DoorDash Interview Questions — Page 14

DoorDash·Data Scientist·Technical Phone Screen

May 2026

DoorDash data science interview that went deep on retention and churn measurement for a transactional app. The whole session was basically one long case question with five layers, and I did not see the survival analysis part coming at all.

How would you precisely define retention and churn for a transactional consumer app, and which definitions would you choose based on the decision you're trying to support?
Walk through the formulas for cohort retention and churn rates. How do you handle right-censoring and delayed conversion, and what statistical pitfalls should you watch for?
How would you measure the long-term retention impact of a treatment like a 20% discount using survival analysis? Define the key concepts and explain how you'd compare groups and control for confounders.
Show with made-up numbers how rolling retention and strict cohort retention can disagree, and explain how you'd reconcile the two for an executive audience.
How do you set washout, observation, and attribution windows in a retention experiment, and how do those choices affect statistical power and potential bias?

“This is where I spent probably too long hedging.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

May 2026

DoorDash data science case focused entirely on a product launch evaluation for bike courier delivery. It was a long, layered question and I kept second-guessing how deep to go on each part versus moving forward.

What are the potential benefits of adding a bicycle courier option compared to cars or scooters, from a business, customer, courier, and operational standpoint?
What factors should you assess before launching or piloting bike delivery? Think about city characteristics, order types, weather, regulation, and whether it might cannibalize existing delivery modes.
Define the metrics you'd use to evaluate bike delivery, including a north-star metric, supporting operational metrics, and guardrail metrics. How do you think about tradeoffs between speed, cost, courier earnings, and safety?
What experiment would you run to test bike delivery on a two-sided marketplace? Walk through your randomization unit, experiment duration, segmentation strategy, and how you'd handle interference between treatment and control groups.
How would you decide whether to scale the bike delivery launch? How do you interpret results while accounting for confounders like weather and time of day, and what does your go or no-go recommendation look like?

“I went straight to cost savings and kind of forgot to talk about courier supply dynamics until they nudged me.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash software engineer round focused on a payout calculation problem with some system-level follow-ups at the end. The coding part went fine and the conversation felt natural throughout.

Given a set of delivery order records, calculate the total payout for a dasher. Completed deliveries are paid based on time and rate, cancelled orders get a flat fee, and there are special time windows where pay is doubled.
How do you handle edge cases like a double-pay window overlapping with an active delivery, or a cancelled order that was placed during a bonus window?
What would you do if the data volume for these payout calculations became very large, or if the upstream service providing order data went down?

“The base logic wasn't too bad but the double-pay windows tripped me up for a minute.”

View Post

DoorDash·Machine Learning Engineer·Technical Phone Screen

May 2026

DoorDash ML engineer interview with a meaty growth/promo design question. The whole session basically lived inside one open-ended scenario, so if you blank on uplift measurement or budget allocation you're in trouble fast.

You own a promotional offer system (e.g. '$10 off' or 'free delivery') meant to drive growth. Walk through how you'd decide who gets a promo, what offer to send them, and when to send it, given a limited budget, the risk of discounting users who'd order anyway, and the need to measure real incremental lift without tanking long-term margins.

“This question is deceptively wide.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

DoorDash system design round for a full-stack role, and they went straight for the jugular with a large-scale alerting system. Pretty intense scope for a single session, covering everything from data modeling to fan-out architecture to DLQ strategies.

Design an alert notification system for a large-scale service that accepts events from multiple producers, applies user-defined routing rules, and delivers across channels like email, SMS, push, Slack, and webhooks.
How would you handle deduplication, alert grouping into digests, and silencing windows within the notification pipeline?
What's your retry and dead letter queue strategy for failed notification deliveries, and how do you ensure at-least-once delivery without spamming users?
How do you handle channel-specific rate limits, say an SMS provider that caps you at 100 messages per second, without dropping high-severity alerts?
How would you deal with hot subscribers, meaning a single user or endpoint that receives a disproportionate volume of alerts?

“This is the whole question, and it's a lot.”

View Post

DoorDash·Machine Learning Engineer·Technical Phone Screen

May 2026

DoorDash ML engineer round that was basically a scheduling problem dressed up in delivery language. Pretty straightforward if you've seen the meeting rooms problem before.

Given a list of delivery orders where each order has a start time and end time representing when a rider is occupied, find the minimum number of riders needed to handle all orders simultaneously.

“Classic interval overlap problem but reframed around riders and orders.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash system design round focused on a service aggregation problem. Pretty OOD-heavy, more code than I expected for what felt like a design question.

You have three separate services that each return a partial view of the same entity. Build a new service that calls all three, merges the results into one response, and handles cases where one of the upstream services fails or times out.

“I started with the happy path which was the right call, but I spent too long on the data models before touching the aggregator logic.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

May 2026

DoorDash software engineer interview with a greedy/sorting problem involving chefs and dishes, plus a follow-up array construction question. Pretty focused session, felt more like a technical phone screen than a full onsite loop.

You have three arrays: chef skill levels, dish difficulty levels, and dish profits. Each chef can cook at most one dish, but only if their skill meets or exceeds the dish's difficulty. Multiple chefs can independently cook the same dish and each earns the full profit. Return the maximum total profit you can get by assigning chefs to dishes.
As a follow-up: given the dish difficulty and profit arrays, how would you build an array where each index represents a skill/difficulty level and stores the best profit a chef at that level could achieve?

“Took me a second to realize multiple chefs can cook the same dish, which changes the whole approach.”

View Post

DoorDash·Software Engineer·Onsite - System Design / Architecture

May 2026

System design round at DoorDash for a software engineering role. Two big open-ended topics, both squarely in distributed systems territory. Not a lot of hand-holding from the interviewer.

Your service depends on an upstream API that starts responding slowly. How do you protect your own service's reliability? Walk through your approach including timeouts, retries, circuit breakers, bulkheads, fallbacks, async processing, and load shedding.
When would you choose Redis over a relational database, and when would you use both together? Compare them across access patterns, durability, consistency, latency, and cost.

“This one went longer than I expected.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

May 2026

DoorDash data science interview with a deep, multi-part experiment design question about a delivery marketplace feature. The whole session was basically one massive switchback experiment prompt broken into six sub-parts, which felt more like a take-home problem compressed into a live setting. Technically demanding and not the kind of thing you can wing.

You're designing a 2-week switchback experiment at the city level to test a feature meant to reduce cold-food incidents for bike couriers. How do you choose the slot length L, and what block-randomization scheme prevents contamination while balancing day-of-week and peak hour effects?
What's the difference between slot-level assignment (intention-to-treat) and realized exposure when couriers in OFF slots pick up spillover demand from adjacent ON slots? How does that affect the numerator and denominator of your cold-food rate metric?
Write out the regression model you'd use, including city fixed effects, slot-of-week fixed effects, and cluster-robust standard errors at the city-by-slot level. How would you add pre-period baselines or covariates like weather, surge, or courier mix?
With a baseline cold-food rate of 6%, a target relative reduction of 10% (MDE of 0.6 percentage points), 120 eligible orders per slot, ICC of 0.02, and 14 days of data, how many ON/OFF switchbacks per city do you need for 80% power at alpha 0.05?
What randomization checks and balance tests would you run before analyzing results, and how would you specifically test for carryover effects between adjacent ON and OFF slots?
How would you handle partial compliance, missing telemetry, or a major unexpected event mid-experiment? What's your decision rule for stopping, extending, or rerunning the test?

“The 45-minute order lifecycle plus 30-minute carryover horizon was the key anchor.”

View Post