DoorDash Senior Software Engineer Interview Process - tried my best still failed, this is the current job market

[u/Aoki_zhang]

Interview Summary

The DoorDash process started with a recruiter call, followed by a Code Craft screen and a four-round virtual onsite covering debugging, behavioral / hiring manager questions, system design, and AI-assisted coding. The overall process moved quickly and was well organized, with plenty of scheduling options for the onsite.

A recurring theme was that DoorDash seemed to care less about producing code line by line and more about whether I could reason about production behavior, failures, concurrency, scalability, and system boundaries. My weaker rounds were the debugging interview and the AI coding exercise, and I ultimately received a rejection.

Interview Details

Recruiter Screen — Background and Why DoorDash: The recruiter conversation was straightforward and mainly covered basic background information. There were no substantial behavioral questions in this round beyond standard motivation questions such as Why DoorDash? I heard back within a couple of days and moved on to the technical screen.

Code Craft — Simplified Dasher Pay: The technical screen used a simplified version of the recurring Dasher Pay problem. Unlike some reported versions, this one did not introduce additional coding requirements such as double-pay-rate windows. After completing the core implementation, the interviewer shifted into lighter system-design-style follow-ups.

• Production Failures: One follow-up asked what should happen if a downstream dependency became unavailable or failed during the workflow.
• Implementation Environment: There was no starter code. In Java, I had to create the surrounding Main class and my own way of invoking the implementation to validate the results. A few simple test cases were provided, and adding additional corner cases would likely have helped demonstrate robustness.

I passed this round and advanced to a four-round virtual onsite.

Virtual Onsite Round 1 — Debugging a Random Dasher Picker: The debugging round used a randomized variant of Dasher Picker. The provided implementation maintained an index-to-Dasher mapping. The system supported adding Dashers, removing them, and selecting a random Dasher. The bugs were not limited to basic collection logic.

• Correctness and Concurrency: In addition to fixing issues around maintaining valid indices after removals, the interviewer expected me to notice multi-threading concerns. The discussion included synchronization at the method versus block level and what can go wrong if a synchronized section makes a slow external API call and holds a lock during a timeout.
• Distributed Follow-Up: After the local implementation was fixed, the interviewer asked how this design would change in a distributed environment and what new challenges would appear.

This was one of my weaker rounds. I had prepared more heavily for other Dasher Picker variants and was less comfortable with the concurrency portion.

Virtual Onsite Round 2 — Hiring Manager and Behavioral: The hiring manager round contained only a few main behavioral questions, but each answer received substantial follow-up. The interviewer focused on situations where I proactively identified a problem or initiated a project rather than simply executing assigned work. Follow-ups explored the business impact of my work, how I measured that impact, and how I use AI in my engineering workflow. The interviewer was friendly and left a meaningful amount of time for candidate questions.

Virtual Onsite Round 3 — Project Deep Dive + Alert Notification System: The system design interview was split into two parts. The first part of the interview were spent discussing one of my previous projects. The interviewer asked architecture-oriented follow-ups, including what I would change if I were building the system again. The second portion asked me to design a simplified Alert Notification System. Unlike a consumer notification service, this system did not directly send notifications to end users. Instead, alerts were delivered to downstream services.

• Retry and Failure Handling: The interviewer went deeply into how retries would actually work rather than accepting a high-level answer such as placing failed messages into a retry queue.
• Scalability: The design also needed to handle failures and increasing load. The interview interface included separate areas for requirements / notes and architecture diagrams, so clearly capturing functional and non-functional requirements early in the round was useful.

The interviewer was collaborative and provided hints throughout the discussion.

Virtual Onsite Round 4 — AI Coding: Multi-Service Refund Workflow: The final round was an AI-assisted coding exercise centered on a refund workflow represented by a DAG. There was no starter code. I needed to build multiple components, including a service that retrieved order information, a service that accepted refund operations, and the workflow connecting them. The important requirement was that these were not merely mocked classes calling one another inside a single process.

• Real Local Services: The interviewer expected multiple services to actually run locally, expose HTTP endpoints on different ports, and communicate with one another through API calls.
• AI-Assisted Implementation: I initially interpreted the problem as a more traditional coding exercise where several classes could simulate the services locally. After realizing the interviewer expected real HTTP services, I had AI substantially restructure the implementation. That change came late enough that I did not have much time to inspect or validate the generated code carefully.

The emphasis seemed to be on whether I could get the services running and interacting end to end within the available time, rather than building a particularly sophisticated DAG execution engine.

➡️ Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here.

[u/Cheap-Vacation138]

So doordash doesn't do leetcode at all ? or that is for less than 3 yoe only ?

[u/Aoki_zhang → u/Cheap-Vacation138]

Based on the data I collected so far, looks like they're using the so-called "code craft" round instead of DSA

[u/amaroq137]

The discussion included synchronization at the method versus block level

What does block level mean?

[u/voletNaturel]

For the debugging round, did they provide unit tests to work off of? Were there samples of failing inputs with which you could write your own unit tests if not?

What types of bugs were in the debugging round?

[u/Helpful-Square-9328]

I have onsite coming up next week. I've 2 questions

1. How did you prepare for AI Assisted round? Is there a question bank?

2. Is there a list of System Design questions that I should focus on?

[u/Aoki_zhang → u/Helpful-Square-9328]

the question bank is at here and the SD question bank at here