DoorDash Business Model & Trade-offs Questions
Analysis of DoorDash's business model within a platform-based marketplace context, including revenue streams (delivery fees, commissions, subscription), cost structure (logistics, driver incentives), partnerships, pricing strategies, market expansion decisions, and the strategic trade-offs between growth, profitability, and delivering value to customers.
HardTechnical
53 practiced
Design the architecture for a forecasting pipeline that predicts GMV 12 months ahead at city-level granularity. Describe feature selection (historical GMV, promotions, weather, macro indicators), model families you would consider, how you would evaluate model accuracy, and how BI would serve forecasts to stakeholders with uncertainty bounds.
Sample Answer
Requirements & constraints:- Forecast city-level GMV 12 months ahead, daily/weekly aggregation, support for scenario analysis, explainability, and uncertainty bounds for stakeholders.Architecture (high-level):- Ingest layer: ETL from OLTP/warehouse for orders (GMV), promotions, product catalogs, weather API, macro data (CPI, unemployment), events calendar.- Storage: Partitioned time-series table in data warehouse (BigQuery/Redshift) with city_id, date, gmvs, features.- Feature engineering layer: Airflow jobs compute rolling lags (t-1,t-7,t-30), moving averages, seasonality indicators (Dow, month, holiday flags), promotion flags (price discount %, promo_type), weather aggregates (temp, precipitation), macro interpolation to city level.- Modeling layer: Train models per city or clustered groups; store models and forecasts in feature store / model registry.- Serving & BI: Export forecasts + lower/upper bounds to BI-ready table; expose via Looker/Tableau + REST API for programmatic access.Feature selection & engineering:- Core: historical GMV lags and rolling statistics (7/30/90d), year-ago values, trend features (slope over windows).- Promotions: binary flags, intensity (discount %), promo duration, promotion type interactions with category mix.- Weather: city-level daily temp, precipitation, extreme-event flags, aggregated to forecast frequency and relevant lags (e.g., 7/30d).- Macro: monthly CPI, unemployment, consumer sentiment; forward-lagged or scenario-driven inputs for 12-month horizon.- Additional: population, store openings, marketing spend, events; encode categorical features, create interaction terms (promo*season).- Selection: start with domain-driven features; use correlation analysis, permutation importance, SHAP to prune; remove multicollinearity; regularize.Model families to consider:- Benchmark: Seasonal naive and ETS (Holt-Winters) for seasonality baseline.- Statistical: SARIMAX/SARIMAX with exogenous regressors (promos, macro).- Machine Learning: Gradient Boosted Trees (XGBoost/LightGBM) on lag features and exogenous vars — good for heterogenous city behaviors.- Time-series ML: Prophet with regressors for holidays/promos.- Deep Learning: Temporal Fusion Transformer (TFT) or Seq2Seq LSTM for probabilistic multi-horizon forecasting when ample data exists.- Hierarchical reconciliation: Use bottom-up or optimal reconciliation (MinT) to ensure city forecasts roll up to region/global consistency.- Ensembles: Weighted blend (by validation performance) of statistical + ML + DL models to improve stability.Evaluation strategy:- Backtesting with rolling-origin (time series cross-validation) emulating production forecasting cadence; evaluate multiple forecasting horizons up to 12 months.- Metrics: MAE, RMSE for absolute error; MAPE or sMAPE for relative error (watch for zeros); CRPS / Pinball loss for probabilistic forecasts.- Calibration: Check prediction interval coverage (e.g., 80% interval contains ~80% of observed points).- Business KPIs: revenue-impact simulations (e.g., percentile scenarios), and alerting on large backtest deviations.- Explainability: Use SHAP/time decomposition to show drivers for each city-month forecast.Serving to BI & stakeholders:- Store forecasts and quantiles (median, 10/90 pct or 5/95) in a BI table with metadata (model version, run_date, confidence).- In dashboards (Tableau/Looker): - Default view: median forecast line with shaded uncertainty band (10–90%). - Scenario selector: toggle promo/macro scenarios which re-run model or apply delta adjustments to exogenous vars. - Drill-downs: city -> category -> channel; show feature contributions (top drivers) via bar charts (SHAP) and simple natural-language insights. - Alerts: highlight cities with expected >X% decline/increase or wide uncertainty.- Delivery: scheduled refresh (monthly/weekly), API for ad-hoc queries, CSV exports for finance planning.- Communication: include model health panel (backtest error, coverage, data freshness) and provenance (data lag, model version) so stakeholders trust forecasts.Operational considerations:- Retrain cadence: monthly or when data drift detected; automate CI/CD for models.- Governance: access controls, audit logs, and clear documentation of assumptions for exogenous scenario inputs.- Performance: cache heavy queries, precompute top-level aggregates for dashboards.This pipeline balances accuracy, interpretability and operational readiness so BI can deliver actionable city-level 12-month GMV forecasts with transparent uncertainty.
MediumTechnical
49 practiced
Given tables users(user_id, channel), orders(order_id, user_id, created_at, total_amount), and marketing_spend(channel, date, spend), describe and write SQL to compute CAC by channel and 12-month LTV per channel cohort. State assumptions and explain how you would align time windows for CAC and LTV.
Sample Answer
Approach (brief): define a cohort by each user’s acquisition month (use users.channel and users’ signup or first_order date), compute CAC as marketing spend during that acquisition month and channel divided by new users in that cohort, compute 12‑month LTV as total revenue from those cohort users in the 12 months after their acquisition divided by cohort size. Align windows by using the cohort month as the reference: spend in cohort month(s) maps to those newly acquired users, and revenue window = [acquisition_date, acquisition_date + 12 months).Assumptions:- users.user_id has the acquisition channel; users has signup_date (if not, we use first order date from orders).- marketing_spend.date is daily; we'll aggregate by month.- created_at and date are in UTC and comparable.- We measure cohorts by signup_month (YYYY-MM).- 12-month LTV includes all orders where order_date >= signup_date and < signup_date + interval '12 months'.- CAC uses spend in the same calendar month as signup (can extend to lookback windows if needed).SQL (Postgres-style):Key alignment notes:- Use the cohort month as the canonical time axis: spend is mapped to the same calendar month as acquisition (or a specified acquisition-window); revenue window is relative (0–12 months after signup).- If marketing spend attribution is more complex (multi-touch, impression windows), replace simple month mapping with an attribution model (first-touch, last-touch, or weighted).- Consider edge cases: users without signup_date, users with signup at month end (partial-month bias), refunds/returns (subtract), currency and timezone normalization.Validation and downstream: expose cohort_month, channel, CAC, LTV to BI dashboards; include cohort size and confidence (small n) flags.
sql
-- 1) build cohort (signup month) and cohort size
WITH user_acq AS (
SELECT
u.user_id,
u.channel,
COALESCE(u.signup_date, MIN(o.created_at) OVER (PARTITION BY u.user_id))::date AS signup_date
FROM users u
LEFT JOIN orders o ON o.user_id = u.user_id
),
cohort AS (
SELECT
user_id,
channel,
date_trunc('month', signup_date) AS cohort_month,
signup_date
FROM user_acq
),
cohort_sizes AS (
SELECT
channel,
cohort_month,
COUNT(*) AS new_users
FROM cohort
GROUP BY 1,2
),
-- 2) monthly marketing spend by channel/month
monthly_spend AS (
SELECT
channel,
date_trunc('month', date)::date AS month,
SUM(spend) AS spend
FROM marketing_spend
GROUP BY 1,2
),
-- 3) aggregate spend for cohort: map spend for channel & cohort_month
cohort_spend AS (
SELECT
c.channel,
c.cohort_month,
COALESCE(ms.spend,0) AS total_spend
FROM (
SELECT DISTINCT channel, cohort_month FROM cohort
) c
LEFT JOIN monthly_spend ms
ON ms.channel = c.channel
AND ms.month = c.cohort_month
),
-- 4) revenue from cohort users in their first 12 months
orders_12m AS (
SELECT
c.channel,
c.cohort_month,
o.user_id,
o.order_id,
o.created_at,
o.total_amount
FROM cohort c
JOIN orders o
ON o.user_id = c.user_id
AND o.created_at >= c.signup_date
AND o.created_at < (c.signup_date + interval '12 months')
),
cohort_revenue AS (
SELECT
channel,
cohort_month,
SUM(total_amount) AS revenue_12m
FROM orders_12m
GROUP BY 1,2
)
-- final: CAC and 12m LTV per channel/cohort_month
SELECT
cs.channel,
cs.cohort_month,
cs.new_users,
COALESCE(sp.total_spend,0) AS total_spend,
CASE WHEN cs.new_users>0 THEN sp.total_spend::numeric / cs.new_users ELSE NULL END AS cac,
COALESCE(rev.revenue_12m,0) AS revenue_12m,
CASE WHEN cs.new_users>0 THEN rev.revenue_12m::numeric / cs.new_users ELSE NULL END AS ltv_12m
FROM cohort_sizes cs
LEFT JOIN cohort_spend sp
ON sp.channel = cs.channel AND sp.cohort_month = cs.cohort_month
LEFT JOIN cohort_revenue rev
ON rev.channel = cs.channel AND rev.cohort_month = cs.cohort_month
ORDER BY cs.channel, cs.cohort_month;HardTechnical
74 practiced
Executive leadership asks for a dashboard that surfaces the trade-offs between growth and profitability across markets. Describe what KPIs and visualizations you would include to quantify growth (e.g., order volume, new users) and profitability (e.g., contribution margin, take rate, unit economics), and outline how BI would enable scenario analysis for leaders deciding where to invest.
Sample Answer
Requirements & constraints:- Executive view comparing markets by growth vs profitability, with ability to drill into segments, time windows, and run invest/divest scenarios over 12–36 months.- Low-latency interactive BI (Tableau/Power BI/Looker), linked to reliable ETL and product/finance sources.KPIs to quantify growth (primary + supporting):- Order volume (orders/month, YoY%): raw growth signal- New users (acquisition by channel), active users (DAU/MAU), conversion rate- Revenue (GMV & net revenue), ARPU/ARPPU- Growth velocity metrics: MoM / QoQ growth rates, cohort retentionKPIs to quantify profitability / unit economics:- Take rate (%) = Net revenue / GMV- Contribution margin per order = (Net revenue − variable cost) / order- CAC (by channel) and CAC payback period- LTV (net contribution per user) and LTV:CAC ratio- Fixed vs variable cost split; operating margin by market- Adjusted EBIT/EBITDA and margin trendsRecommended visualizations:- Scatter plot (x = growth rate, y = contribution margin) with bubble size = GMV or LTV:CAC; quadrants show “Invest”, “Optimize”, “Harvest”, “Exit”- Time-series small multiples: revenue, orders, margin per market- Cohort table/heatmap: retention and LTV build-up by acquisition month- Waterfall per-market P&L to surface drivers (take rate, variable costs, CAC)- Funnel visualization: visits → signups → orders → repeat buyers- Map view with toggles for KPIs to show geographic patterns- Scenario panel: inputs and outcome charts (see below)How BI enables scenario analysis:- Parameterized what-if models embedded in the dashboard: allow executives to change CAC (by channel), marketing spend, price/take-rate, or fulfillment cost assumptions and instantly recalculate projected revenue, contribution margin, LTV, CAC payback, and NPV over a 12–36 month horizon.- Present Monte Carlo or sensitivity analysis (tornado chart) to show which levers most affect profitability and growth.- Pre-built scenarios: “Aggressive invest”, “Maintain”, “Cost-cut” showing impacts on cash burn, breakeven timeline, and expected incremental users/orders.- Enable cohort-level projection: apply retention and ARPU uplift assumptions to cohorts to forecast LTV and cash flows.Data & governance notes:- Sources: orders/transactions, user events, marketing spend, finance GL, fulfillment costs.- Key assumptions surfaced and versioned; allow toggling between GAAP and adjusted metrics.- Include confidence/coverage indicators and currency normalization.Decision guidance:- Use quadrant + scenario outputs to recommend where incremental spend produces acceptable payback and positive NPV; flag markets with high growth but negative unit economics for targeted experiments (pricing, fulfillment optimization) before broad investment.
HardSystem Design
46 practiced
You must choose between batch and streaming architectures for a near-real-time fraud detection pipeline that feeds BI dashboards. Compare batch vs streaming in terms of latency, cost, complexity, data completeness, and operational overhead. Recommend an approach for DoorDash's scale and justify trade-offs.
Sample Answer
Requirements & constraints:- Near-real-time fraud detection feeding BI dashboards — stakeholders need fast detection (minutes), but dashboards can tolerate slightly higher latency for accurate aggregates.- DoorDash scale: high event volume (orders, payments, location), bursty traffic, multi-region.- Priorities: low detection latency for operational response, manageable cost, reliable aggregates for BI, maintainable ops.Comparison (batch vs streaming):- Latency: Batch (hourly/daily) → minutes–hours; Streaming → sub-second to seconds. For fraud alerts, streaming wins.- Cost: Batch leverages cheaper, large-window compute (e.g., scheduled DB/ETL); streaming requires always-on resources (Kafka, Flink) → higher steady cost, but can be tuned (autoscale, spot).- Complexity: Batch simpler (SQL ETL, Airflow); streaming requires event pipelines, stateful processing, schema evolution handling → higher development/QA effort.- Data completeness: Batch naturally reprocessable and easier to ensure completeness; streaming needs exactly-once or deduplication logic, windowing correctness.- Operational overhead: Batch ops are lower-frequency and simpler; streaming needs monitoring for lag, state size, backpressure and more sophisticated incident response.Recommendation for DoorDash BI:Adopt a hybrid architecture:1) Streaming layer for real-time fraud scoring and alerting (Kafka + stream processor like Flink/Beam): produce per-event fraud scores and operational metrics to a low-latency store (Redis, materialized views, or OLAP with realtime ingestion). This supports minutes-to-seconds dashboards and operations alerts.2) Micro-batch/Batch layer for authoritative aggregates and historical BI (Delta Lake / BigQuery / Snowflake via scheduled jobs): run reconciliations, backfills, and complex joins to produce accurate, audited metrics for executive dashboards.Justification & trade-offs:- Hybrid gives low latency where needed (operational fraud response) while keeping cost and complexity manageable by limiting streaming to scoring and near-real-time metrics. Heavy-weight, compute-expensive aggregations run in batch where cost per query is lower and correctness is easier.- Add reconciliation jobs that compare streaming outputs with batch ground-truth to catch drift/duplicates and ensure BI trust.Operational notes:- Invest in observability: end-to-end latency, watermarking, CDC validation.- Schema/versioning, idempotency, and replayable event storage to reduce streaming correctness risks.This balances speed, cost, and reliability for DoorDash scale while keeping BI dashboards accurate and timely.
MediumTechnical
69 practiced
You are asked to evaluate a potential new city for expansion. List the datasets you would require (internal and external), describe the top-line analyses and thresholds you would compute to recommend go/no-go, and outline the dashboard you would build to monitor early performance post-launch.
Sample Answer
Datasets required- Internal - Historical GMV, orders, AOV, cancellations, repeat rate, customer LTV by city/region - Marketing spend & channel-level CAC, conversion funnels, promo performance - Fulfillment/operational metrics: delivery times, cost per order, warehouse utilization - Partner/supply metrics: onboarding time, SKU fill rates, supplier capacity - Pricing/cost structure (COGS, local taxes, shipping)- External - Population, demographics, income, density (census/municipal) - Competitor presence & share (store locations, delivery coverage) - Consumer demand signals: search trends, category-level spend, foot traffic (SafeGraph/Google Mobility) - Local regulations, permit timelines, tax rates - Logistics data: road network, average delivery times, fuel/courier rates - Macroeconomic indicators and unemploymentTop-line analyses & thresholds- TAM & reachable market: population × category penetration rate → target GMV ≥ X (e.g., covers fixed costs + target margin within 12 months)- Unit economics per order: Contribution margin = AOV − variable cost − fulfillment − average promo. Threshold: positive contribution within 6 months and payback CAC ≤ 12 months.- Break-even analysis: fixed launch + operating costs / contribution margin → required orders per month; threshold: attainable given demand forecasts and marketing plan.- Supply-side feasibility: supplier coverage ≥ 90% SKU availability; delivery SLA achievable for ≥ 80% of target zip codes.- Sensitivity/scenario modeling: best/likely/worst for demand, CAC, fulfillment cost to assess risk.Monitoring dashboard (post-launch)- Top row (health): Daily GMV, orders, AOV, conversion rate, active customers, new vs. repeat- Unit economics card: CAC, contribution margin per order, payback period (rolling 30d)- Supply & ops: fulfillment rate, on-time delivery %, average delivery time, cost per delivery- Customer funnel: site visits → add-to-cart → checkout → purchase, by channel- Geography map: heatmap of orders, delivery success by ZIP, underserved zones- Alerts & targets: KPIs vs. forecast with automated thresholds (red/yellow/green), anomaly detection on traffic or fulfillment drops- Drill-downs: cohort LTV, promo lift analysis, channel ROIImplementation notes- Automate ETL daily; include ability to adjust model inputs (CAC, penetration) for scenario replay; share executive summary widget for weekly leadership reviews.
Unlock Full Question Bank
Get access to hundreds of DoorDash Business Model & Trade-offs interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.