DoorDash Software Engineer Case Interview: Designing Real‑Time ETA and Dasher Assignment for a Two‑Sided Marketplace

This engineering case mirrors DoorDash’s real onsite style: a collaborative, whiteboard-first discussion where you scope an ambiguous logistics problem, define success with concrete metrics, design the system end‑to‑end, and reason about trade‑offs under real‑world operational constraints. The focus reflects DoorDash’s culture of data-driven execution, marketplace thinking (merchants, consumers, dashers), and high-ownership reliability during peak demand. What the case covers: - Problem framing and metrics: Define north-star and guardrail metrics for delivery promise accuracy and marketplace health (e.g., promised ETA accuracy/p95 error, on-time delivery rate, assignment latency, order completion rate, dasher utilization, consumer cancellations, merchant prep adherence, cost per order, experiment guardrails). - System design under real-time constraints: Design a service that (1) quotes consumer-facing ETAs at order time and (2) assigns/batches orders to dashers across Marketplace and Drive (white-label) while respecting SLAs and fairness/earnings constraints. - Data and modeling: Identify key features for prep-time and travel-time estimation (historical store prep distributions, menu item effects, backlog/queue depth, traffic/weather, dasher supply heatmaps, pickup/parking friction). Propose an inference path (feature store + online model service) with fallbacks/heuristics when models degrade. - Matching and batching: Propose a scoring function for dasher–order matching that balances ETA risk, distance, batch feasibility (multi-pickup, multi-drop), dasher preferences, merchant constraints, and consumer promise windows. Discuss greedy vs. search-based approaches, incremental re-optimization, and when to split/merge batches. - Architecture and scale: Sketch APIs (Order, QuoteETA, AssignDasher), streaming/queues for location and status updates, online feature store, model serving, and a matching service. Call out latency targets (e.g., <100 ms per candidate scoring), throughput, backpressure, and resiliency (feature flags, circuit breakers, regional isolation, graceful degradation to heuristic ETA). - Operational excellence: Handle Friday dinner spikes, partial outages (maps, model service, or merchant POS), and bad data (clock skew, GPS drift). Walk through on-call triage: identify if a rollout or traffic anomaly drove p95 lateness; propose mitigations (rollback, reduce batching radius, pause promos, dynamic pay boosts), and post-incident hardening. - Experimentation and metrics movement: Outline an A/B or AA→AB plan for a new batching heuristic with marketplace guardrails (consumer cancellations, merchant lateness, dasher earnings variance). Cover power/sample sizing at city-level, ramp strategy, and how to detect Simpson’s paradox across neighborhoods/timeslots. - Edge cases specific to DoorDash: Storefront and Drive integrations with merchant prep signals; shopping orders with item substitutions; stacked orders at the same merchant; store closes mid-prep; handoff to support flows. Suggested flow (used by interviewer): 1) Clarify goals and constraints (5–8 min) 2) Metrics and success definition (5–7 min) 3) High-level architecture and data/ML components (12–15 min) 4) Matching/batching algorithm and APIs (12–15 min) 5) Reliability, cost, and operational trade-offs (8–10 min) 6) Experiment plan and measurement (5–8 min) 7) Extension prompt (time-permitting): city-level surge, incentive tuning, or cross-border timezones. What strong answers demonstrate (aligned with DoorDash style): - Marketplace-first reasoning with explicit trade-offs among consumers, merchants, and dashers. - Concrete metrics and SLAs; pragmatic fallbacks when ideal data/models aren’t available. - Clear API contracts and data flows; attention to latency, tail behavior, and blast-radius control. - Thoughtful experimentation with guardrails; understanding of how changes propagate operationally. - Ownership mindset during incidents; crisp rollback and mitigation strategies.