Uber Data Analyst Interview Guide

Most candidates prep for Uber's data analyst interviews by grinding SQL and brushing up on statistics. That's necessary but not sufficient. The ones who stall out can't think like someone operating a two-sided marketplace where a pricing tweak in one city cascades into driver supply shifts across an entire region.

Uber Data Analyst Role

Uber's data analysts own metric definitions and analytical frameworks across Mobility and Delivery, the company's two revenue engines. Success after year one means a product or ops partner points to your framework when making a decision about driver incentives in a specific metro or activation windows for a loyalty program, not that you shipped a high volume of dashboards.

A Typical Week

The ratio that catches people off guard is how much time goes to writing and stakeholder communication versus pure coding. You'll spend more hours building a findings doc with a clear narrative arc than you will inside a query editor. That's the real job: not answering "what happened?" but building the argument that changes what happens next.

Projects & Impact Areas

Marketplace health work (surge pricing effectiveness, ETA accuracy, driver incentive ROI) carries outsized financial weight because Uber's core business is a real-time matching problem where small analytical wins compound across millions of daily trips. Eats analysts, meanwhile, define and monitor metrics like restaurant churn and delivery basket size that show up in quarterly earnings. The analytical surface area keeps expanding as Uber invests in newer revenue streams like advertising.

Skills & What's Expected

Business acumen is the most underrated skill for this role. SQL proficiency is table stakes (window functions, sessionization queries, self-joins on event logs), and everyone preps for it. Scores for business acumen and data visualization sit just as high as statistics, which matches what interviewers actually screen for: can you catch Simpson's paradox in marketplace data, frame an ambiguous question into a testable hypothesis, then present the answer to a non-technical ops lead who controls budget? That combination separates offers from "strong technically but not quite there" feedback.

Levels & Career Growth

L4 is the most common external hire point, and it's where you'll compete against the deepest candidate pool. Getting from L4 to L5a isn't about writing better SQL. It hinges on owning metric frameworks that teams outside your own adopt, proactively surfacing business opportunities nobody assigned you, and mentoring junior analysts.

Work Culture

Uber requires Tuesdays and Thursdays in the San Francisco office, with most analytics teams clustering collaboration on those days. Analysts are expected to push back on stakeholders with data rather than just fulfill requests, which is empowering if you have conviction but jarring if you're coming from a service-oriented analytics team. Protecting deep work time takes active calendar management, because the volume of ad-hoc Slack requests from Rides and Eats partners is constant.

Uber Data Analyst Compensation

The front-loaded vesting schedule means your effective comp peaks in year one, then declines each subsequent year unless refresher grants make up the difference. From what candidates report, refreshers vary based on performance, so treat the initial grant as the only guaranteed equity when comparing offers.

Both base salary and RSU grants are negotiable, according to Uber's own offer structure. If you have a competing offer from another marketplace company, lean into the equity conversation. RSU grants and signing bonuses tend to give recruiters more room to work with than base alone, and at Uber specifically, the jump in stock grant size between L3 and L4 is dramatic enough that pushing for the higher level (if your experience supports it) can matter more than haggling over individual components.

Uber Data Analyst Interview Process

The take-home assignment at round three is where Uber filters hardest. It covers data modeling, statistical analysis, and visualization across a real-world dataset, and reviewers score your problem framing and assumptions as heavily as your code. Candidates who treat it like a homework problem (dump charts, skip the business narrative) get cut before the onsite even begins. The most common rejection reason across the full loop is poor communication of insights, specifically presenting analysis without connecting it back to Uber's marketplace dynamics like supply/demand imbalance or rider-driver tradeoffs.

Your onsite rounds each probe a distinct skill. The Case Study presentation forces you to defend your take-home methodology under pressure, while Product Sense & Metrics asks you to build metric hierarchies for real Uber features (teen accounts, Eats advertising). A gap in either of those rounds is hard to recover from, because Uber's cultural values like "See the forest and the trees" show up as explicit evaluation criteria, and interviewers expect you to toggle between granular data and strategic implications in every answer.

