USA | DoorDash Debugging Onsite
Summary
I had an onsite debugging interview at DoorDash, where I focused on identifying and fixing logic bugs within a mock Dasher Assignment Service, followed by discussions on test cases and optimization.
Full Experience
I recently went through an onsite interview with DoorDash, which was structured around a debugging exercise. The session began with a 5-minute introduction, followed by a 50-minute hands-on debugging task, and concluded with 5 minutes for Q&A. My primary task was to analyze a main.py file that contained the business logic for a mock Dasher Assignment Service, designed to assign dashers to deliveries. The goal was to pinpoint logic bugs, identify bad design and coding practices, and then improve the codebase, with a strong emphasis on resolving logic issues first. I was provided with several interfaces: User, Dasher, RemoteDeliveryRecordingService (a stubbed logging service), and DeliveryAssignmentService. The DeliveryAssignmentService was the central piece, containing functions like addDasher, pickKey, adjustMap, and pickDasher, which all had subtle but critical logic flaws. After successfully identifying and rectifying these bugs, the interviewer engaged me in a follow-up discussion about additional test cases and how I might further optimize my corrected solution beyond the initial broken implementation.
Interview Questions (1)
You are presented with a single main.py file (or its equivalent in your chosen programming language) which encapsulates the business logic for a mock Dasher Assignment Service, responsible for assigning dashers to deliveries. Your task is to identify and correct logic bugs, as well as bad design and coding practices, with a priority on fixing logic bugs. You are given the following interfaces to work with:
Userclass: Contains anIDattribute; you need to instantiate with an ID.Dasherclass: A specialized, lightweight wrapper around theUserclass.RemoteDeliveryRecordingService: A stubbed logging service. While in a real production environment you would query logs from a storage service (e.g., Splunk, DataDog), for this exercise, you are not required to query log statements. It serves as a placeholder for potential extension. Stubbed functions include:recordDasherAdd(dasherId, timestamp)andrecordDasherPicking(dasherId, timestamp).DeliveryAssignmentService: The primary code component. Its constructor takes an instance ofRemoteDeliveryRecordingService. The functions with existing implementations (which require debugging) are:
a. addDasher(id): Takes an ID and creates a Dasher object to add to a pool.b. pickKey(): A random integer function that selects a random ID from the pool.c. adjustMap(key): A helper function that attempts to process the pool after a dasher has been picked.d. pickDasher(): CallspickKey(), records the picked dasher usingRemoteDeliveryRecordingService, and then callsadjustMap().