DoorDash Interview Questions — Page 13

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026

PM interview at DoorDash with a product sense question framed around Lyft's ride experience. Single question, product strategy focus, nothing too wild but it requires you to actually know the post-match lifecycle pretty well.

You're the PM owning the ride experience at a rideshare company. After a driver and rider are matched, several problems tend to emerge. What's the most effective solution you'd prioritize to address them?

“I spent probably too long listing out all the problems first, cancellations, ETAs being wrong, drivers going to the wrong pickup spot, communication breakdowns.”

View Post

DoorDash·Software Engineer·Onsite - Multi Round

May 2026

DoorDash onsite for a software engineer role, two back-to-back coding exercises that leaned more systems-flavored than pure algorithms. Nothing behavioral, just code and design the whole time.

Implement a service method that fans out to multiple downstream APIs, merges their responses into a single nested structure, handles transient failures, and retries failed calls. Then write tests covering the success path, a single transient failure, and repeated failures, verifying the full nested output each time.
Given a buggy load balancer implementation, find and fix all the bugs, then add round-robin request distribution. After that, explain how you'd extend it to support consistent hashing for better key affinity and minimal remapping when the server pool changes.

“The fan-out part was fine, I've done similar things before.”

View Post

DoorDash·Data Scientist·Take-home Assignment

May 2026

DoorDash data science take-home that was way more involved than I expected. One massive SQL problem covering window functions, rolling aggregates, policy simulation, and multi-CTE output. Took me a few hours and I'm still not sure I got the rolling window right.

Write a single SQL query (CTEs allowed) that, for orders in the last 30 days: computes lateness in minutes using GREATEST and EXTRACT EPOCH, ranks orders within each city and delivery date using PERCENT_RANK, computes a rolling 7-day cold-food refund cost per order at the store-day level, simulates a proposed tiered refund policy (0% under 10 min late, 50% for 10-29 min, 100% for 30+ min) with a $50 cap compared to the current 100%-of-subtotal policy, and outputs both city-level aggregate savings and the top 5% store-days by current refund cost per order.

“The lateness calculation itself was fine, GREATEST(0, ...) to floor at zero is pretty standard.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash backend interview that started with a debugging exercise on a broken round-robin distributor, then pivoted hard into consistent hashing territory. More depth than I expected for what I thought would be a straightforward coding round.

You're given a broken round-robin request distributor. Find and fix the bugs, including things like an off-by-one in the index, a local variable shadowing an instance variable, and missing wrap-around logic.
Now replace the round-robin logic with consistent hashing. Implement the hash ring, add virtual nodes, and write the key-to-server lookup.
When would you prefer consistent hashing over round-robin, and what are the tradeoffs?

“The off-by-one I caught pretty fast.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

System design round at DoorDash for a software engineer role. The core problem was building a bootstrapper API that fans out to multiple sources and handles partial failures gracefully. Pretty meaty question with a lot of moving parts.

Design an aggregated bootstrapper API that fans out to multiple downstream sources (user profile, feature flags, config, experiments) in parallel and returns a single merged response to the client. How do you handle partial failures, per-source timeouts, and result aggregation?
How would you cache results from slow or expensive bootstrap sources, and what tradeoffs does that introduce?
How would you evolve this API as new bootstrap sources get added over time without breaking existing clients?

“This took me a minute to fully scope.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash coding interview with two back-to-back problems, one on pay calculation and one on request routing. The problems felt very on-brand for a delivery company which was either clever or on the nose depending on your mood. Decent difficulty, nothing impossible, but the second one had a part B that could spiral if you weren't careful.

Given a list of pay-rate intervals and a list of delivery trips, compute the total pay for a courier. Trips earn time-based pay according to the rate schedule plus a flat bonus per trip, and you need to handle gaps in the rate schedule and trips that span multiple intervals.
Design an in-memory request router. First implement round-robin routing with add/remove server support, then extend it to use consistent hashing so that server changes only remap a small fraction of requests.

“The core idea clicked pretty fast: sort the intervals, then for each trip do a sweep over the relevant intervals and accumulate.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026

DoorDash PM interview with a metrics and strategy question framed around Amazon. Pretty standard product sense territory but the NPS angle made me think harder than expected.

You're a PM at Amazon and you want to improve NPS. How do you approach this?

“I jumped straight into segmenting the NPS data by customer type and purchase category, which felt right, but I spent too long on diagnosis and barely got to the actual improvement levers before time ran out.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

DoorDash system design round focused entirely on a distributed job scheduler. Dense problem with a lot of moving parts and I felt like I was constantly playing catch-up with the scope.

Design a distributed job scheduler that accepts cron-style jobs, fires them at the right time, and runs them on a worker pool. Cover the full picture: CRUD for jobs, cron parsing, retries, run history, and how you handle scale to millions of jobs without missing or double-firing any.
How would you structure the storage layer to efficiently find which jobs need to fire in the next few seconds, across millions of scheduled jobs?
How do you prevent the same job from being dispatched twice, especially when multiple workers or schedulers are running concurrently?
Walk through how you'd handle retries on job failure without violating exactly-once semantics.
How would you scale the worker pool and the dispatch coordinator as job volume grows?

“This one sprawled fast.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash coding round centered on a buggy implementation problem, specifically around their dasher order-selection logic. The whole thing was about finding subtle off-by-one errors in index handling, which sounds easy until you're staring at it under pressure.

You're given a buggy implementation of a delivery driver order-selection routine. Find and fix the bugs, paying close attention to index handling during removal operations, and walk through the corrected logic with example inputs.

“The sneaky part was the remove call.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

May 2026

PM interview at DoorDash with a strategy question framed around a retail context. Pretty short on details but the core question was a revenue growth case.

If you were a leader at a major retail chain, how would you grow revenue?

“I went straight to the obvious levers (traffic, conversion, basket size) and it felt a bit textbook in hindsight.”

View Post