DoorDash Interview Questions — Page 41

DoorDash·Data Scientist·Technical Phone Screen

Jul 2026

DoorDash data scientist interview with a SQL-heavy technical screen. One question but it packed in a lot, window functions across multiple partitions in a single query. Felt like a reasonable test of whether you actually know SQL or just know the syntax.

Given an orders table with columns for order ID, user ID, order date, city, and order value, write a single SQL query that returns each order alongside the previous order value for that same user (NULL if it's their first), the rank of that order's value within its city from highest to lowest, and the percent rank of the order value within its city.

“Three window functions in one query.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jul 2026

Interviewed for a software engineer role at DoorDash and got a coding problem about insurance network coverage. Basically a geometry plus set-membership problem dressed up in a healthcare scenario. Not too bad once you strip away the domain framing.

Given a list of providers (each with a specialty and a 2D location), a list of members (each with a location and a list of required specialties), and a max distance threshold, write a function that returns the IDs of all members who do not have at least one in-range provider for every specialty they need.

“The problem sounds more complicated than it is.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jul 2026

DoorDash data scientist interview with a SQL-heavy technical screen focused on delivery metrics. The question was applied and realistic, which I appreciated, but the follow-up tripped me up a bit.

Given an Orders table with expected and actual delivery dates, write a SQL query to find the percentage of orders delivered late in the last 30 days. Follow-up: which three customers had the most late deliveries in that same window?

“The main query was fine.”

View Post

DoorDash·Software Engineer·Onsite - Behavioral / Leadership

Jul 2026

Behavioral round at DoorDash for a software engineer role, two questions, both pretty standard conflict and impact territory. Nothing shocking but you really do need a tight story ready or you'll ramble.

Describe a time you had a conflict with a teammate, whether over design decisions, priorities, or code quality. How did you navigate it and what happened?
Tell me about a project you're proud of. What was your specific contribution, what trade-offs did you face, and how did you know it made an impact?

“I went with a code review disagreement story and structured it as situation-action-result.”

View Post

DoorDash·Data Scientist·Onsite - Product Sense / Strategy

Jul 2026

DoorDash data scientist interview with a product strategy case built around the bike-delivery program for dashers. Pretty open-ended, which I wasn't fully prepared for.

If DoorDash were to roll out a bike-delivery program for dashers, what operational or strategic challenges would you anticipate, and how would you approach solving them?

“I started with supply balance which felt safe, then kind of spiraled into weather and safety without a clear thread connecting them.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jul 2026

DoorDash system design round focused entirely on building a real-time driver assignment system from scratch. Pretty intense scope for a single session, covering everything from objectives and constraints to algorithms and failure modes.

Design a real-time system that assigns delivery drivers to incoming orders. Walk through your objectives, constraints, data structures, algorithm choices, and how you'd handle scale and partial information.

“This one sprawled fast.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jul 2026

System design round at DoorDash focused entirely on a donation platform problem. It was one of the more sprawling prompts I've seen, covering everything from payment idempotency to GDPR compliance to counter consistency, all in one session.

Design an online donation platform built around short 3-day campaigns. Walk through functional requirements, non-functional goals, and traffic estimates before getting into the architecture.
What APIs and data models would you define for this system? Think about entities like Campaign, Donation, Donor, PaymentIntent, and Receipt.
How would you handle payment processing, including idempotency, retry logic, and reconciliation with the payment provider?
How would you approach fraud and abuse mitigation on a platform like this?
What consistency model would you use for real-time donation totals, and how do you handle the traffic spikes at campaign launch and close?
How would you design the system to comply with PCI, handle PII, and meet CCPA/GDPR requirements?
How would you observe this system in production, handle disaster recovery, and backfill data if something goes wrong?
How would you extend this platform to support recurring donations or corporate matching programs?

“I spent too long on the requirements phase and the interviewer had to nudge me to move on.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jul 2026

DoorDash data science interview with a meaty marketplace diagnosis case that turned into a full experiment design problem. The scope was broader than I expected and the second half caught me pretty flat-footed.

Completed orders in the Los Angeles market dropped meaningfully. Walk through how you'd investigate this end to end.
The investigation points to merchants being online fewer minutes per day. Design an experiment to test an incentive program meant to fix that.

“I started with the funnel breakdown which felt right, app sessions down to completed orders, but I kept second-guessing whether to lead with supply or demand.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jul 2026

DoorDash coding round for a software engineer role. Three-part exercise: implement a small service class from a spec, extend it with a new requirement, then write unit tests covering the full thing. Felt more like a take-home in spirit even though it was live.

Given a written spec for a small service class with no external dependencies, implement the core logic using if/else control flow and proper input validation. State your assumptions explicitly.
Extend the class you just implemented to handle an additional requirement based on assumptions you clarify with the interviewer.
Write unit tests for both parts of the implementation, covering happy paths, edge cases, and error handling.

“The spec was short but I still managed to overthink the input validation part.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jul 2026

DoorDash software engineering interview with a meaty system design coding question. The problem was a custom hierarchical key-value store built on UNIX-style paths, which sounds manageable until you realize how many edge cases they actually want you to cover.

Design and implement a hierarchical key-value store that operates on UNIX-style absolute paths, supporting create, set, get, and remove operations. Each operation has specific failure conditions: create fails if the parent doesn't exist or the path already exists, set fails on missing paths, and remove fails if the node has children. You need to choose your return types, define path syntax assumptions, justify your data structure choices, analyze complexity, and write unit tests covering edge cases.

“This was a lot to hold in your head at once.”

View Post