DoorDash will hand you a buggy pay-calculation service before it hands you a binary tree. The loop is one of the more hands-on ones in big tech: a debugging-flavored phone screen, a “CodeCraft” round where you build a small working feature, system design that always circles back to the three-sided marketplace of customers, merchants, and Dashers, and, in some 2026 loops, a working session where you’re expected to build with AI coding tools in the editor. If your prep is pure LeetCode grinding, you’ve prepped for about half of it.
Expect four to five rounds over three to six weeks. A recruiter call, a technical phone screen, then a virtual onsite: one or two coding rounds, system design, and a behavioral with a manager. Senior candidates (E5 and above) get a heavier design load, and some teams add a round on their own stack and domain.
The full loop at a glance
| DoorDash SWE round | Length | Format | What they score |
|---|---|---|---|
| Recruiter screen | 30 min | Resume walkthrough, motivation, leveling and comp expectations | Level calibration, team fit, timeline |
| Technical phone screen | 60 min | Debugging or small build exercise in CoderPad/HackerRank; sometimes a LeetCode medium | Working code, edge-case handling, reading unfamiliar code |
| Onsite coding (1-2 rounds) | 60 min each | LeetCode medium/hard, heavy on grids, intervals, job scheduling | Correct solution first, then complexity; self-written tests |
| CodeCraft / AI working session | 60-75 min | Build a functional feature (pay calculator, order assigner); some loops allow AI tools | Shipping something that runs; judgment over AI output |
| System design | 60-75 min | Logistics-flavored: dispatch, ETA, live tracking, payouts | Real-time state, geospatial indexing, failure handling |
| Behavioral | 60 min | Manager-led, built around DoorDash operating values | Ownership stories, conflict, lessons from failure |
Loops vary by team and level, so ask the recruiter exactly which rounds you’re getting. It’s a normal question and they answer it directly.
The phone screen is a code-reading test in disguise
The 60-minute screen usually isn’t the classic “invert this tree” filter. DoorDash’s house format is called CodeCraft, and the screen version tends to be a compact build or a debugging pass: here’s a small service with three bugs, find and fix them, or here are the Dasher pay rules, turn them into code. The pay-rules version is a favorite because the rules are deliberately messy. Base pay plus tips, a peak-pay bonus in certain zones, a minimum guarantee that only kicks in when tips fall short. Then the interviewer changes a rule ten minutes before the end and watches whether your code bends or breaks.
What gets you through is boring engineering hygiene. Name things clearly, keep the rule logic separate from the I/O, and write a couple of tests without being asked. Candidates who start typing before they’ve restated the requirements lose points here that they never get back.
Coding rounds lean on grids, intervals, and scheduling
The onsite algorithm rounds are more conventional. Tagged-question data puts DoorDash’s mix at roughly 60 percent medium and a third hard, and the themes map straight onto the delivery domain: BFS and DFS on grids, interval merging, and scheduling DP. A few phrasings reported by candidates:
- “Given pickup and delivery pairs, count the valid orderings where every pickup comes before its delivery.”
- “Two versions of a restaurant menu are trees. Count the nodes that changed between them.”
- “Given delivery jobs with a start time, end time, and pay, pick the non-overlapping set that earns the most.” (Maximum Profit in Job Scheduling, wearing a Dasher costume.)
- “Implement a HashMap without using built-in hash table libraries.”
The menu-tree question deserves dedicated practice because it looks easy and isn’t. A naive recursive diff double-counts modified nodes, and interviewers will probe your definition of “changed” (added? removed? same id with a new price?) until you commit to one. State your assumption out loud, write it as a comment, and move.
System design is the dispatch problem, whatever the prompt says
You might get “design DoorDash” outright, or a slice of it: “Assign the nearest available Dasher to a new order within a few seconds, and support reassignment when they decline.” Either way the hard parts are the same. You need geospatial indexing (geohashes or S2 cells, and be ready to explain why a naive lat/long range query on a relational index falls over), a stream of location pings from hundreds of thousands of active Dashers, and an order state machine with more states than you’d guess: created, merchant-confirmed, Dasher assigned, picked up, delivered, plus the unhappy paths where a Dasher goes dark mid-delivery.
Strong candidates pick two or three deep-ends and say so out loud. Payouts are a good choice because that’s where correctness bites: the payment step has to be idempotent, since a retry storm after a network blip is exactly how a Dasher gets paid twice. ETA prediction is another, since it opens a conversation about feature pipelines and what you do when the model is wrong at the tail. Senior loops push on failure modes. What happens when the assignment service is down for four minutes on Super Bowl Sunday is a question that has been asked in roughly those words.
The behavioral round is scored, not a formality
The closing hour with a manager runs on DoorDash’s operating values, and the one that shapes the most questions is the expectation that people operate at the lowest level of detail. Expect prompts like “Tell me about a time you caught a problem everyone else had missed” and “Walk me through a project that failed and what you’d do differently.” Generic answers land badly. They want the actual metric, the actual mistake, the actual conversation you had afterward.
One company-specific note: DoorDash runs WeDash, the program where corporate employees, engineers included, periodically do deliveries or support shifts. Some interviewers ask how you feel about that. Answer truthfully, but if doing a delivery to understand your own product sounds beneath you, this is the wrong company and it will show.
What the offer looks like
Engineering levels run E3 through E7. As of mid-2026, levels.fyi medians sit near $278k total comp at E4 and $379k at E5, with reported E5 packages spanning roughly $250k to $430k depending on location and negotiation. Base is the smaller share of the spread; most of the variance comes from the RSU grant on a four-year vest. These numbers drift with the stock price, so check levels.fyi and Blind the week you negotiate rather than trusting any article, this one included.
Equity is where the negotiation actually happens. Recruiters have more room on the initial grant than on base, and a competing offer from a comparable company moves the number more than anything you can say without one.
Where to spend your prep time
Split it three ways. Grind LeetCode mediums filtered to grids, intervals, and scheduling until the patterns are automatic. Run at least two timed system-design reps on dispatch-style problems, out loud, with a real clock. Then practice the thing almost nobody practices: building a tiny working service, with tests, in 45 minutes, and absorbing a requirements change without rewriting everything. That last skill is what CodeCraft measures, and it is also, not coincidentally, the job.
Practice the behavioral round:
