Uber Data Analyst Case Interview — Marketplace Health, SQL Diagnostics, and Experiment Design

This 60‑minute case mirrors Uber’s real onsite style for Data Analysts, emphasizing marketplace thinking, crisp SQL, and decision-oriented insights. You’ll diagnose a live-ops problem in either Mobility or Delivery and recommend data-driven actions that balance growth, reliability, and customer experience. Format and flow (typical at Uber): 1) Problem framing (5–7 min): The interviewer presents an ambiguous scenario, e.g., “Weekend rider cancellations spiked in Los Angeles after a pricing update,” or “Eats checkout conversion dipped post fee-transparency change.” You’ll clarify goals, stakeholders (riders/drivers or eaters/couriers/merchants), constraints (cost, fraud/safety, latency), and define success. 2) Metric tree + marketplace lens (10–12 min): Build a metric tree from a north-star (e.g., completed trips, on-time deliveries, or gross bookings) down to guardrails (cancellation rate, ETA/promise accuracy, take rate, defect rate, support contacts). Show supply–demand mechanics: request→accept→arrive→pickup→complete, or browse→select→checkout→dispatch→delivered. Call out geo/time/device segments, surge/discount bands, and new vs. returning cohorts. 3) SQL-driven diagnostics (15–20 min): Walk through how you’d query large-scale event and fact tables (trips, requests, courier_status, merchant_menu_events, pricing_events). Expect to outline joins, cohorting, window functions, and anomaly isolation (e.g., before/after windows, DiD by market). Examples: compute driver acceptance by surge bucket; conversion by fee disclosure variant; ETA inflation vs. supply hours online; merchant/menu outages correlating with drop-offs. Be explicit about data validity (late-arriving events, deduping, timezone handling, unit consistency) and reproducibility. 4) Experiment/rollout plan (10–12 min): Propose an A/B or switchback test (common at Uber for marketplace features). Define primary metric(s) and guardrails, unit of randomization (user, merchant, or geo cell), expected effect size, sample size/power intuition, runtime, and CUPED/stratification to reduce variance. Address interference (courier pool spillover, surge propagation), ramp strategy, and decision criteria. 5) Recommendation & tradeoffs (5–8 min): Summarize what you’d ship, what to monitor in the first 24–72 hours (marketplace stability, SLA hits, cancellations by reason code), and next steps (dashboards/alerts, country ops comms, rollback plan). Communicate in Uber’s style: concise, metrics-first, and action-biased. What the interviewer focuses on: - Marketplace intuition: Can you reason about two-sided dynamics, ETAs, surge/incentives, batching, and fulfillment probabilities? - Metric design: Clear north-star vs. guardrails; sensitivity to geography, time-of-day, and promo/surge bands. - Practical SQL: Window functions, segmentation, and careful joins; awareness of data pitfalls and logging changes. - Experiment rigor: Interference, unit selection, guardrails for safety/fraud, and decision thresholds tied to business impact. - Communication: Structured, written-first clarity; crisp tradeoffs and an owner mindset aligned with ops partners. Example prompts you might encounter: - Mobility: “Post-pricing update, rider cancellations rose on Friday nights in LA. Diagnose root causes and propose a mitigation test.” - Delivery: “Eats checkout conversion dropped in select US metros after fee transparency changes. Identify the driver, quantify impact, and design an experiment to recover conversion without hurting courier earnings or on-time rate.”