Code Craft & Debugging

Two rounds on the DoorDash loop do not look like LeetCode, and they catch prepared people off guard. In Code Craft you implement a real business module from a written spec, something like a Premium question logic or a cart that has to apply promotions before it can show a total. In the Debugging round you open an unfamiliar service, often a Dasher Assignment Service in a single main.py, watch its unit tests fail, and fix it. Neither round has an algorithmic trick waiting to be found. They measure whether you write the kind of code that ships.

That is the whole reason DoorDash runs them. A clean traversal tells them you studied. A payout module with the rounding right and the duplicate-charge case handled tells them what your pull requests will look like on the team. The two rounds share one worldview, so prepare them together. Code Craft asks you to build something correct from messy rules. Debugging asks you to repair something broken without tearing it apart. The thread is the same. Both reward judgment about edge cases and structure far more than raw problem-solving speed.

The DoorDash angle

Production code beats clever code in both rounds, and the gap is the entire grade. A working solution that handles the awkward inputs and reads like something a teammate could maintain scores higher than a tighter one that drops a case. Get the main path running first and say so, then layer the edge cases on top and back each with a quick test. Interviewers here are watching how you sequence the work and how you talk about trade-offs, not whether you reach for the optimal data structure. A candidate who ships a plain, correct, tested module out-scores one who writes something elegant that mishandles a negative balance.