DoorDash Software Engineer Interview Experience — Five Onsite Rounds Including a Live AI Coding Challenge

Round 1 — Code Craft: Bootstrap / Aggregator API

Problem
You are tasked with implementing an API that exposes the required information and is as resilient to failures as possible in order to ensure a good user experience.

Implement a Bootstrap API that takes a user_id, pulls information from three existing upstream services — Consumer, Payment, and Address — and combines it into a single response. Boilerplate and mock services are provided.

user_id and consumer_id are different identifiers. The code needs to run and return the expected result while tolerating upstream failures as much as possible. If Consumer fails, it's fine to return 500. If Payment or Address fails, whatever other information is available should be kept.

Questions and follow-ups

• Briefly introduce yourself. Does the system you're describing serve only the US, or globally?
• Explain what this API does. In what order are the three upstream APIs called?
• In a real scenario, how do you handle timeouts? On timeout, do you retry or discard?
• Besides catching exceptions, did you check the response status code, e.g. 500?
• Does every upstream failure have to return 500? If partial information is still available, should it be shown?
• What should be returned if user and payment succeed but address fails? What if both payment and address fail but user info is still there?
• Run the code and check the result. Why did it return 500? Are there similar issues elsewhere?
• Does the address include the first name / last name from the expected response?
• Test scenarios where the user service and other upstreams each fail individually, and check the returned status and remaining fields.
• You can look up the actual API, but say what you're checking first. Retry logic can be expanded after the basic implementation is done.

Round 2 — Systems Design & Domain Knowledge

Problem: Food / Menu Item Reviews
Design a review system for menu items in a food delivery app. The page shows the item name, image, rating, and reviews. Users who purchased a given item can write a review, and can upvote/downvote other users' reviews; the system displays the review list and the item's average rating.

A later extension could pay users out based on their upvotes/downvotes, but this round is P0 only: show the item, post a review, upvote/downvote.

On-site conditions:

• Scope simplification: don't get into multiple restaurants or a menu hierarchy — assume one restaurant, one menu, multiple items.
• Rating: item rating is a 0–5 value, shown as stars on the page; no need to model the frontend display.
• Average rating: the average of all of an item's ratings.
• Vote: upvote/downvote on a review is a separate concept from the item's rating.
• Review uniqueness: confirmed on the spot that each user keeps one review per item.
• Voting behavior: only one choice at a time, but switching from upvote to downvote is allowed.
• Review volume: interviewer set it at roughly 10,000 reviews/day.
• Vote/rating traffic: discussed in millions of requests per day for each — not millions of QPS.
• Read/write ratio: reviews are read-heavy; ratings can't be treated purely as reads — the interviewer put read/write at roughly 50/50.
• Display: discussed review sort order, showing a small number of reviews first, and displaying upvote/downvote counts.
• Payout: mentioned only as a future direction, not expanded — no specific amounts, trigger rules, or payment design.

Project deep-dive

• Tell me about your current work. Do you know what DashPass is?
• Pick a project and talk about the most complex technical part.
• What important design trade-offs did you make? What was the decision process? Can you go deeper on the technical details?

System design follow-ups

• How big is "large scale" specifically? Estimate the request volume and read/write ratio for reviews, votes, and ratings separately.
• Do reviews need sorting and pagination, showing the first five first?
• When writing a review, does the item rating also need to be updated?
• How do you store and display upvote/downvote counts? Are there other ways to store counters?
• What Redis command specifically would you use for the counter, and what does the update look like?
• How do the cache and database get updated? Does the read path go through Redis or the DB?
• How does Redis behave under high traffic? What eviction policy would you use?
• If a counter gets evicted before it's written to the database, would that lose data?
• Do the review table and the user-review table duplicate each other? Can the data model be optimized?
• What exactly does the user-review table record? Give an example of a user voting on multiple reviews. Why is this table needed?
• How do you restrict a user to one vote and still support changing it?
• Relational or non-relational database for each table? If the vote table gets very large, is querying or scanning by review ID reasonable?
• Even with Redis aggregating, there are still plenty of counter writes hitting the database — how do you absorb that?
• Draw out the full read/write path, including the entry point, the components it passes through, and which databases get updated.

Round 2 — Hiring Manager / Values / Behavioral

Scenario question
Say you're at DoorDash and a manager comes to you and says customer support is getting a flood of complaints about orders being delivered wrong. That's all they give you before they leave. What do you do next?
Follow-up: this isn't one order, it's a surge of complaints across thousands of orders. DoorDash's overall delivery volume is huge, and there's no way to check thousands of orders one by one. How would you handle it?

Behavioral questions and follow-ups

Opening: Briefly introduce yourself.

AI coding use: How do you use AI at work? What percentage of the code you write is AI-written? Besides coding, where else do you use AI?

Users of the AI tool/agent: Is the AI tool you described for your own team's use, or for other teams to learn about and use your system?

Who initiated it: Was this a task assigned by your manager, or something you started on your own?

