Why candidates walk out confused
Almost every report ends the same way: the code worked, the tests passed, and the candidate has no idea how it went. One said the interviewer kept asking whether they use AI at work while they were still reading the starter code. Another was questioned for using agent mode with "do not generate code yet" instead of plan mode. A third had the assistant produce ten options for the latency question and lost the room explaining them one by one.
Our read: DoorDash is not grading whether you can build a workflow engine. Every report agrees the assistant can build it. It is grading the loop around the assistant, and grading it against the clock. Understand the requirement with the interviewer, read the starter, plan, delegate one small piece, read the diff, run the tests, say what you are accepting and why, move to the next piece. Candidates who skipped the first step built the wrong thing quickly. Candidates who did every step slowly ran out of time. The round wants both at once, which is hard, and that is the point.
What the task actually is
You get starter code for a workflow engine and a description of late-order refunds. The workflow is a small directed graph written in a text file: a start node, a check of whether the order is late, a refund node on the yes branch, an end node. The node implementations are not written. Your job is to parse the definition if the starter does not, execute it for an order, and issue the refund through a mocked payment call.
The trap the reports keep pointing at is execution order versus branch selection. A topological order tells you when a node may run. It does not tell you whether it should. Run every node in dependency order and on-time orders get refunded too, because both sides of the check ran. An assistant asked to "execute the DAG" produces exactly that more often than you would like, and the interviewer is waiting to see whether you notice.
Then the follow-ups. Partial refunds appear in nearly every report: refund half for moderately late orders, refund the items that never arrived. A cancel step shows up in one. Then the questions that are really system design: what happens if the refund API is called twice for the same order, and how do you make the customer stop waiting for all of this. The answers are an idempotency key that does not change across retries, and accepting the request at once while a worker runs the workflow. Some interviewers want them implemented, some only discussed.
The variant that catches people out
Since August 2026 a second version starts from an empty repo. You still build a refund workflow over a graph, but the order lookup and the refund endpoint are your services too, each on its own local port, talking over real HTTP. One candidate built classes calling each other in one process, learned late that the interviewer wanted separate running services, and had to let the assistant rewrite everything without time to read it. That was the round. Ask in the first minute what has to be running at the end, and what you will demonstrate with curl.
What is confirmed, and what is not
- Confirmed: your own IDE and AI assistant on a screen share; a workflow engine for late-order refunds over a graph declared in text; starter code with the node logic missing in most loops; partial refunds as a follow-up; questions on repeated refund calls and on latency; velocity as an explicit grading point. Each is in several independent reports.
- Reported once or twice: a cancel node; a decision tree framing for an MLE loop; the three-service HTTP version; pasting the assistant's summary into HackerRank at the end.
- Not known: the rubric and the bar. Several candidates with working code and passing tests were rejected without feedback, and reports describe DoorDash as needing every round to go well.
How we would prepare
- Build the engine once before the interview. Parser, graph, an executor that decides per edge which branch is taken, a handler per node kind. Not to memorise it, but so that when the assistant writes it you can read it in thirty seconds.
- Practise the loop out loud with a timer. Read, plan, delegate one piece, read the diff, test, narrate. Fifteen minutes for the core path from an empty file is the pace the reports imply.
- Know your idempotency answer cold. A key derived from the order and the step, the same on every retry and every rerun. A random key per call turns a lost response into a double refund.
- Have the latency answer ready in one sentence. Accept and acknowledge at once, run the workflow in a worker, expose a status. Then stop and let the interviewer pull.
- Rehearse the service variant. Two or three tiny HTTP services on different ports, one calling the others, shown working with curl. It is a different muscle from writing classes, and the August candidate who had not practised it did not recover.
Nyrion's DoorDash section starts with Refund Workflow Engine, built from these reports. The starter parses the workflow files and leaves running them to you. Partial refunds and cancel come next. Then the payments service starts timing out, sometimes after applying the refund. The last part accepts orders at once and refunds later. The core and the partial refund are what candidates describe; the failure script and the queue are our way of making the idempotency and latency questions something you can run. We do not clone the HTTP service variant, since our sandbox runs plain Python.
How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.
Frequently asked, briefly answered
Which AI tool can I use?
Your own. Candidates used Cursor, Copilot, Claude Code and Codex in their local IDE. The prompt usually lives in HackerRank and you copy the starter code into your editor. Install and sign in before the call; several candidates lost the first minutes to setup.
Is there always starter code?
Usually. Most reports describe a skeleton workflow engine with the node implementations missing. Since August 2026 some loops start from nothing and want real HTTP services on separate local ports, an order service, a refund service and a workflow service calling each other. Ask in the first minute which version you have and what has to run.
What are the follow-ups?
Partial refunds come up in almost every report. Others: a cancel step, what happens if the refund API is called twice, and how to stop the customer from waiting while the workflow runs. Expect to implement the first one and talk through the others, sometimes with the assistant's help.
Should I write the code myself?
No. The round is graded on how you use the assistant, and interviewers push for velocity. But do not pipe the prompt straight in either: the candidate who expected the biggest deduction had accepted a large change with no time to read it. Plan, delegate a small piece, read it, run the tests, repeat.
Do I need to write tests?
Usually yes, and usually generated by the assistant. The graded part is reading them: interviewers call out generated tests that only cover the happy path. In the from-scratch service variant, getting the services running end to end matters more than the test suite.
What else is in the loop?
A Code Craft phone screen first (Dasher Pay or the bootstrap API aggregator, no AI), then four onsite rounds: AI Code Craft, a debugging round on a dasher picker or load balancer, system design (food reviews, donations, notifications), and a hiring manager round that now asks how you use AI. Reports say every round has to go well.
Practice problems tagged for DoorDash
Browse the catalog and open the DoorDash section. No login required to look; sign in when you want to solve one.