← Back to Directory

DoorDash interview notes, page 30 of 42

Large Enterprises

Most of these DoorDash write-ups come from Software Engineers (265), then Data Scientists (69) and Product Managers (52). The most reported rounds are the technical phone screen (201), the system design round (93), the product sense round (55) and the behavioral / leadership round (36).

416 interview notes · updated Oct 2026

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data scientist interview with a SQL-heavy technical screen. One question, pretty involved, centered on percentile filtering over a rolling window. Not the kind of thing you can wing.
  • Write a SQL query to return all orders from restaurants whose total completed-order revenue over the last 30 days falls in the bottom 25th percentile across all restaurants.

“The setup sounds manageable until you actually sit down to write it.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash data science interview with a product analytics question about driver behavior across order types. Pretty open-ended, which I wasn't fully prepared for.
  • Drivers appear to spend noticeably less active time on grocery orders compared to convenience store orders. How would you investigate and act on this?

“I jumped straight to 'maybe grocery stores are faster' and kind of stopped there, which in hindsight was a weak answer.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data science case focused entirely on diagnosing delivery delays end-to-end, from defining what 'late' even means to designing a geo-holdout experiment. Pretty involved for a single session, and the experiment design portion is where things got real.
  • How would you define 'late' for a food delivery order, and what's your primary KPI versus the guardrail metrics you'd track?
  • Which delivery metrics would you examine first, and how would you instrument the order lifecycle to pinpoint where delays are actually happening?
  • How would you attribute excess delay to specific stages of the delivery process and form hypotheses around things like courier supply, prep time estimation, or dispatch logic?
  • Which segments would you cut the delay data by to localize the problem and decide where to focus first?
  • Propose a solution to reduce delivery delays and design an experiment to validate it. Cover your randomization unit, primary metric, guardrails, test duration, and how you'd handle interference between nearby delivery zones.

“This tripped me up more than I expected.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data science case interview focused entirely on diagnosing a drop in successful orders for a food delivery marketplace. Heavy emphasis on structured thinking across demand, supply, and operational dimensions, plus experiment design. No behavioral questions from what I remember.
  • Successful orders in one geographic market have been declining for four weeks. What could be causing this?
  • Which metrics and data slices would you look at first when investigating this kind of drop?
  • How would you tell apart a demand-side problem, a supply-side problem, an operational issue, and a data instrumentation bug?
  • Walk me through one or two experiments you would run to validate a root cause and try to improve the metric. Include your primary metric, guardrails, and how you'd handle ambiguous results.

“This is where I spent way too long listing possibilities without organizing them.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at DoorDash for a software engineering role. The prompt was a full-blown alert notification platform, the kind where you think you know where to start and then realize thirty minutes in that you've barely scratched the surface.
  • Design a multi-tenant alert notification system for operational incidents, supporting millions of events per day, sub-30-second delivery, at-least-once guarantees, deduplication, escalation chains, on-call schedules, and failover across notification providers.

“I spent way too long on the data model upfront and the interviewer had to nudge me toward the actual delivery pipeline.”

View Post

DoorDash·Machine Learning Engineer·Onsite - System Design / Architecture

Jun 2026
DoorDash MLE system design round focused on ads infrastructure end to end. No ML theory, just backend architecture for the whole ads pipeline, which was a nice change from the usual.
  • Design an ads recommendation and serving system, focusing on the backend infrastructure rather than the ML model itself. Cover ad ingestion, candidate retrieval, ranking, serving top-N ads, click and impression tracking, budget pacing, and the components that support all of this at scale.

“This is a big question and I underestimated how much ground it covers.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash software engineering interview that was basically one long debugging scenario. Dense question, lots of moving parts, and I'm still not sure I covered everything they were looking for.
  • You've inherited a service where unit tests pass locally but production is showing intermittent errors. Without a debugger, walk through how you'd investigate this using logs, including how you'd set log levels, add structured and contextual logging with correlation IDs, and separate signal from noise.
  • How would you build a minimal reproducible case for a production bug when you can't attach a debugger and the failure is intermittent?
  • How would you use feature flags or canary deployments to isolate whether a recent change caused the intermittent production errors?
  • Walk through how you'd divide a debugging investigation across a team, set up a triage board, and track hypotheses from initial guess to confirmed resolution.
  • Once you've confirmed the root cause, how do you implement the fix, add regression tests and alerts, and run a blameless postmortem?

“This part I actually felt okay about.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data science interview focused on a classic ops debugging scenario. One question, but it had a lot of layers and I felt like I was barely scratching the surface by the time they moved on.
  • Driver wait times at restaurants spiked last week compared to the prior week. How would you debug this, and if you confirm restaurant understaffing is the cause, what would you do about it?

“I jumped straight to restaurant-level breakdowns and forgot to first sanity-check whether the spike was even real, like ruling out a logging bug or a change in how wait time is measured.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
DoorDash PM interview, product sense round focused on a cross-company scenario about OpenTable's post-booking experience. One question but it had a lot of surface area to cover.
  • You're the PM responsible for OpenTable's post-booking experience. What do you think their biggest problem is in that area, and how would you prioritize and address it?

“Tricky because you have to context-switch into a company you don't work at and make judgment calls with incomplete info.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash coding round focused on a pretty involved simulation problem around their Dasher pay system. More edge cases than I expected and the domain knowledge tripped me up a bit.
  • Given a sequence of delivery driver shift events (shift start/end, offer, accept, pickup, dropoff, cancel, each with timestamps and metadata like miles and tips), implement a function that calculates the driver's total pay. The pay model includes base pay per delivery, per-mile, per-minute rates, and tips, plus a minimum pay guarantee for the shift. Your solution should also handle out-of-order or missing events.

“This one took me a while to even parse.”

View Post