DoorDash Interview Questions — Page 8

DoorDash·Software Engineer·Hiring Manager Screen

Apr 2026

Bizops screen at DoorDash, one question about the company's business model. Pretty surface-level from what I could tell.

How does DoorDash's business model work?

“Walked through the three-sided marketplace angle: restaurants, drivers, consumers.”

View Post

DoorDash·Software Engineer·Onsite - Behavioral / Leadership

Apr 2026

Behavioral round at DoorDash for a software engineering role. Just one question but it had a lot of moving parts and I don't think I handled all of them cleanly.

Tell me about a time you had to choose between doing something the right way and doing it fast. How did you weigh the trade-off, who was affected, how did you communicate the risks, and what was the measurable result?

“I had a decent story ready but I fumbled the stakeholder part.”

View Post

DoorDash·Frontend Engineer·Onsite - System Design / Architecture

Apr 2026

Did a system design round at DoorDash for a frontend role, which already felt off. The question was fine but the follow-up database deep-dive was brutal for someone who doesn't live in backend land. No callback, as expected.

Design a photo-sharing platform like Instagram, specifically accounting for how the system handles posts from accounts with massive follower counts.

“The base question was manageable.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Apr 2026

DoorDash system design round for a software engineering role. The whole session was basically one big LRU cache question that kept expanding into concurrency territory, which I wasn't fully prepared for.

Design an in-memory LRU cache for a single machine. Walk through how you'd use a hash map and doubly linked list to achieve O(1) get and put, and explain how you handle capacity limits, eviction, and key updates.
Now make your LRU cache thread-safe. Compare global locking versus segmented or per-bucket locking, discuss readers-writer locks, and talk through lock-free approaches. How do you prevent race conditions and keep memory safe under concurrency?
What are the time and space complexity tradeoffs of your design, and what are the major pitfalls someone might run into when implementing this in production?

“I knew this one cold, or thought I did.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding round focused on a string similarity grouping problem that sounds deceptively simple but has real complexity hiding underneath. The swap-based constraint tripped me up more than I expected.

Given a list of restaurant names, group names that are considered 'similar', where two names are similar if one can be turned into the other by performing at most two single-character position swaps. For a query name, return all matching names from the list. Also discuss the time complexity for n names of length L and how to avoid an O(n^2) comparison blowup.

“I got the basic idea fast enough.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash SWE coding round, one problem the whole time. It was more involved than it looked on the surface and I definitely underestimated the parsing piece until I was already mid-explanation.

Given a stream of events for a delivery driver, where each event has a timestamp string and a pay-related value, compute the total pay over specified time intervals such as per day or per shift. Handle timestamp parsing edge cases and events that fall outside the queried interval.

“I jumped straight into the aggregation logic and completely glossed over the timestamp parsing until the interviewer asked how I'd handle a date like '2026-3-6 9:00' vs '2026-03-06 09:00'.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding round focused entirely on a grid BFS problem with a DoorDash-flavored skin on it. One question, pretty involved, and they pushed hard on scaling and edge cases.

Given an m x n grid where cells are either walls, stores, or empty rooms, and a list of query coordinates each pointing to an empty room, return the shortest distance from each queried cell to the nearest store. Return -1 if unreachable. Your solution should scale efficiently when the query list is large, and you need to handle edge cases like duplicate queries, isolated rooms, empty query lists, and grids with no stores at all.

“My first instinct was to run BFS from each query point separately, which works fine for small inputs but falls apart when k is large.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Apr 2026

DoorDash data science technical screen, heavy SQL focus with a food-delivery domain problem that had a lot of moving parts. Four interconnected tasks on the same schema, window functions required throughout, and edge cases baked into the prompt itself.

Given a food-delivery schema (orders, deliveries, complaints, restaurants), compute a daily cold delivery rate for the last 7 days. A delivery is 'cold' if food temp drops below 40°C at dropoff OR a cold_food complaint is filed within 2 hours of dropoff. Deduplicate so each order counts once even if both conditions trigger. Return date, delivered_orders, cold_deliveries, and cold_rate rounded to 3 decimals.
For each restaurant, compute a 7-day rolling cold delivery rate ordered by date, covering 2025-08-26 through 2025-09-01. Dates where a restaurant had zero deliveries should still appear with delivered_orders=0 and a NULL rate.
Using the 7-day rolling cold rate as of 2025-09-01, rank restaurants with DENSE_RANK(), breaking ties by higher total delivered orders. Return the top 3 with restaurant name, delivered orders, cold rate, and rank.
Flag couriers whose cold delivery rate z-score over the last 7 days exceeds +2 standard deviations relative to the full courier population. Use windowed AVG() and STDDEV_POP() across couriers. Return courier_id, deliveries in the period, cold rate, and z-score.

“The deduplication part is what got me initially.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding screen for a software engineer role. The main problem was a payout calculator for a delivery platform, which sounds straightforward until you hit the edge cases around surge windows and deduplication. Follow-ups pushed into system design territory pretty fast.

Given a list of delivery records with timing and rate data, a set of already-paid delivery IDs, and a list of surge windows with multipliers, compute the total payout in cents for a single driver and return the delivery IDs that should be marked as paid.
How would you make the payout operation idempotent if the payment API can time out and the job might be retried?
How would you handle multiple surge windows that overlap each other in time?
How would the algorithm change if the business wants to pay drivers based on the union of their active delivery time rather than computing each delivery independently?

“The core logic took me a while to structure cleanly.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

Apr 2026

DoorDash system design round focused on payment reliability, specifically idempotency in a distributed payments context. The question was a follow-up to a broader payment system design, so it assumed you'd already laid groundwork and went straight into the hard parts.

In a payment system where the network is unreliable and users or clients may retry the same charge multiple times, how do you guarantee a user is never double-charged while keeping the system available? Walk through client-generated idempotency keys, server-side dedup tables, retry handling, timeout reconciliation, concurrent request locking, and UX considerations.

“This is the kind of question where you think you know the answer and then the follow-ups expose every gap.”

View Post