How DoorDash interviews — Question to Offer

1. The shape of a DoorDash loop

DoorDash is a three-sided marketplace. Customers order food. Dashers deliver it. Restaurants make it. Every system design question lands on the same root: how do you keep all three happy at the same time. Get that frame into your head before round one.

A standard onsite is four to five rounds for L4/L5, five to six for L6+. Two are coding, one is system design (sometimes two at L6+), one is behavioral with the hiring manager, and one is what they call technical depth — a long whiteboard on a system you've built. Each round is 45 to 60 minutes.

The hiring manager round is graded heavily. DoorDash has had years of growing-pain reorgs, and the bar for "can you ship in a company that's reorging around you" is real.

2. What DoorDash grades you on

Four signals: scoping, real-time-systems literacy, marketplace tradeoffs, and operational maturity. For system design, the first three carry most of the weight.

Real-time logistics literacy is the load-bearing one. You'll be asked about dispatch, batching, ETAs, location pings. You don't need to know the exact internals of DoorDash's stack. You do need to be fluent enough that you don't waste five minutes asking what a dasher is or how location updates work.

Marketplace tradeoffs is the DoorDash-specific signal. The interviewer is watching whether you can hold three stakeholders in your head at once. A weak candidate optimizes one side ("give the customer the fastest ETA"). A strong candidate asks the second question: "if we promise this ETA, what does the dasher experience look like, and what's the restaurant doing during the wait?"

3. What's different here

Three-sided thinking is the default frame. Every design choice has to be defended for all three parties. If you optimize the customer experience and starve the dasher, you fail the round. If you optimize dasher earnings and the restaurant gets the order cold, same outcome.
Real-time is not optional. Almost every question involves position updates, freshness budgets, ETAs that age in seconds. Be ready to talk about location streams, freshness contracts, and the cost of stale data.
Batching is the DoorDash twist. Uber's marginal trip is one driver, one rider. DoorDash's marginal delivery can be one dasher carrying three orders along a route. Batching shows up in dispatch, ETAs, and customer trust questions. Know what changes when batching is allowed.
Restaurants are a constraint, not a service you control. Restaurants have their own POS systems, their own kitchens, their own pace. You can integrate with them but you can't dictate prep time. Design for that uncertainty.
Operational maturity is graded explicitly. What metrics do you watch. What's the on-call surface. How do you know your dispatch is broken before customers tweet about it. Senior candidates who hand-wave operations lose points.

4. The level bar

How the bar shifts:

L4 (entry senior) — design at the single-service level. Pick one component (the dispatch queue, the menu cache) and design it cleanly. Scope is graded. Depth is shallow.
L5 (senior) — design at the cross-service level. Three-sided tradeoffs expected on every major choice. One deep dive that survives three pushes.
L6 (staff) — design at the marketplace level. You're expected to reason about incentive alignment across customers, dashers, and restaurants. Failure modes explicit. Migration plans when relevant.
L7+ (senior staff) — design at the organization-shipping-it level. How teams own slices. How experiments roll out. What you'd watch on launch day.

In this chapter, units target L5 or L6 explicitly per question.

5. The DoorDash-flavored mistakes

Watch for these:

Treating it like Uber with food. It isn't. Restaurants are a third party with prep time, batching changes the math, and the dasher's optimal route depends on food readiness. If your answer would also work for Uber unchanged, you missed the question.
Forgetting the restaurant. A surprising number of candidates draw the dasher and the customer and forget there's a kitchen. The restaurant has state too. The restaurant can pause, run out of items, or be slammed.
Picking the wrong freshness budget. ETA can age. Order state cannot. Knowing which numbers can be stale by 30 seconds and which cannot is a senior tell.
Skipping the dasher experience. The dasher's app is a real system. Bad UX for the dasher means churn. Interviewers grade whether you thought about what the dasher sees and does at each step.
Hand-waving the payment splits. A $30 order pays four parties (restaurant, dasher base, dasher tip, tax authority). Treat it as one charge and you signal you haven't shipped this kind of system.

6. The seven scenarios in this chapter

Each unit dissects one question end to end. The chapter covers:

16.1 Dasher dispatch — the matching engine, batching, prep-time-aware arrival.
16.2 Real-time order tracking — multi-source state across customer, dasher, restaurant.
16.3 Dynamic menu and restaurant availability — read-heavy menu cache with TTL.
16.4 Payment splits — restaurant, dasher base, tip, tax ledger entries.
16.5 Drive — batched multi-order delivery — when to batch, how to optimize, what to tell the customer.
16.6 Substitutions and out-of-stock handoff — real-time messaging between dasher and customer.
16.7 Take-home — real-time ETA service — design doc on the aggregated ETA computation.

7. The next page

The first scenario: dasher dispatch. The Uber dispatch question with one twist that changes the answer.