DoorDash Data Scientist Interview Cheatsheet 2026

DoorDash Data Scientist interviews usually test two things at the same time: can you write clean analytical code, and can you reason about a messy three-sided marketplace without acting like the data is cleaner than it is.

If you are preparing for the 2026 cycle, the full DoorDash Data Scientist interview prep cheatsheet on PracHub is a useful reference. This post condenses the main patterns into a standalone guide you can use while studying.

The core areas are:

• SQL and Python data manipulation
• Window functions
• A/B testing
• Causal inference
• Marketplace metric design
• Delivery quality diagnostics
• Switchback experiments
• Unit economics, pricing, and power analysis

The main theme across all of them: DoorDash questions are rarely pure syntax questions. They are business analytics questions where the hard part is often defining the metric correctly.

SQL: treat business definitions as part of the problem

DoorDash SQL questions usually involve orders, customers, restaurants, Dashers, events, cities, and time. You may be asked to calculate monthly spend, identify top restaurants, compare customer behavior across periods, or derive delivery-quality metrics.

The interviewer is checking whether you can turn vague business language into correct query logic.

Before writing code, clarify:

• What counts as a completed order?
• Which timestamp should be used: created, confirmed, picked up, delivered, canceled?
• What timezone should reporting use?
• Are canceled or refunded orders included?
• Is the metric order-level, customer-level, restaurant-level, or market-level?

Common SQL patterns include:

DATE_TRUNC('month', created_at)

for monthly metrics,

SUM(CASE WHEN condition THEN 1 ELSE 0 END) * 1.0 / COUNT(*)

for rates, and ROW_NUMBER, RANK, or DENSE_RANK for top-N queries.

The mistake I see most often is row inflation after joins. If you join an order table to item-level or event-level data, COUNT(*) may no longer mean number of orders. Use COUNT(DISTINCT order_id) when the grain requires it.

Also be careful with LEFT JOIN. A filter in the WHERE clause on the right-side table can turn it into an inner join and remove customers, restaurants, or cities with zero activity.

Window functions: know the grain before ranking or comparing

Window functions come up often because marketplace data is sequential. Customers reorder, Dashers receive dispatches, orders move through statuses, and restaurants have performance trends over time.

You should be comfortable with:

LAG(value) OVER (
  PARTITION BY customer_id
  ORDER BY order_ts
)

for prior-order comparisons,

LEAD(status) OVER (...)

for what happened after an event, and

ROW_NUMBER() OVER (
  PARTITION BY city_id
  ORDER BY orders DESC, restaurant_id
)

for deterministic top-N logic.

A good answer explains tie behavior. If the interviewer asks for one top restaurant per city, RANK() may return multiple rows. ROW_NUMBER() with a stable tie-breaker is safer.

For rolling or cumulative metrics, distinguish row-based windows from calendar-based windows. A "7-day rolling order count" is not the same as "last 7 rows." If the table has missing days, that difference matters.

A reliable workflow is:

1. Aggregate to the right grain first, such as restaurant-day or customer-month.
2. Apply window functions after that.
3. Filter top-N results in an outer query or CTE.

That prevents mixing raw order rows with grouped metrics, which can duplicate revenue or distort rates.

A/B testing: user-level randomization is often wrong

Many DoorDash experimentation questions are traps for people who default to "split users 50/50 and compare conversion."

That can work for independent consumer UI changes. It can fail badly for marketplace interventions.

If a change affects dispatch, batching, fees, delivery radius, Dasher incentives, or restaurant availability, one treated unit can affect untreated units. A treated order can change Dasher supply, merchant wait time, ETA accuracy, and customer experience nearby.

That is interference, and it violates the usual assumption that one unit's treatment does not affect another unit's outcome.

For marketplace changes, consider:

• Geo-level randomization
• Market-level randomization
• Zone-level randomization
• Time-block randomization
• Geo-time switchback experiments

A switchback design might randomize treatment by zone × time_block, such as 2-hour or 4-hour blocks. This is useful when market conditions differ across cities or zones, but the policy can alternate over time.

A common analysis equation is:

$$Y_{g,t}=\alpha_g+\gamma_t+\beta T_{g,t}+\epsilon_{g,t}$$

where geography fixed effects control for persistent market differences, time fixed effects control for common time shocks, and treatment estimates the policy effect.

