Uber Data Scientist Interview Guide

From hundreds of mock interviews, one pattern keeps showing up: candidates prep for Uber like it's a standard big tech DS loop, then get blindsided by how much the process revolves around fraud, risk, and marketplace economics. The interview includes dedicated SQL and data modeling rounds alongside product sense questions that skew heavily toward fraud analytics scenarios, which means your prep needs to be far more domain-specific than most people expect.

Uber Data Scientist Role

Uber's DS org sits across Mobility, Delivery, and Freight, and you're expected to own the full arc from problem framing through experiment design to stakeholder recommendation. Success after year one looks like having shipped experiment readouts that actually changed pricing thresholds or fraud detection rules in production, not just having built a model in a notebook. You'll spend real time in Uber's internal Querybuilder (Hive/Presto), Looker dashboards, and Python simulation notebooks, translating messy metric movements into clear recommendations for GMs who don't speak statistics.

A Typical Week

The writing load is what catches people off guard. Documentation and experiment writeups eat almost as much time as analysis itself, because Uber has a strong written culture where your experiment doc becomes the canonical decision record for the team. Infrastructure firefighting is real but small: you'll occasionally chase down a broken Hive table or a schema migration that nuked your dashboard, then ping data engineering and patch your query while you wait.

Projects & Impact Areas

Fraud and risk detection is the gravitational center of Uber DS work, spanning payment fraud, fake account detection, and promo abuse across billions of transactions. It bleeds into marketplace optimization in ways that aren't obvious: dynamic pricing experiments directly interact with fraud signals because surge manipulation is a real attack vector. On the newer end, teams are building LLM-powered AI agents for customer support escalation and fraud narrative summarization, which means you might find yourself evaluating when a language model's confidence is too low for a high-stakes risk decision, not just tuning a classifier.

Skills & What's Expected

Business acumen is rated expert-level, the highest of any skill dimension, yet most candidates underweight it in prep. Uber wants you to frame the problem before you solve it, which means knowing why a 1% false positive rate on fraud detection costs differently than a 1% false negative, and articulating that tradeoff to a non-technical GM. Don't mistake this for ML being unimportant: both machine learning and GenAI are rated high, so you need applied fluency in model selection, deployment tradeoffs, and LLM failure modes. The thing that won't help much is memorizing gradient boosting derivations when the interviewer really wants to hear you justify picking it over logistic regression given Uber's latency and interpretability constraints.

Levels & Career Growth

The jump that stalls careers is L5a to L5b. It's not about shipping better analyses; it's about owning a strategic DS agenda that spans multiple teams and visibly influences how the broader org makes decisions. L6 (Principal) roles involve setting experimentation standards or causal inference methodologies for an entire business unit like Mobility or Delivery, and the scope description in the source data makes clear this is a "technical vision for a broad domain" position, not just a senior IC seat.

Work Culture

Uber requires three days in-office (Tuesday, Wednesday, Thursday) at SF or other hub offices, with Monday and Friday as flexible remote days. The pace is fast but structured: most DS work runs in 1-2 week experiment cycles, and weeks land around 45-50 hours with occasional evening Slack threads but rarely weekend work. The culture rewards people who move quickly on ambiguous problems and aren't precious about their analysis being "done" before sharing it with stakeholders.

Uber Data Scientist Compensation

Uber's initial RSU grants may follow an irregular vesting schedule (something like 35/30/20/15 over four years rather than equal quarterly chunks). If your grant is front-loaded, your Year 1 income will be noticeably higher than Years 3 and 4. Model out all four years of any offer before comparing it to alternatives, because headline total comp can mask a real decline in take-home as you move through the back half of the vest.

On negotiation: from what candidates report, the RSU grant is often your strongest lever, with base salary less flexible. If you're holding a competing offer, lead with it early in the process. One tactic worth trying: request a signing bonus specifically to offset the income drop that comes with a declining vesting curve. Recruiters tend to have more room on one-time payments than on shifting you into a higher base band, though your mileage will vary by level and hiring urgency.

Uber Data Scientist Interview Process

The double SQL & Data Modeling round is the most unusual structural feature here, and from what candidates report, weak SQL performance is the single most common reason people get cut. Round 2 is a live coding session covering joins, window functions, and A/B testing fundamentals. Round 3 goes deeper into schema design, query optimization, and denormalization trade-offs. Treating these as one combined SQL prep block is a mistake; they test different muscles.

