DoorDash Interview Questions — Page 1

DoorDash·Data Scientist·Technical Phone Screen

Apr 2024

DoorDash data scientist interview focused on a clickstream pipeline scenario. The technical portion mixed Pandas wrangling with SQL, which felt reasonable until the lambda-based tiering question made me second-guess my groupby instincts.

Using Pandas, aggregate total revenue and distinct purchase counts per user from an events table, then use a lambda inside apply to classify each user into a revenue tier (zero, low, high).
Write a SQL query that returns, for each platform, the daily conversion rate defined as purchases divided by clicks over the last 30 days.

“The groupby part was fine but I fumbled the lambda for a second because I kept second-guessing whether to apply it on the grouped object or after resetting the index.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Jun 2024

DoorDash data scientist interview, SQL-heavy technical screen built around a food delivery schema. Four questions total, all interconnected, which was a nice change from the usual disconnected grab-bag format.

Given an orders table and a driver requests table, write a query that returns every order that has at least one associated driver request.
For each order, rank the driver offer amounts and flag which offer is the highest.
Count the orders where the most recent driver offer is higher than the one before it, and compute the average improvement in offer amount across those orders.
Explain the difference between bounded and unbounded window frames in SQL, and write an example query for each.

“Pretty standard join to start.”

View Post

DoorDash·Data Scientist·Technical Phone Screen

Aug 2025

DoorDash data science case focused entirely on a real operational scenario: a 12% drop in completed orders in LA. The whole thing was one big structured problem, broken into diagnosis, experiment design, and quasi-experimental fallback. Dense and technical, no fluff.

Completed orders in a major market dropped 12% week-over-week. Walk through how you'd build a funnel-based diagnosis to determine whether the issue is supply-side or demand-side, including what cuts, plots, and thresholds you'd use.
If supply shortage during the dinner peak is your leading hypothesis, design an experiment to validate it. Cover the randomization unit, primary and guardrail metrics, power assumptions, sample size, duration, and how you'd handle spillover and seasonality.
If a randomized experiment isn't feasible, what quasi-experimental method would you use instead? Describe the setup, pre-trend checks, and robustness tests in enough detail that another analyst could run it.

“This is the kind of question where you can talk for 20 minutes and still feel like you barely scratched it.”

View Post

DoorDash·Data Scientist·Take-home Assignment

Sep 2025

DoorDash DS take-home centered entirely on a multi-table SQL schema for new-market readiness. Three fairly involved queries covering daily launch health, supply-demand risk flagging, and courier activation funnels. The kind of prompt that looks clean on paper but has a lot of edge cases hiding in it.

Given a schema with cities, merchants, couriers, and orders tables, write SQL to compute per-day launch health metrics for a specific city over a 7-day window. Include orders created, delivered, and cancelled counts, median delivery ETA in minutes, and merchant coverage per 10k population. Flag each day as at-risk if median ETA exceeds 35 minutes or cancel rate exceeds 8%.
Using a supply_demand table with 15-minute interval granularity, write SQL to aggregate by day the share of intervals where active couriers divided by demand requests falls below 0.8. Flag days where more than 25% of intervals are in that undersupply state.
For couriers who signed up in a given city within a specified date range, compute cohort-level activation and delivery funnel metrics: what share activated within 14 days of signup, what share completed a first delivery, and what was the median time from signup to first delivery in minutes. Return a single summary row.

“The median ETA part is what slowed me down.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding round for a software engineer position. One question, arithmetic expression evaluator, and it was a tighter problem than it looks on the surface.

Given a string representing a valid arithmetic expression with non-negative integers and the operators +, -, *, / but no parentheses, evaluate it and return the integer result. Division truncates toward zero. The string may contain whitespace.

“I knew the general idea but fumbled the operator precedence part for a bit.”

View Post

DoorDash·Machine Learning Engineer·Onsite - Behavioral / Leadership

Apr 2026

DoorDash ML Engineer interview that basically lives or dies on how well you know your own resume. The main ask was to pick a project and go deep, and they weren't letting you off easy with surface-level answers.

Pick a project from your resume and walk me through it end-to-end, including what you'd do differently and what business metrics it actually moved.

“This is the question that exposes you if you've been coasting on vague resume bullets.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash data engineering screen, one coding question, sliding window stuff. Not a bad experience but the index conversion tripped me up more than I'd like to admit.

Given an array of daily revenue values and a window size k, find the contiguous k-day period with the maximum sum and return its start day as a 1-based index. Ties should return the earliest start day. The result should be wrapped in a list.

“I knew sliding window immediately, got the O(n) logic down pretty fast.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding round for a software engineering role. The problem was themed around their core product which was a nice touch, but the actual challenge had enough moving parts to keep you honest.

You're consuming a stream of order events from an upstream API. Each order has an accept time and a fulfill time, making it 'active' between those two points. Pay is $0.30 per minute, multiplied by how many orders overlap in that same minute. Build a system that mocks the upstream API and computes total dasher pay for an arbitrary set of overlapping orders.

“The multiplicity part is what gets you.”

View Post

DoorDash·Product Manager·Onsite - Product Sense / Strategy

Apr 2026

Did a product sense round for a PM role at DoorDash. One question, pretty open-ended, left me second-guessing my answer for the rest of the day.

How would you improve the quality of Airbnb over the next six months?

“Weird to get a question about a competitor's product but I've seen it before.”

View Post

DoorDash·Software Engineer·Technical Phone Screen

Apr 2026

DoorDash coding round focused on a pay calculation problem that looked straightforward but had a lot of edge cases hiding underneath. The production-readiness follow-ups were where things got interesting.

Implement a dasher pay calculation function that takes a list of completed dashes, each with a base pay, tips, promotional bonuses, and peak-pay multipliers, and returns the total earnings for a pay period.
How would you handle monetary rounding in this system, and what are the tradeoffs between different rounding strategies?
How would you make this pay calculation service idempotent so retries don't result in duplicate payments?
What input validation would you add to this function before it runs in production?
How would you handle time-zone issues when computing pay periods for dashers across different regions?

“The core function wasn't too bad.”

View Post