Distilled Prep

DoorDash

DoorDash runs a three-sided marketplace — consumers, merchants, and Dashers — which makes their core problems a compounding version of the classic two-sided ones: every algorithm change touches three populations with different incentives, and every experiment risks interference across all of them.

For data scientists, their interviews famously center on exactly what they blog about: delivery-time prediction, dispatch and batching trade-offs, experimentation under marketplace interference, and operational diagnosis (why did lateness spike?). For software engineers, expect logistics-flavored systems design: real-time dispatch platforms, event streaming across delivery zones, and reliability during demand spikes.

Names worth recognizing: DeepRed (their dispatch/assignment engine) and Curie (their experimentation platform) — both are recurring blog subjects and implicit context in their interview questions.

Their vocabulary

Curie

DoorDash's experimentation platform, frequently blogged about for switchback testing and interference-aware designs — the context behind their experiment-design interview questions.

DeepRed

DoorDash's dispatch and assignment engine: decides which Dasher gets which order(s) and when, balancing delivery speed, Dasher earnings, and food quality. Batching questions and order-ready-time prediction both exist in service of DeepRed's decisions.

The canon

Curated questions on this company's enduring themes.

difficulty 4/5 ML system designML engData scienceforecastingml-platformlogistics-optimizationJul 2026

Design the system that predicts when a restaurant order will be ready for pickup, used by dispatch to time Dasher arrival.

Practice against the follow-up probes
  • What is your label, given that true ready-times are mostly unobserved or noisy?
  • Which errors cost more — Dasher early or food early — and how does that enter the model?
  • What features exist without leakage, and which must be served in real time?
  • How do you handle brand-new merchants and menu items?
  • How do you connect model metrics to marketplace outcomes?
Show answer guide

What the interviewer is probing

ML judgment under label noise and asymmetric costs: ready-time is rarely logged directly (proxies: pickup time minus wait, merchant confirmations when present), errors are asymmetric (early Dasher = paid waiting; late Dasher = cold food and lateness), and the model's value is realized only through dispatch decisions — so calibration and uncertainty matter more than point-accuracy bragging rights.

Strong answer outline

  • Label construction: where merchant "ready" signals exist, use them with de-noising; elsewhere infer from Dasher arrival/wait/pickup telemetry (ready ≈ pickup when Dasher waited; censored when food waited). Model the censoring rather than pretending labels are clean; keep a small ground-truth panel for calibration.
  • Loss design: asymmetric cost — under-prediction (Dasher early) costs Dasher time; over-prediction (food ready, no Dasher) costs quality and lateness. Use quantile regression or explicit asymmetric loss; dispatch consumes a distribution (e.g., P50 + P90), not a point.
  • Features without leakage: merchant historical prep by item/basket size/hour, current confirmed queue depth, kitchen throughput proxies, time/weather; real-time features (queue, recent confirmations) via online feature store; strictly exclude anything timestamped after the prediction moment in training joins.
  • Cold start: hierarchical backoff — item → menu-category → cuisine → market priors; shrink toward the merchant as their data accumulates; widen predicted uncertainty for new entities so dispatch pads conservatively.
  • Serving: prediction at order-confirmation and re-prediction on signal updates; latency budget small; feature freshness monitored; training/serving parity via shared feature definitions.
  • Evaluation tied to decisions: offline — calibration and quantile loss by segment; online — Dasher wait minutes, food-sit minutes, lateness, cost per delivery via experiment; monitor drift by merchant cohort (menus and staffing change constantly).

The underlying concept

This is decision-focused ML: the model's product is not a number but a calibrated distribution consumed by an optimizer whose costs are asymmetric — so loss functions, uncertainty, and calibration are the design surface, not afterthoughts. Label noise and censoring are the second theme: real operational labels are inferred from behavioral traces, and modeling their generation process beats wishing they were clean. Hierarchical priors solve cold start the same way they solve every sparse-entity problem: borrow strength, then let data earn independence.

Source

Distilled Prep canon — curated from DoorDash's public work on ETA and prep-time prediction.

Source: Distilled Prep canon (curated)

difficulty 3/5 Product caseData scienceforecastingdata-qualitylogistics-optimizationJul 2026

Late deliveries increased 8% week-over-week across several cities. Lead the investigation and propose both immediate mitigations and a durable fix.

Practice against the follow-up probes
  • Decompose a delivery's timeline. Where can lateness enter?
  • Is this a forecasting problem or an operations problem — and how do you tell?
  • Which cuts do you make first and why?
  • Several cities at once: what does that pattern itself tell you?
  • What do you ship this week vs. what do you build this quarter?
Show answer guide

What the interviewer is probing

