← Back to Directory

DoorDash interview notes, page 15 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·Product Manager·Onsite - Product Sense / Strategy

May 2026
DoorDash PM interview with a product sense question that used Ticketmaster as the case company, which was a bit of a curveball since it has nothing to do with DoorDash's core business.
  • If you were the PM for Ticketmaster's post-booking experience, what would you do?

“Spent the first minute just figuring out what 'post-booking' even meant in this context.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash software engineering interview with a coding problem themed around their actual delivery driver pay logic. The follow-up added real complexity and the edge case handling portion felt like it mattered more than I expected.
  • You're given a log of delivery driver events for a single day. Each event is a JSON record with an order ID, event type, timestamp, and a base rate per minute. For each order, find the valid start and end event pair and compute pay as duration times base rate. Return the driver's total pay across all orders for the day.
  • Follow-up: certain time windows are marked as peak periods where pay is doubled. If a driver's paid interval partially overlaps a peak window, split the interval at the peak boundaries and apply the doubled rate only to the overlapping portion. How do you handle this?
  • How would you handle malformed input in this system? For example: events with no matching pair, duplicate events for the same order, or events that appear in an invalid order (like a completion before a start).

“The core problem wasn't hard once I stopped overthinking the JSON structure.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

May 2026
DoorDash data science interview, one big case question about a metric drop in the LA market. The whole thing was a single sprawling problem with six sub-parts that kept going deeper. Felt like a marathon.
  • Successful orders per day in the LA market has dropped over the past two weeks compared to the prior four-week baseline. How would you first verify the decline is real and not caused by data pipeline issues, seasonality, or a mix shift?
  • Give one plausible hypothesis for the drop from each side of the marketplace: the customer side, the restaurant side, and the dasher side.
  • If all three hypotheses seem to be contributing to the decline, how would you quantify the impact of each one on the overall drop in successful orders?
  • Walk through the funnel you would build to diagnose this drop. What metrics would you track at each step and how would you pinpoint where the biggest loss is occurring?
  • Based on the likely root causes you've identified, what product or operational changes would you propose?
  • Pick one of your proposed improvements and design an A/B test for it. Cover the unit of randomization, primary metric, guardrail metrics, experiment duration, and any interference, power, or bias concerns.

“This is where I spent too long.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash coding screen focused on a pay calculation problem for delivery drivers. Pretty domain-specific but not algorithmically brutal, the tricky part was in the edge cases they expected you to handle.
  • Given a list of delivery events for a driver, each with a timestamp string, implement a pay calculator that parses the timestamps, computes time on shift, total miles, and tips per event, then outputs total pay using a base + per-minute + per-mile + tips formula with a minimum guarantee. Your solution should also handle out-of-order and duplicate events.

“The core math wasn't bad but I underestimated how much time I'd spend just on timestamp parsing and sorting.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at DoorDash, 45 minutes, designing a donation platform for a short-burst charity event. The scope felt manageable at first but the payment reliability stuff went deeper than I expected.
  • Design a donation service to support a 3-day charity fundraising event, where users can browse campaigns, donate through a third-party payment provider, receive a receipt, and see real-time progress toward a fundraising goal.
  • How would you handle the scalability requirements given that donations could spike virally over a short 3-day window?
  • How do you ensure the displayed fundraising total is always accurate, never double-counting donations or losing any?

“I started with the happy path and it went fine, but the interviewer kept pushing on what happens when Stripe returns a 500 mid-charge.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash software engineering interview with a systems-focused coding round. The main problem was building a round-robin load balancer with health tracking, bug fixing, and test writing. Pretty meaty for a single session.
  • Implement a round-robin request router given a list of backends. It should return the next healthy server for each incoming request, handle servers being added or removed, and correctly wrap around without skipping or duplicating assignments.
  • You're given failing tests that show incorrect routing behavior. Identify the bug in the round-robin implementation and fix it.
  • Write tests covering: single server, multiple servers, server removal during active routing, and health flapping scenarios.
  • Analyze the time and space complexity of your implementation, and discuss thread-safety considerations.

“This looked manageable at first.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
DoorDash system design round, one meaty question about dependency resolution and service startup. Felt like a backend-heavy session dressed up as a design discussion.
  • Design a bootstrap routine for an application where components declare dependencies on each other. The routine must initialize everything in the correct order, detect circular dependencies, and handle failures during initialization gracefully. How would this fit into a real service startup flow?

“This one has a few layers and I underestimated the failure-handling part at first.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash software engineering interview that was essentially a hands-on debugging and refactoring exercise on a legacy module, followed by a concurrency design discussion. Pretty practical stuff, less algorithmic than I expected.
  • You're given a legacy module with a failing test suite. Walk through how you'd systematically debug and refactor it, specifically addressing naming conventions, exception handling, input validation, and overall code structure until all tests pass.
  • After fixing the module, describe a plan to make it safe for multi-threaded execution. What strategies would you consider (immutability, thread confinement, synchronization, concurrent data structures) and how would you validate correctness under concurrency?

“This took longer than I thought it would.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026
DoorDash system design round that threw a curveball: instead of the usual 'design this from scratch' setup, they gave me a live-outage scenario with constraints baked in, which meant none of my go-to technical fixes were on the table.
  • You're on call when a major payment system outage hits and your usual technical mitigations aren't available due to infrastructure limitations. Walk through how you'd handle triage, severity assessment, internal and external communication, customer impact mitigation, escalation, and postmortem.

“This one broke me a little.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026
DoorDash coding screen for a software engineer role. The problem was dressed up in delivery driver language but it was just LCS underneath, which I didn't clock immediately and cost me a few minutes of confusion.
  • You have two delivery drivers, each with an ordered list of restaurant IDs they need to pick up from. Since there's only one car, it can only visit restaurants that appear in both lists, and the order must be preserved for each driver. Find the longest possible route the car can take.

“Took me an embarrassingly long time to realize this was just longest common subsequence with a story wrapped around it.”

View Post