← Back to Directory

DoorDash interview notes, page 11 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

May 2026
DoorDash data science interview focused entirely on SQL, four interconnected parts all built around the same orders schema. The questions escalated nicely from basic aggregation to window functions and percentile logic, which I appreciated, though part four tripped me up more than I expected.
  • For each calendar month, what percentage of that month's total orders were placed by high-frequency customers, defined as customers who placed more than 30 orders in that month?
  • Excluding high-frequency customers, find the top spender for each month by total order value. If multiple customers tie for the top, return all of them.
  • Compute the month-over-month change in total sales for a specific restaurant, then generalize the same logic to every restaurant.
  • Given a query that computes the percentage of customers ordering from bottom-30%-by-sales restaurants, explain what the query does line by line, then rewrite it to produce that percentage broken out per month.

“This one is mostly mechanical once you realize you need two layers: first aggregate per (month, customer) to find who clears the 30-order threshold, then join that back to get their share of total orders.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash data engineering interview with a meaty SQL problem built around their actual domain schema. One question but it had a lot of moving parts and the follow-up discussion on window functions vs LIMIT went longer than I expected.
  • Using a schema with merchant, menu, order, and dasher tables, write a SQL query to find the top 5 merchants by total revenue within a given time window. Return merchant_id, merchant_name, total revenue, and rank. Use window functions to handle ties, and explain the difference between RANK/DENSE_RANK and just doing LIMIT 5. Filter to active merchants and handle nulls and cancelled orders.

“I got the basic aggregation down pretty fast but fumbled a bit explaining when DENSE_RANK actually matters versus RANK.”

View Post

DoorDash·Machine Learning Engineer·Technical Phone Screen

May 2026
DoorDash ML engineer interview with a greedy interval batching problem. The coding part was pretty focused and they wanted you to actually run your own tests, which I wasn't totally expecting.
  • Given a sorted list of timepoints, pack them into the minimum number of batches where each batch holds at most B items and all items fall within a window of length W starting from the first item in that batch. Implement the solution, write your own test cases, run them, and then discuss edge cases and possible improvements.

“The greedy part clicked pretty fast: start a batch at the leftmost unused item, keep pulling in items that fit within B count and within the W window, then close the batch and repeat.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
DoorDash system design round for a software engineer role. No fixed problem to solve, just the interviewer steering a conversation about how you'd make an existing service more robust and scalable. It's more of a probing dialogue than a whiteboard session, which I wasn't fully prepared for.
  • How would you handle malformed or abusive input coming into a service? Walk through your validation and sanitation approach and when you'd fail fast versus tolerate bad data.
  • Your service needs to process a dataset that's too large to fit in memory. What are your options and how do you choose between them?
  • How do you design a service to handle partial failures or full outages in a dependency gracefully?
  • You're calling a third-party API in production. What does a production-safe integration look like?
  • Describe how you'd design a producer/consumer architecture. How do you think about partitioning and what tradeoffs come with it?
  • What's the difference between at-least-once and exactly-once delivery, and how do you actually achieve exactly-once semantics in practice?
  • When would you choose streaming over batch processing, and vice versa? What factors actually drive that decision?

“I went straight to input validation at the API boundary and talked about rejecting early, but the interviewer kept pushing on the tolerate-vs-reject tradeoff.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026
Did a product sense round for a PM role at DoorDash. One question, pretty open-ended, and I left not totally sure how I did.
  • How would you improve Spotify as a podcast app?

“I went straight to user segmentation which felt right in the moment but I spent way too long on it before getting to actual features.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
DoorDash system design round where you spend the bulk of the time walking the interviewer through one of your own projects rather than solving a prompt they give you. Felt more like a technical conversation than a traditional interview, which I wasn't fully ready for.
  • Walk me through a technically deep project you've worked on as if you're presenting the system design, covering the problem, architecture, key trade-offs, and how you'd handle failures or scale.

“This one caught me because I expected them to give me a prompt.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026
PM round at DoorDash with a product sense question framed around Ticketmaster. Pretty standard case format but the post-booking angle meant you had to think beyond the purchase funnel, which tripped me up a bit.
  • You're a PM at Ticketmaster. How would you identify and solve the biggest problem in the post-booking experience?

“I spent too long in the problem identification phase and kind of rambled through user segments before landing on anything concrete.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026
DoorDash product sense round, one question about designing for a teen audience. Pretty open-ended and I spent way too long setting up the problem before actually getting to ideas.
  • Design a product that helps teenagers discover new restaurants and places to eat.

“I went straight into features and had to backtrack when they asked who exactly I was designing for.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash coding screen, one problem the whole time. It's a scheduling/time-slot encoding question that looks deceptively simple until you actually have to handle AM/PM, 24-hour conversion, and day rollover all at once.
  • Given a list of start times in 'Day HH:MM AM/PM' format and a corresponding end time, generate all 5-minute interval slot codes between them. Each code is a 5-digit integer where the first digit is the day of the week (1=Mon through 7=Sun) and the remaining four digits are the hour and minute in 24-hour format. Handle AM/PM conversion, correct 24-hour formatting, and day rollover when the interval crosses midnight.

“I underestimated this.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
DoorDash system design round focused entirely on building an HTTP API around an existing dasher pay computation engine. Pretty deep dive, lots of back-and-forth on failure modes and retry semantics specifically.
  • You have existing logic that computes a dasher's pay from order event logs. Design an HTTP API to expose this as a service, covering endpoints, request/response schema, idempotency, failure handling, validation, and observability.

“This is a big compound question and I underestimated how much they'd push on the failure handling piece.”

View Post