DoorDash Data Engineer / Data Scientist Interview 2026｜SQL Window + A/B Test + Marketplace Metrics Deep Dive

DoorDash is North America's largest on-demand delivery platform, and Data Engineer (DE) / Data Scientist (DS) hiring volume in 2026 still ranks among the top of the marketplace / fintech bracket. 1point3acres reports show DE / DS pass rates exceed SDE — but the most common rejection reason is "two-sided marketplace business sense": many candidates have solid SQL and ML, yet can't explain supply / demand / matching, which is a deal-breaker.

This article focuses on the DE and DS tracks specifically (distinct from SDE): heavy SQL questions, two-sided A/B test variants, and marketplace metrics. For the SDE coverage, see our DoorDash SDE article.

DoorDash DE / DS Recruiting Pipeline

Stage	Duration	Content	Pass Rate
1. Recruiter Screen	30 min	Resume + ETL/ML experience + comp expectations	100% → 55%
2. SQL + Coding OA (HackerRank)	75 min	3 SQL + 1 Python	55% → 30%
3. Tech Phone Screen	60 min	SQL deep-dive + Python data wrangling	30% → 18%
4. Onsite Loop (4-5 rounds)	half-day	SQL / A/B / ML / Case / BQ	18% → 9%
5. Hiring Manager Chat	30 min	Team match + offer talk	9% → 8%

Key differences vs SDE:

DE onsite = 4 rounds: SQL + Data Modeling + ETL Design + BQ
DS onsite = 5 rounds: SQL + A/B Test + ML / Product Sense + Case + BQ
DS Product subtrack adds a Product Case round; DS Analytics subtrack adds a Causal Inference round

Question 1 — SQL Window Function (DE / DS shared)

Problem

Given an orders table:

order_id	user_id	restaurant_id	total	created_at

Write a SQL query: return all dates per restaurant in 2026-Q1 where daily order count grew >20% vs 7 days prior.

Approach

Classic window function + LAG:

WITH daily AS (
  SELECT
    restaurant_id,
    DATE(created_at) AS d,
    COUNT(*) AS orders_today
  FROM orders
  WHERE created_at >= '2026-01-01' AND created_at < '2026-04-01'
  GROUP BY restaurant_id, DATE(created_at)
),
with_prev AS (
  SELECT
    restaurant_id,
    d,
    orders_today,
    LAG(orders_today, 7) OVER (PARTITION BY restaurant_id ORDER BY d) AS orders_week_ago
  FROM daily
)
SELECT
  restaurant_id,
  d,
  orders_today,
  orders_week_ago,
  ROUND((orders_today - orders_week_ago) * 100.0 / NULLIF(orders_week_ago, 0), 2) AS pct
FROM with_prev
WHERE orders_week_ago IS NOT NULL
  AND orders_today > orders_week_ago * 1.2
ORDER BY restaurant_id, d;

Scoring:

Use LAG(..., 7) instead of 7 self-JOINs — the latter TLEs
NULLIF to avoid divide-by-zero
DATE(created_at) — DoorDash uses UTC, but many candidates forget timezone, causing date-rollover errors

Trap: the prompt says "vs 7 days prior". If you write LAG(orders_today, 1), that compares to yesterday — point deduction.

Question 2 — A/B Test Design (Two-Sided Marketplace, DS Required)

Problem

DoorDash wants to test a new "restaurant ranking algorithm" that promotes high-rated restaurants. Expected GMV will rise. Design the A/B test.

Bonus vs Penalty

Dimension	Penalty Answer	Bonus Answer
Unit	"User-level random split"	Call out two-sided contamination: a user in A still sees restaurants from B → cluster on city or use time-slice
Metrics	GMV only	GMV + restaurant fairness (small restaurants pushed down?) + Dasher utilization
Duration	"Run 2 weeks"	Compute sample size (MDE 5% + power 80%) and call out new-user cold-start effects
Guardrail	Not mentioned	New-user D7 retention may not drop > 1%

Recommended 4-Step Structure

Step 1. Goal — primary: GMV; secondary: Dasher avg delivery time; guardrail: new-user D7 retention
Step 2. Design — switchback by city × hour (avoid two-sided spillover)
Step 3. Sample size — MDE 3% on GMV, alpha 0.05, power 80% → ~60 city-hour cells, ~2 weeks
Step 4. Decision — t-test + Bayesian fallback for multiple comparisons

The DoorDash-specific signal: switchback experiment — the same city alternates between A and B by hour. 90% of candidates wrongly answer "user-level split", and this single mistake disqualifies them.

Question 3 — Causal Inference (DS Analytics Required)

Problem

Q3 launched a "Dasher bonus" program (extra $50 every 10 deliveries). After launch, average daily orders per Dasher rose from 12 → 14. Can you attribute this to the program? How would you rigorously estimate the ATE?

Scoring Dimensions

Identify confounders: seasonality, city expansion, Dasher base growth
Method choice: observational data → DiD (difference-in-differences) or Synthetic Control
Assumption check: parallel trends
Robustness: placebo test + alternative control groups

Recommended Framework

import pandas as pd
import statsmodels.formula.api as smf

# columns: city, dasher_id, day, daily_orders, treatment (0/1, eligible city), post (0/1, post-launch)
df["did"] = df["treatment"] * df["post"]
model = smf.ols(
    "daily_orders ~ treatment + post + did + C(city) + C(day)",
    data=df
).fit(cov_type="cluster", cov_kwds={"groups": df["city"]})
print(model.summary())
# DiD coefficient on 'did' = the ATE estimate

