← Back to Directory

DoorDash interview notes, page 37 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·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash SWE coding round, two parts to a single grid-based problem. The follow-up was a lot heavier than I expected and I don't think I fully nailed the tie-breaking logic under pressure.
  • Given an m x n character grid with dashmarts ('D'), impassable cells ('X'), and open cells, write a function that takes a list of query locations and returns the shortest distance from each location to the nearest dashmart. Return -1 if the cell is impassable or no dashmart is reachable.
  • Extend the previous grid problem: each dashmart has a base busy score, and its effective busy score for a query at distance d is max(0, base - alpha * d). For each query, find the reachable dashmart that maximizes this effective busy score, breaking ties by shortest distance, then by row, then by column. Return the dashmart coordinates and its effective busy value.

“Multi-source BFS from all dashmarts simultaneously, precompute distances, then answer queries in O(1).”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash analytics engineer interview that basically asked me to narrate an entire ETL project from scratch and then pivot into a behavioral story about dealing with messy stakeholder situations. Two pretty meaty questions, not a lot of fluff.
  • Walk me through an ETL pipeline you built end to end, covering the business goal, source systems, how data was ingested, transformations, modeling decisions, orchestration, testing, monitoring, backfills, and how you handled failures or schema changes.
  • Tell me about a time your project had unclear requirements, a disagreement with a stakeholder or manager, or conflicting opinions on the right technical approach, and how you resolved it.

“This is a lot of ground to cover and I underestimated how much they'd actually want to dig into each layer.”

View Post

DoorDash·Machine Learning Engineer·Onsite - Behavioral / Leadership

Jun 2026
Behavioral round at DoorDash for an ML Engineer role. Just the one question but it had a lot of moving parts packed into it.
  • Tell me about a time you had a disagreement with a collaborator. How did you approach the conversation, what was the disagreement about, how did you understand their perspective, and how did you resolve it? What was the outcome, and what would you do differently?

“The question itself is fine but they really loaded it up.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash coding round with one meaty tree problem that took up the whole session. The question had enough layers to it that I kept second-guessing my approach mid-explanation.
  • Given two rooted trees where each node has a unique string key among its siblings and a value, compute the total number of differing nodes. Nodes only in one tree count as additions or deletions. If two nodes share the same key path but have different values, treat the whole subtree as deleted and recreated, counting every node in both subtrees. Child order doesn't matter. Design an efficient algorithm, analyze complexity, and handle edge cases like empty trees or heavily skewed structures.

“I started with a naive recursive diff and pretty quickly realized the 'delete + recreate' rule for value mismatches was the tricky part.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash data engineer screen with a classic pairing problem. Nothing too wild but the index-based output tripped me up a bit.
  • Given an array of task durations in minutes, find all pairs of tasks whose combined duration equals exactly 60 minutes, and return their index pairs. For example, given [1, 43, 20, 59, 30, 30], the answer would be [[0, 3], [4, 5]].

“My first instinct was a brute force double loop and I almost just went with it.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Jun 2026
DoorDash SWE system design round. First chunk was a project walkthrough, then they dropped a pretty involved multi-domain design problem covering food ratings, social posts, and driver payroll all in one shot. More breadth than I expected for a single session.
  • Walk the interviewer through a recent project you worked on.
  • Design a system that aggregates user ratings for food items into a 5-point scale, supports user-generated posts with likes, and handles monthly earnings settlement for delivery drivers.
  • How would you model the data entities for this system, including food items, ratings, posts, likes, delivery records, and settlements?
  • What storage technologies would you choose for each part of this system and why?
  • How would you design the monthly batch settlement pipeline for driver earnings, including handling retries, idempotency, and producing an auditable pay statement?

“Standard opener but the 15-minute time box is real.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jun 2026
DoorDash software engineer round focused entirely on a pay-calculation problem that kept getting more complicated. Started manageable, then they piled on peak hours and concurrency rules until it felt like a mini system in itself.
  • Given a list of delivery orders, each with accept/deliver times and restaurant wait timestamps, compute per-minute pay where the rate scales with how many orders are concurrently active that minute, but the restaurant wait window is excluded from counting toward concurrency for other orders.
  • Now extend the solution to support configurable peak-hour windows. During peak hours the per-minute rate doubles. How do you combine this with the concurrent-order multiplier and the restaurant wait pause logic?

“The concurrency part is where I got turned around.”

View Post

DoorDash·Frontend Engineer·Onsite - Coding / Algorithms

Jun 2026
DoorDash frontend coding round, building on top of a phone-screen project. Three features to implement in TypeScript and the whole thing felt more like a real work task than a typical interview, which I appreciated but also underestimated.
  • Add three filter buttons to an existing list page where the filter values come from an API response. How do you wire up the state and handle the data flow?
  • Implement a tag-based filtering category that supports multi-tag selection. You need to decide on AND vs OR semantics and justify the choice.
  • Build a 'See More' / 'See Less' toggle that expands a truncated list and collapses it back. Make sure the component structure is clean and the interaction is accessible.

“This part felt straightforward at first but I spent way too long deciding where to put the filter state.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jul 2026
DoorDash coding round focused entirely on domain-specific payment logic for their dasher platform. Not your typical leetcode grind, which honestly threw me a bit.
  • Design and implement the payment calculation system for a delivery driver. Given inputs like base pay, per-mile rate, per-minute rate, tips, peak-pay multipliers, and guaranteed minimums, define the data classes and write a function that computes the final payout with proper edge-case handling.

“This one was more involved than I expected for a phone screen.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Jul 2026
DoorDash data engineer round focused entirely on a SQL bucketing problem using their core tables. One question, but it had a lot of moving parts and they clearly wanted to see you think out loud about the design choices, not just produce working syntax.
  • Given an ER diagram with merchant, menu, order, and dasher tables, write a SQL query that assigns each merchant to a bucket (low, medium, high) based on a bucketing metric of your choice, such as total order count, total revenue, or order frequency. Justify your choice and return one row per merchant with the merchant ID, the metric value, and the bucket label.

“I went with total revenue over a trailing 90-day window because it felt more business-relevant than raw order count.”

View Post