Why DoorDash is rebuilding its engineering interviews around AI

For years, software engineering interviews have had a strange relationship with actual software engineering. 

The daily job is highly collaborative and involves reading existing code, debugging, writing tests, working across interfaces, and communicating clearly. 

Traditional interviews, on the other hand, put candidates in a timed, isolated setting and reward algorithm drills that rarely show up in actual production work. 

That mismatch was tolerated because success in those algorithmic interviews was hard to fake  and was loosely correlated with computer science fundamentals.

AI coding assistants changed the equation. 

When a standard interview prompt can be solved in seconds, the interview either turns into proctoring or a shared pretense that engineers don’t use AI tools at work. But DoorDash is building an AI-native engineering organization. And so we made a straightforward decision: Our interview process must reflect the work our engineers actually do.

AI makes the old format obsolete 

If a model can instantly generate a correct solution, the challenge shifts from engineering skill to performance theater. Candidates self-select into excessive prep and memorization. The process of policing "cheating" becomes trivial; detection becomes an arms race. Great engineers opt out because the process does not respect how they actually work. 

We aren’t interested in winning an arms race. By removing the artificial prep barrier, we’re optimizing for people who want to build, ship, and own outcomes rather than those who want to memorize binary tree traversals.

We want to evaluate production-relevant skills

In production, you rarely start from a blank file. You inherit systems, ramp into unfamiliar codebases, and make changes with incomplete context. You collaborate, ask questions, form hypotheses, test them, and ship incrementally. AI tools are a massive force multiplier, but their value comes from how you use them. You can’t expect an AI agent to be successful if you haven’t explained exactly what success looks like.

The skills we care about include:

• Getting unblocked in an unfamiliar domain: Can you dive into a new codebase, build a mental model quickly, and find your way forward without hand-holding?
• Making pragmatic tradeoffs under constraints: Can you weigh architectural choices with real-world DoorDash complexities in mind — for example, the impact on merchants, Dashers, and consumers?
• Turning ambiguity into an executable plan: Can you take a high-level requirement and break it down into a clear sequence of technical steps?
• Validating with rigor: Can you create a minimal repro, read the logs, and write targeted checks to prove a fix works, rather than blindly trusting an AI output?
• Communicating the why: Can you clearly narrate your reasoning, taste, and tradeoffs while you work?

What our new format looks like

We are replacing traditional coding rounds with a 60-minute, AI-assisted engineering working session. You join a realistic project, ramp up, and start contributing.

Here is what to expect:

• Use your own environment: You will work entirely on your personal machine using your preferred integrated development environment, or IDE. 
• Show the full loop: We ask that you use integrated AI tools, including an editor-integrated assistant, because we need to see the full loop — editing, running code, debugging, and iterating. Free-tier options for all mainstream AI coding agents, such as Cursor, Claude Code, and Codex, are sufficient.
• Use the full feature set: All features can be used, including chat, inline suggestions, planning, agent/autopilot modes, and running commands through the tool. We want to see you use the tools to their full potential.
• Address practical tasks: We provide starter code in your preferred language and a task that looks like actual DoorDash work. You may be asked to implement and extend an order dispatch system, build a smart menu composer, or automate a support request resolution system.
• Show your work: During the session, you will share your screen and narrate what you are doing, what you plan to try next, and why. Clear communication is essential. 

We score the session on a small set of signals: How you get oriented, how you use AI and verify outputs, how you debug, how you manage scope, and how you communicate tradeoffs. Finishing every task is less important than showing a tight loop and good judgment, although velocity does matter.

What change taught us

We did not get the format right immediately. Running pilots altered our approach. Among our discoveries:

• Scope matters more than cleverness: We initially developed a microservice-based interview question called the Order Management System. Candidates extended a system with three services — order, fulfillment, and a message bus — in a larger codebase. While this produced useful signals about service boundaries and architecture, it was too ambitious for a standard 60-minute interview. Many candidates needed 15 to 20 minutes just to explore and understand the code.
  • As a result, we moved to smaller, focused projects so candidates can spend most of the hour doing engineering work rather than mapping a large system.
• Setting expectations can be key: If we didn’t tell candidates in our early pilot what to expect, many arrived with little to no experience using AI-assisted tools. As a result, they arrived unprepared, without a configured IDE, or believing that the use of AI to its fullest potential was somehow "cheating" (yes, you are allowed to one-shot problems).
  • We now send a detailed candidate guide that sets expectations up front, including the requirement to arrive with a working setup and the comfort to use AI during the session.
• Interviewers need to step up their game, too: This format cannot be graded with a simple rubric that checks for the right output. Interviewers need to assess workflow, including tool use, a candidate’s approach to debugging, judgment, and communication under real constraints.
  • To foster this, we invest in interviewer training and treat it as a hiring advantage, because evaluation quality depends on the person running the session.

Come build with us

We are hiring for real-world engineering, not puzzle-solving. Interestingly, our new interview format also allows engineers with non-traditional backgrounds to truly shine. Whether you come from a non-CS rigorous discipline like physics or math, or started your career in an adjacent role like data engineering, AI tools help close the execution gap. The true differentiators are what you bring to the table: Your decision-making, your system-level reasoning, and your ownership.

If you want to ship meaningful products quickly, work across the stack without artificial boundaries, and use the best tools available, your interview now is designed to reflect that. Landing a job here means doing what you already do at work.