Overview

• 5 minute intro
• 50 minutes on debugging exercise
• 5 minutes for Q/A

Debugging Dasher Assignment Service

You have a single main.py file (or equivalent in your chosen programming language) that contains some business logic for a mock Dasher Assignment Service. This service would be used to assign dashers to deliveries.

You need to identify the logic bugs, bad design/coding practices and improve the codebase. Prioritize fixing logic bugs

You are given the following interfaces:

User class

• Contains just an ID attribute
• You need to instantiate with ID

Dasher class

• A special type of user
• Very lightweight wrapper. You get the idea

RemoteDeliveryRecordingService

• Stubbed out logging service. In real production, you'd actually want to be able to query the logs from some storage service or 3P like Splunk, DataDog, Sentry, etc. You are not required to query log statements in this exercise. The logging service is more of stub for you to extend as you wish. No functions implemented, just the placeholder signature. Below are the stubbed out functions you can modify:
• recordDasherAdd(dasherId, timestamp)
• recordDasherPicking(dasherId, timestamp)

DeliveryAssignmentService

• Main piece of code
• Constructor takes in an instance of the RemoteDeliveryRecordingService

The functions that have an implementation (remember it's a debugging exercise) are:

a. addDasher(id) --> take an id and create Dasher object to be added to the pool

b. pickKey() --> rand int function that choose random id from the pool

c. adjustMap(key) --> helper function that tries to process the pool after picking dasher

d. pickDasher() --> calls pickKey(). with the key, record the picked dasher and then calls adjustMap. There is a call to the RemoteDeliveryRecordingService

Bugs weren't too bad to find. It was mainly minor but important logic issues. In terms of followup, the interviewer asked me about additional test cases, optimizing my solution to be better than that of the broken implementation provided

Tips

• You are DEBUGGING code already given to you! Don't overfixate on abusing OOP in everything

• No AI allowed for this round guys! You gotta actually use your brain :D

• Read the business requirements provided in the question carefully. I made sure in the first 10 minutes to read through the requirements as I was going through the buggy code and clarified any unclear requirement to the interviewer. It's really important you be able to solve the right problem

• Communicate communicate communicate! Interviewer is not a mind reader. They can't help you if you don't vocalize

• You are gonna do this in Hackerrank, so just use debug prints. You won't be able to see all the output in one go b/c Hackerrank truncates the output console for some reason. Don't get too cute with adding breakpoint() everywhere. Keep it simple

• When you want to make a fix, try to keep your change simple. Imagine you are putting up a PR in the real world. Give your reviewer a small PR instead of a gigantic one! Try to use as much of the existing stuff there is! Don't reinvent the wheel