← Back to Directory

DoorDash interview notes, page 35 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·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash SWE interview that was basically a coding round disguised as a design exercise. They gave me a filesystem-style key-value store to build from scratch and wanted real working code plus a complexity breakdown at the end.
  • Design and implement a hierarchical key-value store where keys are directory-style paths like /a/b/c. Support create, set, get, and delete operations with the constraints that root always exists, create requires the parent to exist, and delete only works on leaf nodes. Also discuss the time complexity of each operation.

“This felt like two questions jammed into one.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
PM interview at DoorDash, product sense round with one question about improving the post-booking experience for TaskRabbit. Pretty open-ended, which I wasn't fully prepared for.
  • How would you improve the post-booking experience for TaskRabbit?

“I spent too long on the obvious stuff like notifications and ratings and the interviewer kind of just waited.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash software engineering interview that went deep into spatial algorithms. The main problem was a nearest-courier matching question that started reasonable and then kept escalating with follow-ups until I was basically designing a mini geo-indexing system on the fly.
  • Given a set of customer locations and a set of courier locations (each courier has an id), for every customer find the nearest courier by distance. On ties, return the smallest courier id. Implement a brute-force solution first and analyze its complexity.
  • Design a solution that beats O(n * m) for large inputs. Walk through spatial data structures like k-d trees, R-trees, or spatial hashing and analyze the complexity of your chosen approach.
  • Which distance metric are you assuming, Euclidean or great-circle, and how does that choice affect correctness and the data structures you'd use?
  • How do you handle edge cases: tie-breaking by smallest id, duplicate courier locations, and floating-point precision when comparing distances?
  • How does your approach change if courier locations update frequently, for example couriers being added, removed, or moved in real time?
  • How would you efficiently handle large batches of customer queries at once?
  • How would you add a maximum pickup radius constraint, where a customer returns 'no courier' if no courier is within range?

“The brute-force part was fine, just iterate all couriers for each customer and track the minimum.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data science take-home style question, one big SQL problem about cuisine-level delivery performance with CTEs, window functions, and percentile math. Pretty gnarly for a single question but that's kind of their thing.
  • Write a single SQL query (CTEs or subqueries only, no temp tables) that computes, per cuisine: the median delivery time in minutes for completed orders under 10 miles in the most recent 7-day window, the same median for the prior 7-day window, the percent change between the two, and the count of qualifying deliveries. Exclude ghost kitchens, canceled orders, and any cuisine with fewer than 30 qualifying deliveries in the recent window.

“This one took me a while to untangle.”

View Post

DoorDash·Software Engineer·Onsite - Behavioral / Leadership

Jun 2026
Behavioral round at DoorDash for a software engineer role. The main question was a deep dive into a past project, and it went in a few directions I wasn't fully prepared for.
  • Walk me through a recent project you led or made a major contribution to. What was the problem, what was your role, what design decisions did you make, and what were the measurable outcomes?
  • What specific feedback did you get from your manager and product stakeholders on that project, and how did you actually incorporate it?
  • Looking back at that project, what would you change to improve either the impact or the execution?

“I had a solid story ready but the measurable outcomes part tripped me up.”

View Post

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

Jun 2026
ML system design round at DoorDash for an MLE role. The whole thing was focused on infrastructure and pipelines rather than modeling, which I wasn't fully expecting. Pretty thorough coverage of the full lifecycle from feature stores to serving to observability.
  • Design the end-to-end ML infrastructure for a large-scale product, covering the training pipeline, inference pipeline, and experiment management. Focus on the infrastructure and high-level pipelines rather than the model itself.
  • How would you design a feature store that supports both online low-latency lookups and offline batch training jobs?
  • Walk through how you'd handle A/B testing, shadow deployments, canary rollouts, and rollbacks for ML models in production.
  • How would you monitor a deployed ML system for data drift, model drift, and training/serving skew?
  • How would you approach cost optimization and multi-tenant isolation in a shared ML infrastructure platform?

“This was basically the whole interview.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
DoorDash PM interview with a classic strategy case that sounds like a business school warmup but actually has some teeth to it once you get past the obvious answers.
  • How would you triple Craigslist's revenue over the next five years?

“I spent the first minute just trying to remember how Craigslist even makes money right now, which is not a great look.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash coding round, grid BFS problem with a follow-up on dynamic obstacle handling. Pretty domain-flavored but the core was standard multi-source BFS stuff. The follow-up is where things got interesting.
  • You have an m×n grid with store cells, home cells, road cells, and obstacle cells. For each home, find the shortest path distance to the nearest store. If no store is reachable from a home, return -1 for that home. Walk through your algorithm, its complexity, and write the code.
  • If new obstacles are added to the grid frequently between queries, how would you update the shortest-path distances without running a full BFS from scratch each time?

“Multi-source BFS from all stores simultaneously, which gets you shortest distances to every reachable cell in one pass.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash coding screen for a software engineer role. One problem, pretty domain-flavored but straightforward once you break it down.
  • Given an order with a pickup location and a list of dashers (each with an id, current location, and availability flag), write a function that assigns the order to the nearest available dasher by Euclidean distance, breaking ties by smallest id. Return the dasher's id, or null if no one is available. Also analyze the time complexity.

“The logic itself isn't hard but I spent a weird amount of time second-guessing whether I needed to actually sort or just do a linear scan.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
A deep end-to-end product case for a DoorDash data scientist role, centered entirely on designing and launching a bicycle courier program. No fluff, no warmup questions, just one big sprawling scenario that kept branching into sub-questions for what felt like forever.
  • What is the primary business objective behind launching a bicycle courier program in dense urban areas?
  • What factors would you evaluate before launching the program, covering things like geographic fit, supply and demand balance, operational readiness, economics, and safety or compliance?
  • How would you operationalize this program day-to-day and at scale, including courier eligibility, onboarding, routing and ETA adjustments, dispatch logic, pricing, merchant coordination, and support?
  • What specific data would you collect to understand parking and curb access challenges for bike couriers?
  • What metrics would you track to measure program success? Walk through your core KPIs, secondary metrics, and guardrails.
  • How would you design an experiment to test this program given the two-sided marketplace and the network interference problem?
  • How would you decide which cities or neighborhoods to launch in first, and what does a phased rollout strategy look like?
  • If the metrics don't improve after launch, how would you diagnose what went wrong and decide what to change?

“I jumped straight to cost reduction and kind of forgot to frame it from the customer side first.”

View Post