Uber Data Analyst Interview Questions

WITH dedup_events AS (
  -- Remove exact duplicate event rows from late or repeated ingestion
  SELECT DISTINCT
    trip_id,
    event_ts,
    event_type
  FROM trip_events
), last_event AS (
  -- Pick the latest event per trip to define terminal status
  SELECT
    trip_id,
    event_type AS last_event_type,
    event_ts AS last_event_ts
  FROM (
    SELECT
      trip_id,
      event_type,
      event_ts,
      ROW_NUMBER() OVER (
        PARTITION BY trip_id
        ORDER BY event_ts DESC, event_type DESC
      ) AS rn
    FROM dedup_events
  ) x
  WHERE rn = 1
), trip_labels AS (
  SELECT
    t.trip_id,
    t.city_id,
    DATE(t.requested_at) AS request_date,
    CASE WHEN le.last_event_type = 'CANCELED' THEN 1 ELSE 0 END AS is_canceled
  FROM trips t
  LEFT JOIN last_event le
    ON le.trip_id = t.trip_id
  WHERE t.requested_at >= CURRENT_DATE - INTERVAL '28 days'
)
SELECT
  request_date,
  city_id,
  COUNT(*) AS trips,
  SUM(is_canceled) AS canceled_trips,
  1.0 * SUM(is_canceled) / NULLIF(COUNT(*), 0) AS cancel_rate
FROM trip_labels
GROUP BY 1, 2
ORDER BY 1, 2;

WITH order_base AS (
  SELECT
    o.order_id,
    o.city_id,
    o.merchant_id,
    o.eater_id,
    o.fulfillment_mode,
    o.created_at,
    o.promised_dropoff_at,
    o.actual_dropoff_at,
    o.order_status,
    CASE
      WHEN o.order_status = 'COMPLETED'
           AND o.actual_dropoff_at IS NOT NULL
           AND o.promised_dropoff_at IS NOT NULL
           AND o.actual_dropoff_at <= o.promised_dropoff_at
      THEN 1 ELSE 0
    END AS is_on_time,
    CASE
      WHEN o.order_status = 'COMPLETED'
           AND o.actual_dropoff_at IS NOT NULL
      THEN EXTRACT(EPOCH FROM (o.actual_dropoff_at - o.created_at)) / 60.0
      ELSE NULL
    END AS delivery_minutes
  FROM eats_orders o
  WHERE o.created_at >= DATE '2026-01-01'
),
attempts_agg AS (
  SELECT
    a.order_id,
    COUNT(*) AS assignment_attempts,
    MAX(CASE WHEN a.attempt_status = 'ACCEPTED' THEN 1 ELSE 0 END) AS had_accept
  FROM courier_assignment_attempts a
  GROUP BY 1
)
SELECT
  ob.city_id,
  DATE_TRUNC('day', ob.created_at) AS ds,
  COUNT(*) FILTER (WHERE ob.order_status = 'COMPLETED') AS completed_orders,
  AVG(ob.is_on_time::DOUBLE PRECISION) FILTER (WHERE ob.order_status = 'COMPLETED') AS on_time_rate,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY ob.delivery_minutes) FILTER (WHERE ob.order_status = 'COMPLETED') AS median_delivery_minutes,
  AVG(COALESCE(aa.assignment_attempts, 0)) AS avg_assignment_attempts_per_order
FROM order_base ob
LEFT JOIN attempts_agg aa
  ON ob.order_id = aa.order_id
GROUP BY 1, 2;

The distribution skews heavily toward conceptual reasoning over raw technical execution, which surprises candidates who walk in having only prepped SQL. Product sense and experimentation questions often chain together in Uber's loop: you'll propose a metric hierarchy for, say, Uber Eats' upfront tip feature, and then a follow-up (sometimes in the same round, sometimes the next) forces you to design an experiment that accounts for courier-side spillover effects on that very metric. The single biggest prep mistake is treating these areas as independent study tracks when Uber's interviewers explicitly probe the seams between them, especially around whether your proposed success criteria can actually survive a valid marketplace test.