Scoring:

cov_type="cluster" is required — Dashers in the same city aren't independent
Two-way fixed effects: C(city) + C(day)
Report coefficient + p-value + 95% CI; don't just report the mean diff

Question 4 — ETL / Data Modeling (DE Required)

Problem

Design a dimensional model that answers 3 BI questions: (1) GMV trend per city per day; (2) restaurant cohort retention; (3) Dasher hourly utilization rate.

Star Schema

Fact Tables:
  - fact_orders (grain: order_id)
      city_key, restaurant_key, dasher_key, date_key, hour_key, gmv, items_count
  - fact_dasher_hours (grain: dasher × hour)
      dasher_key, date_key, hour_key, online_minutes, active_minutes, deliveries

Dimensions:
  - dim_restaurant (SCD Type 2 for cuisine / location changes)
  - dim_dasher (SCD Type 2 for tier changes)
  - dim_city
  - dim_date / dim_hour

Scoring:

Don't JOIN fact_orders and fact_dasher_hours into a single table — different grains will explode
SCD Type 2: restaurants change cuisine / location; you need historical snapshots to compute "GMV by old cuisine"
For utilization, fact_dasher_hours must include online_minutes; you cannot derive utilization from orders alone ("online but no order" is the core under-utilization signal)

Question 5 — Behavioral / Product Sense (DS Required)

High-Frequency Questions

Question	Tested
"What's a metric DoorDash should care about but doesn't?"	Product thinking + marketplace literacy
"How would you decide whether to launch DashPass in a new city?"	Business judgment + data-driven decision
"Tell me about a time you delivered against ambiguous requirements."	Ownership + communication
"What's wrong with using AOV (average order value) as a primary metric?"	Critical thinking on metrics

DoorDash-preferred answer template: always loop back to the three-sided marketplace (consumer / restaurant / Dasher); any metric or decision must consider all three.

4-Week Prep

Week	Focus	Resources
W1	SQL window / CTE / performance	LC SQL 50 + StrataScratch DoorDash bank (30+ Q)
W2	A/B Test in two-sided marketplaces	Trustworthy Online Controlled Experiments (Kohavi), ch. 1-7
W3	Marketplace metrics + DiD / Causal	DoorDash engineering blog + Mostly Harmless Econometrics ch. 5
W4	Mocks + Product Case	5 mock cases + 8 STAR-format project stories

2026 Comp (DE / DS)

Level	Title	Base	Stock (4yr vest)	Bonus
L4 (NG)	DE I / DS I	$150-170K	$60-100K	10-15%
L5	DE II / DS II	$175-205K	$120-180K	15-20%
L6	Senior DE / DS	$215-260K	$200-300K	20-25%

vs Meta/Google: base slightly lower, but bonus ceiling and RSU refresh are more generous. Stock-vest value varies with marketplace business cycles.

FAQ

Q1: Is DoorDash DE or DS easier to land?

For new grads, DE is slightly easier — SQL-heavy, lower ML bar, and standardized question banks. DS is more competitive because Product Sense + A/B test experience are also weighed. Candidates with data internships including ML should aim for DS; strong SQL but no ML should aim for DE.

Q2: Do I need deep Causal Inference for DoorDash DS?

Product DS subtrack can skip it (A/B test suffices). Analytics DS / Marketplace DS subtracks require comfort with DiD / IV / Synthetic Control — at least the assumption-check level. Strongly recommend Mostly Harmless Econometrics ch. 5 + DoorDash's own "Marketplace Experimentation" blog before onsite.

Q3: SQL or pandas in DoorDash DE / DS interviews?

Onsite SQL round forces SQL (HackerRank editor). Tech Phone Screen accepts pandas, but DE candidates should prefer SQL (more aligned). DS Causal / ML rounds can use Python (statsmodels / sklearn / scipy). Don't switch mid-round — pick one language and finish.

Q4: Why do so many candidates fail DoorDash A/B Test questions?

Because two-sided marketplace spillover is not standard textbook A/B testing. The "user-level random split" most internet companies teach fails at DoorDash — the same user sees restaurants from both arms. The expected answer is switchback by city × time, or cluster randomization by zip code.

Q5: Are non-CS backgrounds accepted for DoorDash DE / DS?

Yes. DS has hired pure math / stats / economics PhDs (zero CS background). DE leans CS / data engineering, but SDE-to-DE crossovers are common. Resume tip: make it scannable in 30 seconds — recruiter must spot marketplace / two-sided / user-behavior project work immediately.

Q6: How much sign-on does DoorDash give New Grads?

2026 cycle: DE / DS New Grad sign-ons typically $25-40K, paid over 1-2 years. 4-year vest 30-25-25-20 with 1-year cliff. Strong candidates with multiple offers can negotiate sign-on + RSU up by 15-20%.

Contact

If you're prepping DoorDash, Uber Eats, Instacart, GoPuff — the two-sided-marketplace cohort — the most under-estimated screen is A/B test + causal inference, which is the main filter. We've curated the 2025-2026 cycle DoorDash DE bank (30+) + DS Product Case bank (20+) + causal templates — feel free to reach out.

Add WeChat Coding0201, get the DoorDash DE / DS bank and book mocks.

Email: [email protected]
Telegram: @OAVOProxy