Use clustered standard errors at the assignment level. If treatment was assigned by zone-hour, raw order count alone does not tell you the true amount of independent evidence.

Power: millions of orders can still be underpowered

Clustered experiments reduce effective sample size. If you randomize across 10 markets, you do not magically have millions of independent experimental units just because millions of orders occurred.

A simple design effect is:

$$DE = 1 + (m-1)\rho$$

where m is cluster size and ρ is intra-cluster correlation.

That means power depends on the number of independent clusters and the variance at that level. For switchbacks, use historical variance at the market-time or zone-time level.

For a two-sample mean comparison, a rough sample size formula is:

$$n \approx \frac{2\sigma^2(z_{1-\alpha/2}+z_{1-\beta})^2}{\delta^2}$$

For proportions, replace variance with p(1-p).

In an interview, you do not need to compute every value perfectly. You do need to say what minimum detectable effect matters, what variance estimate you would use, and how clustering changes the calculation.

Metrics: pick one decision metric and guardrails

DoorDash experiments often involve tradeoffs. A batching algorithm may raise orders per Dasher hour but hurt food quality. A promotion may improve D7 retention but increase refunds. A dispatch change may reduce delivery time while lowering Dasher earnings.

A strong metric setup has:

• One primary decision metric
• Guardrail metrics
• Diagnostic metrics
• Pre-planned segments

For logistics changes, primary metrics might include delivery time, on-time rate, or contribution profit per order. Guardrails might include cancellation rate, merchant wait time, Dasher idle time, customer rating, refund rate, or reorder rate.

Segments matter because effects can differ by market density, peak versus off-peak, new versus existing customers, restaurant category, distance band, Dasher mode, and supply-demand balance.

Do not claim success from an aggregate lift if suburban zones degrade while dense urban zones improve. That is exactly the kind of marketplace reasoning interviewers expect.

Causal inference: start with the estimand

Causal inference questions usually start with a metric change or a proposed rollout: late deliveries increased, a merchant variety launch changed retention, a new incentive changed Dasher behavior.

Do not jump straight to a model. Start by defining the causal question.

Are you estimating:

• Average treatment effect?
• Treatment effect on treated?
• Segment-specific effect?
• Local effect for compliers?

Then choose the method.

Randomized experiments are best when feasible. If not, DoorDash-style questions often point toward difference-in-differences, matched controls, synthetic control, or staggered rollout analysis.

For difference-in-differences:

$$\hat{\tau} = (Y_{treated,post} - Y_{treated,pre}) - (Y_{control,post} - Y_{control,pre})$$

The key assumption is parallel trends. You should say you would check pre-period trends, run placebo tests, and compare against matched markets.

Regression adjustment can improve precision, but it does not remove bias by itself. Use pre-treatment covariates only. Controlling for post-treatment variables, such as actual delivery time, can block part of the treatment effect you are trying to measure.

Example: diagnosing late deliveries

A good answer starts with definitions.

"Late" could mean late relative to quoted ETA, promised delivery window, or food-ready time. The business may care about order-level lateness, customer perception, merchant SLA, or retention.

Then decompose total delivery time:

• Merchant prep time
• Dasher assignment latency
• Travel to merchant
• Pickup wait
• Travel to customer
• Batching delay

Compare affected and unaffected markets, dayparts, merchant types, weather conditions, and distance bands. Once you have a leading hypothesis, choose the design.

If prep-time estimates look wrong, test merchant-facing prep prompts or adjusted buffers. If Dasher supply is the issue, a zone-hour switchback test of incentives may fit better than customer-level randomization.

The final recommendation should tie back to launch criteria: reduce late rate without hurting Dasher earnings, merchant wait, cancellations, refunds, or contribution margin.

What to practice

For SQL, practice joins, conditional aggregation, date grouping, ranking, rolling metrics, and percentiles. For experimentation, practice explaining why user-level randomization may fail and how switchbacks work. For causal inference, practice turning a vague metric movement into a clear estimand, method, and decision.

You can find related DoorDash-style and marketplace analytics prompts in the PracHub interview questions library.

If you want the full structured version with topic-by-topic practice cards, use the DoorDash Data Scientist interview prep cheatsheet as your study checklist.