DoorDash Interview Questions — Page 17

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

System design round at DoorDash for a software engineer role. The prompt was about building a food review platform with rewards tied to review quality, which sounds deceptively simple until you get into the abuse-resistance and exactly-once payout stuff.

Design a system that allows DoorDash consumers to post reviews on food items they ordered, where review quality is scored and consumers earn dollar-based rewards accordingly.
How would you handle the functional requirements: submitting a review with text, photos, and a star rating; scoring each review for quality; issuing rewards; and letting users browse reviews per item with sorting and pagination?
What are the non-functional requirements you'd prioritize, and how do you design for high read throughput, fair and abuse-resistant quality scoring, and idempotent reward payouts?
Walk through the anti-abuse components you'd build: rate limiting, deduplication of reviews, and fake review detection.

“This one sprawled fast.”

View Post

DoorDash·Software Engineer·Onsite - Behavioral / Leadership

May 2026

Behavioral round at DoorDash for a software engineer role. One question, pretty focused on customer issue handling, which makes sense given what DoorDash actually does.

Walk me through a time you dealt with a customer-facing problem like a missing or wrong order. How did you figure out what happened, keep the customer in the loop, and fix it? What changed in your process afterward to stop it from happening again?

“This felt like a product-ops question disguised as behavioral.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026

PM interview at DoorDash with a product sense question borrowed from the Google Flights world. One question, no frills, just a prioritization case.

How would you prioritize fixing the worst part of the post-booking experience for a flight search product?

“I spent too long trying to enumerate every possible post-booking pain point before actually picking one to go deep on.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash analytics engineer interview that was basically one long deep-dive on a single ETL pipeline you've built. They give you around 40 minutes and peel back every layer, so if you've only ever touched one part of a pipeline end-to-end, this round will expose that fast.

Walk me through an ETL pipeline you built end-to-end, covering source systems and ingestion, schema and transformation logic, orchestration and scheduling, data quality checks and SLAs, monitoring and alerting, failure handling and backfills, and the trade-offs you made.

“This is the whole interview, not just an opener.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash ran a pretty unusual coding round where you're not allowed to write any code yourself. You have to prompt AI tools like Cursor or Copilot, paste in what they generate, and iterate until the tests pass. The interviewer is watching how you think and decompose the problem, not whether you can type fast.

Given a problem statement and a partial codebase, solve it entirely through AI coding tools by writing prompts and iterating on the generated code until all tests pass. No writing code yourself.

“This format genuinely threw me.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash coding screen focused on a stream processing problem involving order events. Pretty domain-specific for a food delivery company, which I guess makes sense, but it still caught me a bit flat-footed.

Given a stream of order events, each containing an order ID, dasher ID, timestamp, and a status of ACCEPTED, FULFILLED, or CANCELED, write a function that takes a dasher ID and returns their total pay. Pay is calculated as the number of currently ongoing deliveries multiplied by a base rate of 0.3, where an ongoing delivery is one that has been accepted but not yet fulfilled or canceled.

“My first instinct was to just filter by dasherId and count ACCEPTEDs, which is wrong because you have to subtract out the ones that got FULFILLED or CANCELED afterward.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

System design round at DoorDash for a software engineer role. The whole session was basically one big question about querying dasher order history at scale, and it went in a lot of directions fast.

Design a system to support querying completed order records across all dashers. Walk through storage choices, partitioning, indexing, pagination, async exports, freshness trade-offs, and access control.

“This is one of those questions that looks like a single question but is really like six questions stapled together.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

System design round at DoorDash for a software engineer role, focused entirely on designing a payment system for delivery drivers from scratch. The question was massive and covered basically every dimension of distributed systems design you can think of. Walked away feeling like I got maybe 60% of it.

Design an end-to-end payment system for DoorDash delivery drivers that computes payouts from order lifecycle events. The event stream has records with dasherId, orderId, timestamp, and status (accepted, fulfilled, cancelled). Walk through the full system design including APIs, payout rules, time handling, storage, idempotency, bad data handling, batch vs streaming, reliability, and consistency trade-offs.
How do you define the API between the event producer and the payment service, and what should the earnings query response look like for a dasher?
What are the payout rules when an order is accepted, fulfilled, or cancelled, and which timestamp do you attribute the payout to?
How do you handle late-arriving or out-of-order events, and what happens when a FULFILL event arrives with no prior ACCEPT?
How do you ensure idempotency and avoid double-paying a driver under at-least-once event delivery?
When do you use streaming vs batch processing for payout computation, and how do you handle backfills and end-of-period reconciliation?
How do you sketch the key classes and methods for event ingestion and payout calculation, and how does the API handle querying a dasher's earnings for a local pay period including timezone and DST?

“This is a beast of a question.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash coding screen focused on a grid traversal problem themed around their DashMart product. Pretty standard BFS territory but the domain-specific framing threw me off for a second.

Given a grid map with a Dasher at a starting cell and a DashMart at a known location, find the shortest path between them while handling non-traversable cells correctly.

“My first instinct was Dijkstra but the grid was unweighted so BFS was obviously the right call.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

DoorDash system design round where they had me build an in-memory hierarchical key-value store from scratch. Pretty open-ended, which I wasn't expecting for a coding-adjacent round. Had to cover data structures, complexity, testing, and then concurrency and persistence on top of it.

Design and implement an in-memory hierarchical key-value store using UNIX-style paths. The root node '/' starts with value '#'. Support Create, SetValue, GetValue, and Delete operations with appropriate constraints (parent must exist for create, no children allowed for delete, etc.). Define the class interface, pick your data structures, analyze time and space complexity, write unit tests, and explain how you'd add concurrency safety and optional disk persistence.

“This was basically the whole interview.”

View Post