Operational decomposition under time pressure: can the candidate break the promise-to-door timeline into stages (quote, prep, assignment, travel, wait-at-store, last mile), distinguish "we predicted badly" from "the system performed worse," and use the multi-city pattern to prioritize hypotheses (simultaneity suggests a common cause: model release, app version, incentive change, weather system)?

Strong answer outline

  • Definition first: late relative to quoted time — so lateness rises if quotes got tighter OR operations got slower. Check whether the ETA model/quote policy changed; a quote-side change explains multi-city simultaneity instantly.
  • Timeline decomposition: order → merchant confirmation → prep → Dasher assignment → travel to store → wait at store → pickup → travel to consumer. Attribute the extra minutes: which stage(s) grew?
  • Common-cause scan (because several cities moved together): model or app releases, dispatch/batching parameter changes, incentive/supply changes, weather systems, holidays/events; overlay release calendars on the trend.
  • Segment cuts in order of information: by stage (above), by city vs. control cities, merchant type (prep-time issues concentrate in specific cuisines/chains), batched vs. solo deliveries, Dasher tenure (new-Dasher influx slows pickup), hour-of-day.
  • Immediate mitigations: widen quote buffers where lateness concentrates (protects promises at slight conversion cost), cap batching aggressiveness, targeted supply incentives at peak.
  • Durable fix: whichever stage drove it — recalibrate ETA/prep models with recent data, add wait-at-store telemetry, dispatch parameter guardrails, and a lateness decomposition dashboard so the next spike self-localizes.

The underlying concept

"Late" is a relation between a promise and an outcome, so its investigation always forks immediately: did promises tighten or did performance slip? Treating the delivery as a sum of stage durations turns a vague metric move into an attribution problem — the same telemetry-decomposition instinct as latency debugging in distributed systems. And correlated onset across units is itself evidence: simultaneity points to shared infrastructure (models, releases, policies) rather than local operations, which is why release calendars are the first dataset a good investigator pulls.

Source

Distilled Prep canon — curated from DoorDash's public work on delivery operations and ETA prediction.

Source: Distilled Prep canon (curated)

difficulty 3/5 Product caseData scienceexperimentationcausal-inferencemarketplace-dynamicsJul 2026

DoorDash adds bicycle Dashers in a market that previously relied on cars. How would you determine whether the launch is successful?

Practice against the follow-up probes
  • Success for whom? Walk through consumers, Dashers, merchants, and the platform.
  • Bike deliveries will differ from car deliveries by construction. How do you avoid mistaking selection for causation?
  • What experiment design fits a market-level supply change?
  • How do you measure whether bikes added capacity versus cannibalizing car Dashers?
  • Weather and geography interact with mode. How does that shape rollout and analysis?
Show answer guide

What the interviewer is probing

Three-sided metric thinking plus a specific trap: bikes get assigned short, dense, small-basket orders, so naive bike-vs-car comparisons measure the assignment policy, not the mode. Strong candidates design at the market level (geo or phased rollout), decompose incremental capacity vs. substitution, and treat existing car Dashers' earnings as a first-class guardrail.

