Companies · DoorDash

Companies

DoorDash

Prep plan for a DoorDash SWE loop. Interactive coding, AI code craft, and an engineering-values conversation.

1 min read system-design

Software Engineer Virtual onsite Remote

Interactive coding

60 minutes (about 50 on the problem) · Shared editor, live with an engineer. I write C++. No AI tools.

What's scored

  • Fundamentals, communication, and clarifying questions.
  • Problem solving and trade-offs.
  • Debugging, iteration, and extensible code.
  • Reliability: upstream failures, latency, missing data, HTTP status codes.

Checklist

  • Minutes 0–3: read every given class and run the provided test before writing.
  • Ask what a 500, a 404, and a timeout should do.
  • Keep pure logic separate from the fetch.
  • Add tests: empty, invalid, boundary, duplicate, upstream error.
  • State complexity and one extension.

Linked topics

Practice

  • Merge overlapping or touching intervals without std::sort. O(n log n) with my own merge sort.
  • Aggregator endpoint: one hard dependency (fail with 500), the rest soft (200 plus a degraded list). Call the soft ones in parallel.
  • Insert, delete, get-random in O(1): vector plus index map, swap-with-last remove. The bug is forgetting the last-element case.
  • Also drill: k nearest eligible Dashers, sliding-window rate limit, LRU with TTL that does not cache failures.

AI code craft

60 minutes (about 50 building) · Build from an empty directory with an AI coding assistant, screen shared.

What's scored

  • Problem solving, not pasting the prompt and walking away.
  • AI fluency: small prompts, context, reading the output.
  • Code quality and catching the corners the model skipped.
  • Communication and scope. Velocity matters. A running demo matters more than a perfect design.
  • Correctness under duplicates and near-simultaneous requests. Test coverage is not the grade. Running the system is.

Checklist

  • Minute 1: ask what must be running at the end and how you will demo it (curl, ports).
  • Copy the prompt into PROMPT.md. Write the decisions you clarified.
  • Something is running by minute 20. Demo a duplicate by minute 35.
  • One slice at a time. Read every diff. Commit when it is green.
  • Idempotency key stable across retries, checked inside the lock.
  • If you have seen the problem, or think the tool has, say so.

Linked topics

Practice

  • Rewards checker from an empty folder: a process that stays up, POST orders returns 202, duplicates do not double-count, a bad payload is 400.
  • Refund workflow: separate services, follow the chosen branch of the DAG, do not refund an on-time order just because it appears in a topological order, same idempotency key on the refund call.
  • Dispatch starter: read an existing small codebase, fix assignment bugs, then add decline and reassignment.

Engineering values

30 minutes · With an engineering manager. One or two stories with follow-ups, then my questions.

What's scored

  • Relevant experience.
  • Ownership.
  • Make room at the table (inclusion), in their words: the best idea wins and the person closest to the problem speaks.
  • 1% better every day: your own growth, and iterating on something you shipped.

Checklist

  • About 90 seconds, then stop. Say I, one real number, one lesson.
  • Tie the story to a customer: Dashers, merchants, or consumers.
  • Have a real inclusion story ready. Do not improvise one.
  • Bring two questions about the team.

Linked topics

Practice

  • One ownership story, one debugging story, one inclusion story, one failure story.
  • Say each out loud in under two minutes.

Coding round

Expect models, a mock upstream, and a service with a TODO. Read the given code and run the provided test before writing anything. Ask early whether built-ins like std::sort are allowed.

Status codes to have ready: 200, 201, 202, 204. 400 and 401/403 are not retried. 404 means I decide (often empty). 409 conflict, 422 validation, 429 retry after Retry-After. 500 maybe, 502/503/504 retry with jitter. A timeout is retried only if the call is idempotent or carries a key.

Partial failure in an aggregator: the identity call is fatal, the others return what they have plus a degraded list. Don’t hide a failure in a silent null.

AI code craft

Plan briefly, then build. The standard library is enough. An unordered_map behind a mutex is enough to demo correctness; say persistence was cut on purpose.

The trap in a workflow problem: topological order is not control flow. Follow the branch that was actually taken. A retried call uses the same idempotency key, not a new UUID per attempt. Return 202 if the work is slow and do it on a worker so the process stays up.

Narrate while the model runs. Read every diff. If I reject a line, say why. End with a short summary that only claims what I actually ran.

Values

About 90 seconds per story, one real number, one lesson. Tie it back to Dashers, merchants, or consumers. Don’t guess a metric.

Before the day

  • Screen share tested on the whole desktop, not a window.
  • g++ -std=c++20, git, and curl work offline. An empty scratch directory exists.
  • If full-screen share fails, share the editor and terminal one after another and say so.

Further reading

Check yourself

Answer the questions. Multiple choice is scored on this device only.

1. The ICR is best prepared as:

2. A refund DAG says: if the order is late, refund. A topological execution of every node will:

3. What has to be true of a duplicate order in the AI code craft round?