Build that connective muscle with Uber-specific practice questions at datainterview.com/questions.

How to Prepare for Uber Data Analyst Interviews

Uber posted $52 billion in revenue for full-year 2025, up 20.1% year over year. The company's near-term priorities center on autonomous mobility: the Lucid/Nuro robotaxi partnership targets on-road autonomous testing in 2026, and WeRide plans to deploy 1,200 robotaxis across the Middle East by 2027. For analysts, that translates into AV fleet cost-per-trip modeling, supply/demand rebalancing when autonomous and human drivers share the same marketplace, and figuring out how to measure rider trust in a vehicle with no driver.

When interviewers ask "why Uber," they're filtering for candidates who grasp the specific analytical tension of a two-sided marketplace layering in autonomous supply. Don't gesture at Uber's scale. Instead, reference something concrete from the Q4 2025 prepared remarks, like the challenge of pricing robotaxi rides competitively against human drivers while maintaining marketplace liquidity, and explain what metric tradeoffs that creates.

Try a Real Interview Question

| trips |
|------|
| trip_id | user_id | city    | request_ts           | status    |
|--------|---------|---------|----------------------|-----------|
| 101    | 1       | SF      | 2026-01-03 08:15:00  | completed |
| 102    | 1       | SF      | 2026-01-08 09:10:00  | completed |
| 103    | 2       | SF      | 2026-01-20 18:30:00  | completed |
| 104    | 2       | SF      | 2026-01-29 07:05:00  | completed |
| 105    | 3       | NYC     | 2026-01-10 12:00:00  | completed |

| users |
|------|
| user_id | signup_ts           |
|--------|----------------------|
| 1      | 2025-12-28 10:00:00  |
| 2      | 2026-01-19 11:00:00  |
| 3      | 2026-01-02 08:00:00  |
| 4      | 2026-01-05 09:00:00  |
| 5      | 2026-02-01 10:00:00  |

-- Write a query that returns city-level D7 retention for first-time riders in Jan 2026.
-- Assumptions: status='completed' indicates a completed trip; use timestamps as-is.

WITH completed_trips AS (
  SELECT
    trip_id,
    user_id,
    city,
    request_ts
  FROM trips
  WHERE status = 'completed'
), first_trip AS (
  SELECT
    user_id,
    city AS first_city,
    request_ts AS first_trip_ts,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY request_ts) AS rn
  FROM completed_trips
), jan_first_trip AS (
  SELECT
    user_id,
    first_city AS city,
    first_trip_ts
  FROM first_trip
  WHERE rn = 1
    AND first_trip_ts >= TIMESTAMP '2026-01-01 00:00:00'
    AND first_trip_ts < TIMESTAMP '2026-02-01 00:00:00'
), retained_users AS (
  SELECT DISTINCT
    j.user_id,
    j.city
  FROM jan_first_trip j
  JOIN completed_trips t
    ON t.user_id = j.user_id
   AND t.request_ts > j.first_trip_ts
   AND t.request_ts <= j.first_trip_ts + INTERVAL '7' DAY
)
SELECT
  j.city,
  COUNT(*) AS first_time_riders,
  COUNT(r.user_id) AS retained_d7,
  ROUND(1.0 * COUNT(r.user_id) / NULLIF(COUNT(*), 0), 4) AS d7_retention
FROM jan_first_trip j
LEFT JOIN retained_users r
  ON r.user_id = j.user_id
 AND r.city = j.city
GROUP BY 1
ORDER BY 1;

Uber's event data is full of marketplace quirks: cancelled rides that still generate surge signals, multi-stop trips with partial completions, null values where pricing tiers shift mid-ride. Problems that force you to handle these edge cases in SQL (sessionization, window functions over sparse event logs) are close to what you'll actually encounter. Sharpen that skill at datainterview.com/coding.

Test Your Readiness

Use the quiz results to spot your weak areas, then drill those specific topics with practice questions at datainterview.com/questions.