One thing that surprises candidates: even in the ML and Product Sense rounds, interviewers expect you to frame answers in terms of Uber's marketplace dynamics. Proposing a churn model without discussing how driver supply and rider demand interact, or designing an experiment without acknowledging interference effects across Uber's two-sided network, reads as surface-level. Borderline SQL performance doesn't necessarily sink you if the rest of your onsite signal is strong, but from what candidates report, it's rare to recover from two weak data rounds when the role leans this heavily on data fluency.

Uber Data Scientist Interview Questions

-- Assumed tables
-- identity_verification_attempts(attempt_id, user_id, created_at, decision, is_retry)
-- decision in ('approved','rejected', ...)

WITH base AS (
  SELECT
    a.attempt_id,
    a.user_id,
    DATE_TRUNC('day', a.created_at) AS day,
    a.decision
  FROM identity_verification_attempts a
  WHERE a.is_retry = FALSE
),
-- Dedupe ingestion duplicates by attempt_id
attempts_dedup AS (
  SELECT
    attempt_id,
    user_id,
    day,
    decision
  FROM (
    SELECT
      b.*,
      ROW_NUMBER() OVER (PARTITION BY b.attempt_id ORDER BY b.attempt_id) AS rn
    FROM base b
  ) x
  WHERE x.rn = 1
),
user_day AS (
  SELECT
    day,
    user_id,
    COUNT(*) AS attempts_cnt,
    SUM(CASE WHEN decision = 'approved' THEN 1 ELSE 0 END) AS approved_cnt
  FROM attempts_dedup
  GROUP BY 1, 2
),
day_agg AS (
  SELECT
    day,
    SUM(attempts_cnt) AS attempts_cnt,
    SUM(approved_cnt) AS approved_cnt,
    COUNT(DISTINCT CASE WHEN attempts_cnt >= 3 THEN user_id END) AS users_3plus_attempts
  FROM user_day
  GROUP BY 1
)
SELECT
  day,
  users_3plus_attempts,
  -- 7-day rolling approval rate on daily totals
  1.0 * SUM(approved_cnt) OVER (
    ORDER BY day
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  )
  / NULLIF(
      SUM(attempts_cnt) OVER (
        ORDER BY day
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
      ),
      0
    ) AS approval_rate_7d
FROM day_agg
ORDER BY day;

-- Assumed tables
-- eats_orders(order_id, user_id, payment_method, captured_at, captured_amount)
-- payment_disputes(dispute_id, order_id, dispute_type, dispute_amount, dispute_created_at)
-- dispute_type in ('chargeback','refund','retrieval_request', ...)

WITH orders AS (
  SELECT
    o.order_id,
    o.payment_method,
    DATE_TRUNC('week', o.captured_at) AS capture_week,
    o.captured_amount
  FROM eats_orders o
  WHERE o.captured_at IS NOT NULL
),
chargebacks_dedup AS (
  -- If multiple chargeback rows exist for the same order, keep the latest one.
  -- Alternative is SUM by order_id if your system truly emits additive amounts.
  SELECT
    d.order_id,
    d.dispute_amount AS chargeback_amount
  FROM (
    SELECT
      pd.*,
      ROW_NUMBER() OVER (
        PARTITION BY pd.order_id
        ORDER BY pd.dispute_created_at DESC, pd.dispute_id DESC
      ) AS rn
    FROM payment_disputes pd
    WHERE pd.dispute_type = 'chargeback'
  ) d
  WHERE d.rn = 1
),
cohort AS (
  SELECT
    o.capture_week,
    o.payment_method,
    SUM(o.captured_amount) AS captured_amount,
    SUM(COALESCE(cb.chargeback_amount, 0)) AS chargeback_amount
  FROM orders o
  LEFT JOIN chargebacks_dedup cb
    ON cb.order_id = o.order_id
  GROUP BY 1, 2
)
SELECT
  capture_week,
  payment_method,
  captured_amount,
  chargeback_amount,
  1.0 * chargeback_amount / NULLIF(captured_amount, 0) AS chargeback_rate
FROM cohort
ORDER BY capture_week, payment_method;

The two heaviest areas aren't independent, they compound. Framing a chargeback metric incorrectly in a product sense answer means your follow-up SQL query is solving the wrong problem, and interviewers at Uber treat that as a single connected failure, not two separate misses. From what candidates report, the most common misallocation of prep time is over-rotating on model architectures when the interview is really testing whether you can reason about fraud economics and then translate that reasoning into precise data work.

