DoorDash Interview Process & Rounds
In candidate reports, DoorDash's software engineering process is a recruiter call, a one-hour Code Craft phone screen (most often Dasher Pay or the Bootstrap API), and a virtual onsite of four rounds: AI Code Craft, where you build a small working system with your own AI coding tool, Debugging, System Design, and a hiring-manager round on engineering values. Reports that give dates run from about two weeks between the phone screen and an offer to over two months from referral to result, and through spring and summer 2026 many candidates mention a hiring freeze while recruiters kept scheduling interviews. Most onsite reports end in a rejection (13 of 15 that give an outcome), often after candidates felt the rounds went well, and the rounds they blame most are system design and debugging.
Part of the full catalog of DoorDash interview questions, covering every round.
AceOffer is not affiliated with, endorsed by, or sponsored by DoorDash. Questions are reconstructed from interview experiences candidates shared, not from DoorDash materials.
Key facts
- •5 distinct round types
- •12 questions reconstructed from 95 candidate reports
- •Reports span Apr 2026 – Oct 2026
- •Refreshed monthly · last updated October 2026
The DoorDash loop, from candidate reports
Reported DoorDash software engineering loops are practical rather than LeetCode-style. The phone screen is a one-hour Code Craft round of runnable code, most often Dasher Pay or the Bootstrap API, followed by production questions on upstream failures, retries and idempotency. The onsite has four rounds: AI Code Craft, where you build an order refund workflow as live services with your own AI coding tool; Debugging, either a round robin load balancer followed by consistent hashing or a random Dasher picker; System Design, most often a food item review system or a three-day charity donation event; and a hiring-manager round on engineering values. Staff, ML Engineer and some other loops add a project deep dive, often with slides, and some loops include incident scenarios such as a spike in customer complaints or a merchant pricing error.
DoorDash interview timeline
| Step | Typical timing |
|---|---|
| First recruiter contact to phone screen | About one to two weeks (3 reports) |
| Phone screen to result | Within an hour to four business days (5 reports); one candidate had no news two weeks later |
| Phone screen to onsite | Nine days to about three weeks (3 reports); one took about seven weeks after the recruiter left the company |
| Onsite to decision | Next day to about a week (6 reports); one candidate waited two weeks |
| End to end | About two weeks from phone screen to offer, to over two months from referral to result (3 reports) |
The fastest report went from the phone screen to a pass in about two weeks, through a friend's referral to a team close to the candidate's previous work. The slow cases are mostly scheduling: one candidate's recruiter left the company mid-process and the next recruiter took a month to book the onsite, another had a round rescheduled three times, and one candidate passed the phone screen but could not get onsite times. Onsite rounds were split over two days when interviewers had conflicts, and one interviewer arrived ten minutes late.
The DoorDash interview process, step by step
1. Recruiter call
A short call on your background and the process in most reports; one candidate's whole process ran over email, with no call.
One recruiter asked standard background questions and why DoorDash, with no behavioral questions, and moved the candidate on within a day or two. Another candidate had a second call with a different recruiter after the phone screen to book the onsite. Candidates describe detailed preparation material: one ML candidate got a full outline for the project deep dive, and in one February 2026 loop the guidance described the coding as coding with AI. In April 2026 one staff candidate who had passed a coding screen and a project deep dive was told the process had changed and a Code Craft round was now needed before the onsite.
- →Ask which rounds your loop has and whether AI is allowed in them. In the February 2026 loop the guidance mentioned coding with AI, but no round allowed it.
- →Expect slow handoffs and follow up when you hear nothing. One candidate's recruiter left the company mid-process, and the next recruiter took a month to book the onsite.
2. Code Craft phone screen
About 60 minutes with an engineer: one practical problem in runnable code, then production and design questions. Some screens give no starter code at all.
The most reported problem is Dasher Pay (20 reports), followed by the Bootstrap API (8 reports as a phone screen), which combines three upstream services and is mostly about handling their failures. Other screens in reports include a grid BFS to the nearest DashMart, validating a cart, a chef-and-dish profit problem and, for one staff candidate, a path key-value store. Statements are often vague, and candidates describe spending real time pinning down the data shape and the rules with the interviewer before writing code. Some screens supply test cases and expect you to add edge cases; others have no tests and no starter code, and in Java you write your own main method to run anything. Once the first part works, many interviewers add a peak-hour follow-up to Dasher Pay, while others skip it and spend the rest of the hour on production questions: very large input, an upstream service that is down or slow, duplicate upstream data and idempotency, retries, timeouts and circuit breakers. One candidate says the second half became almost a system design conversation. Finishing is not always enough: several candidates whose code ran were rejected, one of them an hour after the call.
- →Agree on the data shape, the rules and your approach before you code. One interviewer was clearly unhappy with a simple first version and pushed for a more efficient one, although the recruiter had said a working solution comes first.
- →Work out the expected output of your own test cases carefully. One candidate's code was correct, but they ran out of time on a wrong hand-computed expected value.
- →Prepare the production follow-ups out loud: upstream failures, retries with backoff, circuit breakers, idempotency for duplicate data and very large input.
- →If you use Java, practise building a runnable program from an empty file. Candidates lost time writing classes and a main method from scratch, and on concurrency they had not written recently.
3. Project deep dive (some loops)
About 60 minutes on one past project in the report that gives a length, often with slides; part of the phone screen for staff and ML candidates, and a separate round in some other loops.
Candidates walk through one project: the problem, their role, the methods, the hard parts, how they measured success and the trade-offs. One ML candidate got a detailed outline from the recruiter to prepare against and calls the round a useful exercise. Several candidates prepared slides, and one says slides were the key because the interviewer kept looking at them. The question that matters most, in that report, is what exactly you owned in a large system. Reports differ on the focus: a staff candidate was asked about scope, leadership and cross-functional work, while another candidate, who failed the round, thinks it cared more about the distributed system behind the project than about leadership. Candidates who felt the conversation went well were still rejected, some within two days.
- →Build a short slide deck for one project and rehearse it against the recruiter's outline.
- →Be precise about what you owned, not what the team built.
- →Pick a project with real system design in it. One candidate who failed the round thinks a distributed systems project would have done better.
- →For staff roles, prepare stories on scope, leadership and cross-functional work.
4. Onsite: AI Code Craft
In your own IDE with your own AI coding tool, sharing your screen; some candidates copy a starter skeleton out of HackerRank, others get no starter code.
The onsite is four virtual rounds, AI Code Craft, Debugging, System Design and the hiring manager, booked on one day or split over two or three. The most reported AI Code Craft task (13 reports) is the order refund workflow defined as a DAG, built as a running system. Several candidates stress that the interviewer wanted separate services, each on its own port, calling each other over real HTTP endpoints, not classes calling each other in one process; one candidate who assumed the second had to rewrite most of the code mid-round. Candidates describe building two to four services. Follow-ups add node types such as partial refunds and cancellations, ask what you would add from a product point of view, and ask how to handle repeated API calls or a slow workflow that keeps the user waiting. Some interviewers expect tests at each step, while one candidate says running the services mattered more than tests. In two reports the round ended with the AI agent summarizing the design, trade-offs and tests, and the candidate pasting that summary into HackerRank instead of uploading code. Loops from February to April 2026 had no AI round.
- →Set up and test your IDE and AI coding agent before the day. Two candidates recommend having a tool you know installed locally.
- →Ask what the interviewer wants built, how many services and how they talk, before you give the prompt to the AI. One candidate passed the prompt straight to the agent and later wished they had asked more.
- →Plan each step, read the AI's changes before accepting them, and keep each change small, though one interviewer kept urging a candidate to accept faster.
- →Be ready to explain which AI suggestion fits your code. One candidate got ten latency fixes from the AI and struggled to say which was workable.
5. Onsite: Debugging
One round on a given codebase with tests, without AI in the report that says; most often a round robin load balancer, otherwise a random Dasher picker.
Twelve reports name the problem: seven a round robin load balancer whose second part is consistent hashing, and five a random Dasher picker. You run the given tests, add prints and fix the bugs; candidates describe small bugs such as a typo in a string, a wrong loop and a missing initialization, and one says the hard part was the second part rather than the bugs. Interviewers then go past the failing tests: thread safety and where a lock belongs on the picker, how it would work as a distributed system, how to improve and scale it in production, and code-review comments on quality and conventions. Time is tight: several candidates only reached pseudocode or a skeleton for consistent hashing, one interviewer arrived ten minutes late, and another kept pushing the candidate to go faster. One October 2026 candidate got a different, longer object-oriented codebase with three failing tests.
- →Practise writing consistent hashing quickly after the round robin fixes. It is where most candidates ran out of time.
- →On the picker, once the logic bugs are fixed, move to the threading problems rather than hunting minor bugs.
- →Prepare both versions. One candidate prepared only round robin and consistent hashing and got the random picker.
- →Stay calm and read strings closely. One candidate lost minutes to a string missing one letter.
6. Onsite: System design and domain knowledge
One round, often opening with 15 to 25 minutes on a past project; 75 minutes in one report, including your past design experience.
The most reported prompt is a food item review system (11 reports), followed by a three-day charity donation event (3 reports). Other prompts in reports include a job scheduler, an alert notification system for downstream services, a data processing system and, in older or front-end loops, Instagram. Interviewers dig into the data model: several candidates describe long questioning on table schemas and APIs, how to stop a user voting twice, and how counts move between a cache and the database, and one candidate had not started the high-level design at 45 minutes because of it. One candidate notes that design rounds elsewhere rarely ask this much about schemas. On the donation prompt, one candidate was asked to include the payment service provider and to handle failed payments, network loss and duplicate requests. Interviewers vary: some give hints, while one let the candidate set the scale and said little else. The interface pairs a document tab for the prompt and requirements with a drawing tool one candidate found hard to use.
- →Prepare the food review design down to the tables, the voting rules and the path counts take between cache and database. It accounts for most reports.
- →Know how the parts you name work. One candidate was asked how retries on a message queue are implemented, and another had to explain how Temporal works after proposing it.
- →Write the functional and non-functional requirements in the document tab as you agree them. One candidate forgot and spent time catching up.
- →Agree early how to split the time, so detailed schema questions do not use up the round before the high-level design.
7. Onsite: hiring manager and Engineering Values
One round with the hiring manager, sometimes billed as Engineering Values plus an HM chat; 45 minutes in one report.
Several reports describe a few behavioral questions followed by close questions on the details, which two candidates compare to Amazon's behavioral rounds. Topics in reports include ownership and work you started yourself, its business impact and how you measured it, how you use AI at work (down to how much of your code AI writes and which models you use), a conflict, the biggest failure, what you would do differently on a project, feedback you received, a production problem you caused, and how performance and goals are set on your team. Some interviewers add a scenario: one candidate was told that support was seeing a spike in complaints about wrong deliveries across thousands of orders and asked what they would do. Styles vary: some managers read questions from a script with few follow-ups, and one staff candidate had rapid questions with about five minutes per answer. One candidate thinks this round, with debugging, cost them the offer.
- →Prepare fewer stories in more depth. One candidate was asked only two or three questions, each followed by many follow-ups.
- →Have a clear answer on how you use AI at work, including how much and with which tools.
- →Think through how you would triage a problem across thousands of orders without checking each one by hand.
- →Prepare four or five questions to ask. One round left plenty of time for them.
How the DoorDash loop differs by role
Staff
Staff candidates describe a phone screen of coding plus a project deep dive. One April 2026 staff candidate's coding was a path key-value store and the deep dive focused on scope, leadership and cross-functional work; they were then told a Code Craft round had been added before the onsite. A later staff onsite had four rounds: AI Code Craft, the food review design, an incident round and a 45-minute behavioral round. That candidate thought the incident round would be easy for anyone who has handled a serious production incident, and believes the design round was where it went wrong. Incident rounds also appear outside staff reports: another candidate's onsite included an incident analysis on a merchant pricing error.
ML engineer
ML engineer reports open with a project deep dive of about an hour, often with slides; one ML phone screen paired it with a system design round. One ML onsite had four rounds, each with a shadow interviewer: a hiring-manager round on resume and values, an ML domain knowledge round on the methods used in your own work, an ML system design for store recommendations, and the AI Code Craft round without starter code. Three of the four ML reports end in a rejection within two days, one without feedback as a policy.
New grad and entry level
One new grad loop had three rounds together: an interactive coding round about calling a given API correctly, with edge-case and latency follow-ups; a behavioral round on owned projects, bringing a project back on track and making sure every voice is heard; and a LeetCode-style interval merging round. The result came in about a week. An E3 backend candidate in Canada had a LeetCode-style variant of the Dasher question in the phone screen and was rejected two or three days later.
Earlier 2026 loops
Loops from February to April 2026 had no AI round: one candidate's guidance said coding with AI, but the interviewers had not heard of using it. Those loops had Code Craft as an onsite round in one report, debugging, system design and a short hiring-manager chat of about 20 minutes. One senior candidate in that period describes a Code Craft round where every field of a large nested expected result had to match character for character before moving on, and an interviewer who pressed on small mistakes such as string formatting. One April 2026 onsite had three rounds and no coding: system design, debugging and behavioral.
Frontend
In a 2025 front-end report the first round was a system design (Instagram), with many database questions in the deep dive.
After the final round
Results come from the recruiter, by email or a call, from the next day to about a week after the onsite in most reports that give timing; one candidate waited two weeks. Rejections usually come without feedback, and one ML candidate was told feedback is not given as a policy. One candidate who passed got a recruiter call five days after the onsite and signed the offer three days later; their skip-level manager said DoorDash rarely rescinds offers, but the immigration paperwork for a visa transfer took more than a month to file and the start date came about five months after signing. Another candidate who passed in September 2026 was preparing to negotiate. Through spring and summer 2026 candidates repeatedly mention a hiring freeze; some had interviews cancelled or saw the posting disappear, and others noticed recruiters still pushing loops forward while few offers were reported.
What does DoorDash ask in each round?
DoorDash interviews span 5distinct round types, shown below. Counts reflect distinct questions per round across the loops we’ve indexed.
- •Agreeing on the approach before coding. A candidate who passed the Dasher Pay screen advises talking the approach through with the interviewer before writing it.
- •Answering the production follow-ups in depth. A candidate who passed the Code Craft screen discussed backoff with jitter and circuit breakers for upstream failures.
- •Adding error handling once the basic version works. A candidate who passed the Bootstrap API screen, and later the onsite, says working code plus error handling was enough.
- •Preparing the reported problems. A candidate who passed in September 2026 says every round except the donation design matched earlier reports and was simple with preparation.
- •Building in-process classes in AI Code Craft when the interviewer wanted separate services calling each other over HTTP. One candidate had to rewrite most of the code mid-round.
- •Handing the prompt to the AI before asking the interviewer what they want built.
- •Running out of time on consistent hashing after slow round robin fixes in the Debugging round. Several candidates only reached pseudocode or a skeleton.
- •Letting schema and API questions use up the design round. One candidate had not started the high-level design at 45 minutes.
- •Hand-computing a wrong expected value for your own Dasher Pay test. One candidate's code was correct, but the time ran out.
How to prepare for the DoorDash interview
1. Write Dasher Pay and the Bootstrap API as runnable code
Together they cover most phone screens. Write each from an empty file in your language with your own tests, then practise the follow-ups out loud: upstream failures, retries, idempotency and very large input.
2. Build a small multi-service system with your AI tool
Practise the order refund workflow as separate services on separate ports calling each other over HTTP, in your own IDE with your own AI agent, and practise explaining what the agent wrote.
3. Debug an unfamiliar class against the clock
Fix a round robin load balancer and a random picker from failing tests, then write consistent hashing and add thread safety, all inside an hour.
4. Prepare the food review design in depth
Cover the tables, the voting rules, counters between cache and database, and the full read and write path; then the donation event, with failed payments and duplicate requests.
5. Prepare one project with slides, plus ownership stories
Know what you owned, the trade-offs and how you measured success, and prepare stories on ownership, AI use, conflict, failure and a production problem you caused.
FAQ
How long does the DoorDash interview process take?▾
What is DoorDash Code Craft?▾
What happens in the AI Code Craft round?▾
How many rounds are in the DoorDash onsite?▾
Can I use AI in the DoorDash interview?▾
Does DoorDash ask LeetCode questions?▾
Is DoorDash hiring, or is there a hiring freeze?▾
Which DoorDash rounds do candidates fail?▾
How fresh is this DoorDash interview data?▾
Get the full DoorDash catalog
Every question, every candidate-reported follow-up, and what passers actually do. Monthly refresh.