DoorDash AI coding interviews: format, example tasks, and how to prepare

What the interview looks like

DoorDash’s March 19, 2026 announcement describes a 60-minute engineering session using starter code, your own computer, and integrated AI tools. Agent modes are allowed. You share your screen and explain your work. DoorDash’s engineering interview announcement.

DoorDash’s general policy, dated October 9, 2025, says live AI use requires explicit permission. Read the later engineering announcement as a defined format, not authorization for every behavioral, design, or other interview. Ask your recruiter which rounds use it and follow the candidate guide supplied with your invitation. DoorDash’s general AI interview policy.

Example tasks DoorDash has published

The announcement names three possible task areas: extending order dispatch, composing menus, and automating support resolution. These are examples of work candidates might receive, not complete questions or a guarantee about your interview. DoorDash’s published examples.

Use those areas to ask concrete engineering questions in practice. What happens when the same request arrives twice? How should the system represent an unavailable item? Which support actions can be reversed? Those follow-up questions are ours. Their value is in taking a broad feature request and finding the rules that determine whether a solution is useful. You can practice that reasoning without guessing an employer’s exact prompt.

Set up your editor before the interview

Before practice, verify your editor, terminal, language runtime, package manager, assistant login, and screen sharing. Open a small unfamiliar repository and run its documented test command. Check that you can see and stop an agent’s running commands, inspect its diff, and reject a change. Tool familiarity should include recovery from a wrong action, not only accepting a successful completion.

Use the setup you already know. A last-minute switch to a new agent or language adds something else to troubleshoot under pressure. If the assistant stops responding, explain what happened and continue with the smallest part you can complete yourself. Keep the requirements somewhere you can read without reopening a long chat history.

Try a pickup status exercise

Practice with a small service that receives readiness updates for a pickup. Each update contains a pickup ID, an integer revision, and a status: preparing, ready, or cancelled. Events can arrive out of order or be repeated. Build a function that updates the current state and requests a notification only when a pickup first enters ready.

This is an original nrml exercise. Keep the first version in memory and return a notification record instead of sending a real message. For an existing project to work on, try Rebuild State from Out-of-Order Events. It covers duplicate deliveries and stale versions, the same problems that make this status exercise interesting.

Decide which updates the system should accept

For this exercise, require a positive integer revision and a recognized status. A new pickup accepts its first valid update. An existing pickup accepts only a greater revision; equal or smaller revisions leave state unchanged. Cancellation is terminal, even if a later message has a higher revision. Ready can become cancelled but cannot return to preparing. Write these rules down so you can check generated code against them.

When an accepted update changes preparing to ready, return one notification intent. A first update that is already ready also returns one. Replaying the same update must return none. Keep state and intent together in the function’s result so tests can verify their relationship. In this initial model, each call is processed serially; concurrency and durable delivery are separate extension topics.

Ask AI for one change at a time

Before editing, find the request handler, state model, and nearby tests. Read how the application reports a malformed request. Then give the assistant the relevant files and your update rules. Ask it to implement the transition function before wiring up the route. This gives you something small enough to read and run while there is still time to correct a misunderstanding.

Watch for useful-looking changes that take the exercise in the wrong direction. If the model starts building a messaging framework, stop it and explain why a returned notification record is enough for the current requirement. You should be able to explain the next change in one sentence. If you cannot, narrow the request before asking for more code.

Inspect the pickup handler, state model, and focused tests.
Implement a pure transition function using the supplied revision rules.
Return the next state and any readiness notification intent together.
Preserve existing request/error conventions and avoid real side effects.
Add focused tests, then report the diff and exact checks run.
Do not add a database or messaging framework.

Check duplicate and delayed messages

A function can pass isolated examples and still fail when messages interact. Trace preparing at revision 1, ready at revision 3, and a delayed preparing at revision 2. The final state must remain ready, and there must be exactly one notification intent across the sequence. Then replay revision 3 and verify that nothing changes.

Try ready at revision 1, cancelled at revision 2, and ready at revision 4. The cancellation must remain terminal under this exercise’s contract. This is where a plausible implementation often fails: it checks revision freshness but forgets transition eligibility. Read the branch order yourself and ensure rejected updates do not silently consume a revision or overwrite a meaningful status.

Test state changes and notifications together

Build tests from the contract before inspecting the assistant’s proposed expectations. Include an unknown pickup, identical replay, lower revision, equal revision with different status, terminal cancellation, and malformed revision. Check both next state and notification output. Testing only the final state misses an implementation that returns the same notification on every replay.

Add an immutability check if the function promises not to alter its inputs. Include a second pickup to catch accidentally shared state. For a rejected event, verify that the old revision survives; otherwise a bad high-revision message could block a later valid one. Name each test after the behavior it protects so an interviewer can understand a failure without reading the whole suite.

What if the notification fails?

After the first version works, introduce a realistic extension: the notification operation can fail. Explain that returning an intent does not guarantee its delivery. For the rehearsal, add a fake delivery queue and separate enqueueing from attempted delivery. Keep a stable notification identity, such as pickup ID plus the accepted ready revision, so repeated delivery attempts can be recognized.

Be precise about the limit. An in-memory queue can demonstrate retries but cannot survive a process crash. A production design would need durable storage and an atomic relationship between state changes and queued work, plus a delivery policy. Discuss that boundary without claiming to have implemented it. A small complete improvement is easier to defend than an unfinished persistence rewrite.

Make Payment Webhooks Idempotent gives you another setting for practicing repeated requests and conflicting identities. Work through it after the pickup exercise and explain which rules carry over. Payments and notifications have different consequences, so the point is to recognize the duplicate-work problem while still reading the new requirements carefully.

Leave time to run the code

For a one-hour practice session, try ten minutes for orientation and contract, thirty for implementation and targeted debugging, fifteen for verification, and five for a handoff. This schedule is nrml’s recommendation, not an official DoorDash allocation. Adjust it when the starter environment needs less setup or a requirement exposes a deeper ambiguity.

You do not need to narrate every keystroke. Speak when you learn something or change direction. If a test fails, read the mismatch before asking the assistant to fix it. “The stale update is overwriting state before the guard runs” is useful to both your interviewer and the model. “Something is broken, fix everything” gives neither of them much to work with.

Explain what works and what is unfinished

Demonstrate an out-of-order sequence and a duplicate, then summarize the accepted behavior, tests, and remaining limitations. Say whether integration checks actually ran. If you only verified the pure function, do not imply that an HTTP route, queue, or database is also proven. Your final explanation should match the code and evidence visible on screen.

If you have time for another practice session, introduce two workers handling the same job. Stop Double Claims in the Job Scheduler is a useful next exercise because it adds expiring leases and ownership checks. That moves beyond the serial processing assumption in the pickup example and gives you a concrete way to discuss what changes when work becomes concurrent.