Drill fraud-scenario questions with full solutions, including the metric framing and SQL implementation together, at datainterview.com/questions.

How to Prepare for Uber Data Scientist Interviews

Uber hit $52B in revenue for full-year 2025, growing about 20% year over year. The headline bets shaping DS work right now are autonomous vehicles: a Lucid/Nuro robotaxi partnership targeting on-road testing in 2026, plus WeRide deploying 1,200 robotaxis across the Middle East by 2027. For data scientists, this creates genuinely new measurement problems, like how you design switchback experiments on a marketplace where autonomous and human supply coexist with different cost structures and reliability profiles.

The biggest mistake candidates make in their "why Uber" answer is talking about ride-hailing as if it's 2016. Interviewers have heard "I love the marketplace dynamics" a thousand times. What actually lands: connecting your skills to a specific current priority, like how causal inference gets harder when autonomous vehicles enter the supply mix, or how the robotaxi rollout across different geographies (Bay Area vs. Middle East) creates natural experiments with very different confounders.

Try a Real Interview Question

| experiment_assignments |
|------------------------|
| user_id | variant   | assigned_at |
|---------|-----------|-------------|
| 101     | control   | 2026-02-01  |
| 102     | treatment | 2026-02-01  |
| 103     | treatment | 2026-02-02  |
| 101     | treatment | 2026-02-03  |
| 104     | control   | 2026-02-04  |

| trips |
|-------|
| trip_id | user_id | requested_at | status    |
|---------|---------|--------------|-----------|
| 9001    | 101     | 2026-02-02   | completed |
| 9002    | 101     | 2026-02-05   | canceled  |
| 9003    | 102     | 2026-02-03   | completed |
| 9004    | 103     | 2026-02-06   | failed    |
| 9005    | 104     | 2026-02-06   | completed |

-- Write SQL that outputs one row per variant with:
-- users, users_with_completed_trip, completion_rate, abs_lift_vs_control

WITH params AS (
  SELECT
    DATE '2026-02-01' AS start_date,
    DATE '2026-02-07' AS end_date
),
latest_assignment AS (
  SELECT user_id, variant
  FROM (
    SELECT
      ea.user_id,
      ea.variant,
      ea.assigned_at,
      ROW_NUMBER() OVER (PARTITION BY ea.user_id ORDER BY ea.assigned_at DESC) AS rn
    FROM experiment_assignments ea
    JOIN params p
      ON ea.assigned_at BETWEEN p.start_date AND p.end_date
  ) x
  WHERE rn = 1
),
user_completed_trip AS (
  SELECT
    t.user_id,
    1 AS has_completed
  FROM trips t
  JOIN params p
    ON t.requested_at BETWEEN p.start_date AND p.end_date
  WHERE t.status = 'completed'
  GROUP BY t.user_id
),
variant_metrics AS (
  SELECT
    la.variant,
    COUNT(*) AS users,
    SUM(COALESCE(uct.has_completed, 0)) AS users_with_completed_trip,
    1.0 * SUM(COALESCE(uct.has_completed, 0)) / NULLIF(COUNT(*), 0) AS completion_rate
  FROM latest_assignment la
  LEFT JOIN user_completed_trip uct
    ON la.user_id = uct.user_id
  GROUP BY la.variant
),
control AS (
  SELECT completion_rate AS control_rate
  FROM variant_metrics
  WHERE variant = 'control'
)
SELECT
  vm.variant,
  vm.users,
  vm.users_with_completed_trip,
  vm.completion_rate,
  vm.completion_rate - c.control_rate AS abs_lift_vs_control
FROM variant_metrics vm
CROSS JOIN control c
ORDER BY vm.variant;

Uber's SQL rounds reward fluency with window functions, self-joins, and conditional aggregations chained together under time pressure, often framed around event-sequence analysis on Uber's marketplace data (trip logs, payment events, account activity). Expect to write queries that go beyond simple aggregations and require you to reason about temporal ordering and edge cases in messy transactional data. Build that muscle at datainterview.com/coding.

Test Your Readiness

Uber's product sense questions often tie back to the robotaxi rollout, marketplace experimentation, and metric design for new initiatives. Pressure-test yourself on those patterns at datainterview.com/questions.