Strong answer outline

  • Define success across sides: consumers — delivery time, lateness, food quality, cost; Dashers — earnings per active hour for both modes (cannibalization shows up as car-Dasher earnings decline); merchants — order volume, wait-at-store; platform — cost per delivery, fulfillment rate at peak.
  • Name the selection problem: dispatch will route bikes to short/dense orders — never compare bike orders to car orders directly; compare markets (or time periods) with and without the bike program.
  • Design: staged geo rollout with matched control markets or synthetic control; within-market switchbacks are polluted by supply persistence (Dashers don't appear/disappear hourly), so market-level inference is the honest unit.
  • Incrementality decomposition: total supply-hours before/after by mode; survey/behavioral evidence on whether bike Dashers are new workers or car Dashers switching; capacity value measured at peak (did fulfillment improve when it was binding?).
  • Interaction effects: weather (bike supply collapses in rain — check reliability under adverse conditions before calling success), geography (dense cores vs. suburbs), and time-of-day mix.
  • Decision framing: expand where bikes add peak capacity at lower cost per delivery without degrading car-Dasher earnings past a threshold; hold or adjust incentives where substitution dominates.

The underlying concept

When a new supply type enters a marketplace, the platform's own assignment algorithm immediately confounds any unit-level comparison — the treatment (mode) is entangled with the routing policy. The clean counterfactual lives at the market level, which is why geo experiments and synthetic controls dominate marketplace launch evaluation. The second discipline is decomposing gross additions into incremental capacity vs. substitution: marketplaces care about the net supply curve, and total-hours accounting plus peak-constraint analysis is how you see it.

Source

Distilled Prep canon — curated from DoorDash's public work on marketplace experimentation.

Source: Distilled Prep canon (curated)

difficulty 4/5 Product caseData scienceexperimentationlogistics-optimizationmarketplace-dynamicsJul 2026

Design the experiment for a new batching algorithm that assigns two orders to one Dasher. The team believes it cuts cost per delivery; you suspect it risks lateness and food quality.

Practice against the follow-up probes
  • What is the treatment unit — order, Dasher, zone, time window — and why?
  • Where does interference between treatment and control come from here?
  • Why might a switchback beat user-level randomization, and what new problems do switchbacks bring?
  • What guardrails and what decision rule — is this a superiority or a non-inferiority question?
  • The algorithm's benefit depends on order density. How does that shape analysis and rollout?
Show answer guide

What the interviewer is probing

Interference-aware design: batching decisions consume shared Dasher supply, so treated and control orders in one market at one time contaminate each other. This is the canonical switchback scenario, and the interviewer wants the candidate to reason to it — plus the analytic maturity to frame cost savings against lateness as a non-inferiority test with pre-set margins.

Strong answer outline

  • Why order-level randomization fails: an order batched in treatment removes a Dasher from the shared pool that control orders draw on — control outcomes absorb spillover, biasing effects (typically making treatment look better than reality).
  • Design: switchbacks — randomize (zone × time-window) units between algorithms; windows long enough for the system to reach steady state (dispatch queues clear) but short enough for many units; buffer/burn periods at boundaries to limit carryover.
  • Analysis on switchbacks: cluster-robust inference at the window-zone level; expect far less power than order-level tests — plan duration accordingly; check residual carryover by comparing boundary vs. interior periods.
  • Metric frame: primary — cost per delivery (superiority); guardrails — lateness rate, food-temperature proxies/complaints, cancellations, Dasher earnings per hour, merchant wait congestion (non-inferiority with pre-registered margins, e.g., lateness within +0.5pp).
  • Heterogeneity: batching pays only above an order-density threshold; pre-plan analysis by density tier and hour; rollout policy is likely conditional (batch aggressively in dense zones at peak, minimally elsewhere), not global.
  • Decision rule stated upfront: ship the density-conditional policy if cost improves where guardrails hold; iterate the algorithm where quality margins fail.

The underlying concept

Marketplace experiments fail SUTVA whenever treatment consumes a shared resource; the fix is to randomize the level at which the resource is shared — space-time blocks rather than orders. Switchbacks buy validity at the price of power and carryover risk, which planning (steady-state windows, buffers, clustered inference) manages. The metric lesson: when an intervention trades cost against quality, the honest statistical frame is superiority on the target plus non-inferiority margins on guardrails, all pre-registered so the trade-off is decided before the data can argue.

Source

Distilled Prep canon — curated from DoorDash's public work on switchback experimentation and dispatch optimization.

Source: Distilled Prep canon (curated)

difficulty 3/5 Systems designSoftware engdistributed-systemsapi-designreliabilityJul 2026

A customer taps "Place order" and their app times out waiting for your response, so it retries. Meanwhile your first attempt actually succeeded — the order reached the kitchen. Walk me through how you design the order placement API so retries are safe, and then tell me what happens when the deduplication store itself is briefly unavailable.

Show answer guide

What the interviewer is probing

Whether the candidate reaches for idempotency keys as a design principle rather than a buzzword: where the key is generated, what gets stored, the atomicity requirement between "check" and "act", and TTL trade-offs. The second part tests degraded-mode reasoning — do they fail open (risk duplicates) or fail closed (risk lost orders), and can they connect that choice to the business cost of each failure?

Strong answer outline

  • Client generates the idempotency key (per logical order attempt, not per HTTP request) so all retries of one intent share a key.
  • Server: atomic check-and-set (e.g. unique constraint or conditional write), not read-then-write — the race between two concurrent retries is the classic bug.
  • Store the response with the key so retries return the original result, not just a "duplicate" error.
  • TTL discussion: too short re-enables duplicates, too long bloats storage; tie it to realistic client retry windows.
  • Degraded mode: articulate fail-open vs fail-closed and pick using domain cost — a duplicate food order costs a refund; a dropped one costs a customer. Reasonable answers differ; unreasoned answers don't.

The underlying concept

Exactly-once delivery doesn't exist between distributed parties; what systems actually implement is at-least-once delivery plus idempotent processing, which is indistinguishable from exactly-once from the caller's perspective. The idempotency key turns a side-effecting operation into something safely retryable by giving the server a durable memory of intents it has already honored. Every payment and ordering system you've used is built on this pattern.

Source

Hand-written seed example in the style of DoorDash's platform reliability posts.

Source: Example seed question (hand-written)