Model identification: Which LLM did you use? Which model was used for summarizing content?

Model choice: Do you pick models per task, or always use the company default? Do you use different models for coding, or mostly the same one?

Cost: Does the company have a token cap or budget? Do you personally cover part of a subscription fee?

Most proud-of project: Pick a recent project you're most proud of. What was it, why did it matter, what was your role, what impact did it have? Keep technical detail to a minimum — focus on the non-technical side.

Quantifying impact: Was the main impact saved on-call time? Without this improvement, how much extra on-call time would there be per week?

Where it came from: Who proposed the project — PM, manager, or you?

From prototype to production: The interviewer confirmed the path from side project/prototype, to proving impact, to the PM taking it over. After the PM took over, was it still your project? Did you keep participating and maintaining it?

Staffing: Did other engineers work on it? Was the person who helped senior or junior?

Cross-functional collaboration: Did you actually interact with frontend engineers and give input, or did they just work off the PM's spec? How did the early prototype transition into the later implementation?

Disagreement with a colleague: What disagreement did you have with a peer? What specifically was it? How was it resolved?

Testing responsibility: If there's no QA, do you have to test it yourself? How did you validate it?

Production incident: Have you ever caused a major production issue yourself? What was it? How did you resolve it?

Validating at scale: If there are many migration tasks, are you planning to review them one by one manually? That doesn't scale — how would you test it?

Migration health: After the migration, did you check whether the pipeline was healthy? When output/activity dropped to zero, why wasn't there an automatic alert?

Alerting gap: Is the lack of alerting a gap, or was there a good reason? This kind of alert should go to whoever owns the migration, not rely on business users noticing — is making sure things stay healthy after a migration your responsibility?

Constructive feedback: What constructive feedback have you gotten from a manager or peer? How did you respond?

Growth goals: What personal goals are you working on for growth? Prioritize work-related ones, though personal goals are fine too. The interviewer understood you want to improve your architecture skills — what specifically are you doing to improve it?

Diversity: Does team diversity matter to you? Different backgrounds and perspectives can have upsides and downsides — what's your take?

Questions for the interviewer: What do you want to ask? When a question was too broad, the interviewer asked me to be more specific about what I wanted to know about how the team works.

Round 2 — Debugging: DeliveryAssignmentService

Problem
Given DeliveryAssignmentService, which randomly picks a Dasher to assign a delivery to, find and fix the bugs, design issues, and code quality problems in the existing code.

dasher_map stores Dashers, with keys starting from 0 and increasing consecutively. add_dasher adds a Dasher. pick_dasher randomly picks and removes one Dasher. adjust_map adjusts the keys after a removal, by filling the gap with the last element. The external RemoteDeliveryRecordingService can be assumed to work correctly.

The fix must preserve each function's original time complexity — it can't turn into a full scan of the map.

Follow-up
If this were a PR review, what else would you change? Are there other code quality, convention, or best-practice issues?

Round 2 — AI Code Craft: Order Status and Refund Workflow

Original prompt
At DoorDash, when something goes wrong with an order — delayed, lost, undelivered — support agents need to respond consistently. We want a system that can evaluate an order's current state and automatically decide what action to take: issue a refund, close the request, escalate, etc.

Our system would function by querying a real API that you build to represent order status, checking the order status, and following a rule set defined as a directed acyclic graph to make a decision.

An example DAG could look like this:

Start Node
↓
Check if the order is late?

• Yes → Issue Refund → End
• No → End

Build a working end-to-end system. At minimum, it should handle a late order triggering a refund. Keep it simple — a working demo matters more than polish.

The system should use real API calls between components and keep running continuously — not just execute once — so it can be observed live.

This is unreleased interview content. If you or any tool you're using — including AI assistants — has prior exposure to this exact problem, you're asked to say so before starting.

What they care about:

• Working end-to-end system
• Reasonable scope decisions under time pressure
• Using AI effectively to accelerate implementation
• Components that interact as separate systems

Less important: perfect abstractions, elaborate class hierarchies, low-level polish.

Use any language, framework, or AI tool you prefer.

Additional requirements and follow-ups

• Use your own IDE, share your screen, and build the system through an AI coding agent.
• The minimum goal is a late order automatically triggering a refund; other branches of the decision tree can be extensions. No need to actually move money, but you do need to show the refund request being triggered.
• How do you define an order, a delayed/lost/undelivered order? What does "dependency" mean in the DAG?
• Are you writing the prompt for the AI right now, or building it yourself first? What's the plan?
• Why make this design change? Can you describe it to the agent and have it done?
• Can the system actually run, exposing an API/gRPC interface you can test by hand?
• Run curl yourself and explain what the response means. You can have the AI generate the commands.
• Did you get blocked on anything? Did the tests run as expected? Can you show the refund being triggered?
• At the end, have the agent summarize the problem, design decisions, trade-offs, testing, completion status, and architecture, then paste the response into HackerRank.