← Back to Directory

DoorDash interview notes, page 34 of 42

Large Enterprises

Most of these DoorDash write-ups come from Software Engineers (265), then Data Scientists (69) and Product Managers (52). The most reported rounds are the technical phone screen (201), the system design round (93), the product sense round (55) and the behavioral / leadership round (36).

416 interview notes · updated Oct 2026

DoorDash·Data Scientist·Technical Phone Screen

Jun 2026
DoorDash data science interview with a meaty product analytics case about a mobile app pop-up tanking partner-channel conversions. One question but it had a lot of moving parts and I felt like I was chasing my tail a bit trying to structure it on the fly.
  • After a new mobile app download pop-up was added, first-time purchases from the partner-referral channel dropped sharply. How would you confirm the pop-up caused this, quantify the trade-off between app installs gained and orders lost, and design an experiment to decide whether to keep, modify, or remove it?

“I started with the funnel mapping which felt right, but I got a bit tangled when they pushed on how to separate the pop-up effect from seasonality and partner mix shifts.”

View Post

DoorDash·Machine Learning Engineer·Technical Phone Screen

Jun 2026
Behavioral and technical mix for an MLE role at DoorDash. The conversation covered hands-on LLM work, a resume walkthrough, and a pretty open-ended discussion about what research directions you actually care about and why. Felt more like a vibe check on depth than a grind-through-leetcode situation.
  • Walk us through your hands-on experience with LLMs, covering training, fine-tuning, prompting, and deployment.
  • Which LLM research directions do you find most interesting, and why?
  • Take us through the highlights of your resume.

“This is where I spent most of the call.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash coding round, one algorithmic problem about scheduling deliveries for maximum profit. Pretty much a classic DP problem dressed up in DoorDash-flavored context, which I thought was a nice touch even if the underlying idea wasn't new.
  • Given a dasher's shift window defined by a start and end time, and a list of candidate deliveries each with their own start time, end time, and payout, find the subset of non-overlapping deliveries that fits within the shift and maximizes total profit.

“I recognized the weighted job scheduling shape pretty quickly, which felt good.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash software engineering interview with a system design coding problem around consistent hashing. Pretty implementation-heavy for what felt like a technical phone screen, and the complexity requirements made it clear they wanted more than just a working solution.
  • Implement a ConsistentHashRing class that distributes keys across servers using a hash ring with virtual nodes. The class needs add_server, remove_server, and get_server methods, with get_server wrapping around the ring if no node is found at or after the hashed key position.

“The virtual node part is where most people trip up and I was no exception.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash technical phone screen for a software engineer role, basically one meaty grid traversal problem with a couple of follow-ups tacked on at the end. The core question wasn't too bad but the extensions pushed into territory I wasn't totally prepared for.
  • You're given a 2D grid where cells are either walls, exits, or empty rooms. Fill each empty room with its shortest distance (using 4-directional moves) to the nearest exit. If a room can't reach any exit, leave it unchanged. Walk through your approach and analyze the time and space complexity.
  • How would you extend this solution to work across multiple floors, essentially a 3D grid?
  • What if movement between cells had different costs instead of uniform steps? How would your approach change?

“Went with multi-source BFS seeded from all exits simultaneously, which is the right call.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at DoorDash for a software engineer role. The prompt was a review and rewards platform, which sounds straightforward until you start pulling on the threads around fraud detection and eventual consistency.
  • Design a system that allows users to submit, edit, and delete reviews for products or restaurants, and rewards qualifying reviewers through a points or payout ledger.

“This is a bigger prompt than it looks.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
DoorDash PM case interview focused on a supply-side problem, specifically a drop in restaurant partners over a short window. One question, pretty open-ended, and the kind of thing that sounds manageable until you're actually in it.
  • Restaurant supply on the platform has dropped 10% over the last week. As a PM, how do you diagnose and address this?

“I went straight into root cause territory, which felt right, but I think I spent too long on the diagnosis side and rushed the action plan.”

View Post

DoorDash·Software Engineer·Onsite - Product Sense / Strategy

Jun 2026
BizOps interview at DoorDash, one question deep into driver behavior and supply-side growth. Pretty open-ended case style, no right answer but you could tell they wanted structured thinking with a real operational lens.
  • How would you increase the number of drivers using the red food bag provided by DoorDash over a weekend?

“I went straight to incentives and kind of stayed there too long.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at DoorDash where they asked me to design a Twitter-scale service. Pretty classic question but the scope was wide enough that I kept second-guessing where to spend my time.
  • Design a Twitter-like service covering core features: posting tweets, following/unfollowing users, home timeline, profile timeline, likes, retweets, and replies.
  • How would you handle timeline reads at low latency for hundreds of millions of users, given that the system is heavily read-dominant?
  • How would you store and query the social graph (who follows whom) to support follow/unfollow operations and timeline generation?
  • How would you approach search and trending topics in this system?

“The scope of this thing is massive and I burned too much time on the tweet storage schema before they nudged me toward timelines.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash engineering interview focused on a debugging exercise involving a dasher assignment service. The whole thing was very hands-on: here's a broken codebase, here's a failing scenario, go figure out what's wrong and fix it. More involved than I expected.
  • Given a codebase for a delivery driver assignment service with a reported bug causing incorrect assignments, reproduce the bug and write a minimal failing test that isolates the root cause.
  • After identifying the root cause of the bug (such as a stale cache, bad sort comparator, time-unit mismatch, or race condition), implement a fix and explain its complexity.
  • How would you add observability to this service, including structured logging and metrics, and what safeguards like timeouts, retries, or circuit breakers would you introduce?
  • Walk through edge cases for this assignment system: no available drivers, ties between candidates, GPS jitter, late position updates, partial outages, and performance under high load.

“This was the core of the whole session.”

View Post