Uber Data Engineer Interview Guide

From hundreds of mock interviews, here's the pattern that trips up Uber Data Engineer candidates: they prep like it's a SQL-heavy analytics role and get blindsided by the software engineering bar. Uber's DE org sits closer to platform engineering than to BI. You're expected to write production-grade PySpark jobs that deduplicate billions of Kafka trip events, then own the on-call pager for the pipelines those jobs feed.

Uber Data Engineer Role

At Uber, a Data Engineer builds and operates the pipelines behind the marketplace's nervous system. Trip events flow through Kafka, driver supply signals land in Hive, and Eats order fulfillment metrics refresh for downstream data science teams. Success after year one means product teams trust your tables enough to build surge pricing and ETA models on them without a second thought.

A Typical Week

The thing that catches most candidates off guard is how much infrastructure work rivals pure coding. You're not just writing Spark jobs. You're cleaning up orphaned HDFS partitions, writing null-rate checks that page the on-call, and doing storage hygiene on shared Hadoop clusters before quota reviews hit.

Projects & Impact Areas

The core work revolves around Uber's marketplace signals: real-time trip deduplication feeding the trips fact table, driver incentive calculations that consolidate six upstream sources, and the dimensional models powering surge pricing decisions. Data quality isn't a side quest you tackle when things break. You'll contribute to internal tooling like schema registries and anomaly detection on data freshness, and Uber expects you to treat these systems as first-class products.

Skills & What's Expected

SQL is necessary but nowhere near sufficient. Uber's stack (Spark, Kafka, Hive, HDFS, Presto, Cassandra) means you need to reason about exactly-once semantics and executor OOM errors caused by data skew on keys like city_id in São Paulo. Business acumen scores surprisingly high, too. You're expected to explain why a driver earnings fact table exists and how it affects marketplace balance, not just demonstrate that you can build it.

Levels & Career Growth

From what candidates report on Blind, there's real confusion between L5ii and L6 offers for senior/staff candidates. Clarify your target level with the recruiter before the loop starts, because comp bands and interview expectations shift meaningfully between them. The blocker for L5-to-L6 promotion at Uber isn't technical skill; it's scope. Staff DEs drive alignment on platform-wide migrations (like evaluating Apache Iceberg as a replacement for Hive/ORC table formats), and if your impact stays within one team's pipelines, you'll stay at L5.

Work Culture

Uber mandates Tuesday, Wednesday, and Thursday in the San Francisco or Sunnyvale office, with Monday and Friday as flexible remote days. Remote-only arrangements for engineering roles are rare. On-call rotations are real, and the pager can be unforgiving when hundreds of downstream teams depend on your tables. The culture rewards ownership above all: you ship it, you monitor it, you fix it.

Uber Data Engineer Compensation

Uber's RSU grants vest over four years, often on a 25% annual schedule. That even cadence means no back-loading surprises, but it also means your initial grant size sets the trajectory for your total comp across the entire vesting window. Negotiate the RSU number hard before you sign, because there's no structural acceleration later to bail out a weak initial offer.

Both base salary and RSU grants are flexible levers at Uber, and a sign-on bonus can sweeten things further if you're holding a competing offer. Where most candidates leave money on the table: they fixate on one component instead of pushing across all three simultaneously. Come prepared to articulate your specific value (pipeline scale you've operated at, systems you've owned end-to-end) and let any competing offers do the rest of the talking.

Uber Data Engineer Interview Process

Budget 5 weeks from recruiter screen to offer. The final round, Uber's Bar Raiser, is run by a senior engineer from a completely different team who pressure-tests your technical depth and cultural fit against Uber's company-wide standards. From what candidates report, this round carries outsized weight in the final decision, so don't treat it as a casual chat after surviving the technical gauntlet.

The most common rejection reason isn't a weak system design or a shaky star schema. It's submitting code that doesn't actually execute. Uber's loop puts real emphasis on runnable, edge-case-tested solutions, and interviewers penalize pseudocode heavily. Pair that with the fact that Uber's on-call culture means DEs ship production code in Go, Java, and Python daily, and you can see why they care. Sharpen that muscle at datainterview.com/coding with problems that mirror Uber's flavor: graph traversals for geospatial routing, streaming aggregation structures, and log parsing.

Uber Data Engineer Interview Questions

1from __future__ import annotations
2
3from dataclasses import dataclass
4from typing import Dict, Iterable, List, Tuple
5
6
7@dataclass(frozen=True)
8class Event:
9    order_id: str
10    ts: int
11    status: str
12
13
14def final_status_per_order(events: Iterable[Tuple[str, int, str]]) -> Dict[str, Tuple[int, str]]:
15    """Return {order_id: (final_ts, final_status)}.
16
17    Tie break: if ts is equal, later event in the input wins.
18    """
19    best: Dict[str, Tuple[int, int, str]] = {}
20    # Store (ts, index, status) so that (ts, index) defines total order.
21    for idx, (order_id, ts, status) in enumerate(events):
22        if order_id not in best:
23            best[order_id] = (ts, idx, status)
24            continue
25
26        best_ts, best_idx, _ = best[order_id]
27        # Later timestamp wins; if tied, later index wins.
28        if ts > best_ts or (ts == best_ts and idx > best_idx):
29            best[order_id] = (ts, idx, status)
30
31    return {oid: (ts, status) for oid, (ts, _idx, status) in best.items()}
32
33
34if __name__ == "__main__":
35    sample = [
36        ("o1", 10, "CREATED"),
37        ("o1", 12, "ACCEPTED"),
38        ("o2", 8, "CREATED"),
39        ("o1", 12, "CANCELED"),  # same ts as ACCEPTED, later in input so wins
40        ("o2", 9, "DELIVERED"),
41    ]
42    out = final_status_per_order(sample)
43    assert out["o1"] == (12, "CANCELED")
44    assert out["o2"] == (9, "DELIVERED")
45    print(out)
46

1from __future__ import annotations
2
3from collections import defaultdict
4from typing import DefaultDict, Dict, Iterable, List, Tuple
5
6
7def max_concurrent_trips_per_driver(
8    events: Iterable[Tuple[str, int, str]]
9) -> Dict[str, int]:
10    """Compute max number of concurrent active trips per driver.
11
12    event_type: 'START' or 'END'
13    Ordering rule: if START and END share the same ts, END happens first.
14    """
15    per_driver: DefaultDict[str, List[Tuple[int, str]]] = defaultdict(list)
16    for driver_id, ts, event_type in events:
17        if event_type not in ("START", "END"):
18            raise ValueError(f"Unknown event_type: {event_type}")
19        per_driver[driver_id].append((ts, event_type))
20
21    result: Dict[str, int] = {}
22
23    # Define a stable total order: (ts, rank) where END rank 0, START rank 1.
24    def sort_key(item: Tuple[int, str]) -> Tuple[int, int]:
25        ts, event_type = item
26        rank = 0 if event_type == "END" else 1
27        return (ts, rank)
28
29    for driver_id, evs in per_driver.items():
30        evs.sort(key=sort_key)
31        active = 0
32        max_active = 0
33        for _ts, event_type in evs:
34            if event_type == "END":
35                active -= 1
36            else:
37                active += 1
38                if active > max_active:
39                    max_active = active
40        # If data is imperfect, active could go negative; clamp is a product choice.
41        result[driver_id] = max_active
42
43    return result
44
45
46if __name__ == "__main__":
47    sample = [
48        ("d1", 5, "START"),
49        ("d1", 7, "START"),
50        ("d1", 7, "END"),  # END at same ts should apply first
51        ("d1", 9, "END"),
52        ("d2", 1, "START"),
53        ("d2", 2, "END"),
54    ]
55    out = max_concurrent_trips_per_driver(sample)
56    assert out["d1"] == 1
57    assert out["d2"] == 1
58    print(out)
59

1/* Daily city-level completion funnel metrics */
2SELECT
3  city_id,
4  trip_date,
5  /* All requests, regardless of status */
6  COUNT(*) AS total_requests,
7  /* Completed requests only */
8  SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) AS completed_trips,
9  /* Unique riders who made a request that day */
10  COUNT(DISTINCT rider_id) AS unique_riders,
11  /* Safe decimal rate */
12  (SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) * 1.0)
13    / NULLIF(COUNT(*), 0) AS completion_rate
14FROM fact_trip
15GROUP BY
16  city_id,
17  trip_date
18ORDER BY
19  trip_date,
20  city_id;

1/* Latest known trip status as of a cutoff timestamp.
2   Assumptions:
3   - event_ts is the business event time
4   - ingestion_ts is used only to break ties deterministically
5   - :cutoff_ts is a bind parameter (timestamp)
6*/
7WITH filtered AS (
8  SELECT
9    trip_id,
10    event_ts,
11    status,
12    ingestion_ts
13  FROM raw_event_trip_status
14  WHERE event_ts <= :cutoff_ts
15), ranked AS (
16  SELECT
17    trip_id,
18    event_ts,
19    status,
20    ingestion_ts,
21    ROW_NUMBER() OVER (
22      PARTITION BY trip_id
23      ORDER BY event_ts DESC, ingestion_ts DESC
24    ) AS rn
25  FROM filtered
26)
27SELECT
28  trip_id,
29  event_ts AS latest_event_ts,
30  status AS latest_status,
31  ingestion_ts AS latest_ingestion_ts
32FROM ranked
33WHERE rn = 1;

Uber's loop is structured so that no single skill carries you through. A candidate who aces the SQL round but freezes when asked to sketch a real-time fraud detection pipeline for Eats merchants (where schema evolution, consumer lag, and exactly-once delivery all collide in one prompt) won't clear the bar. The most common prep mistake, from what candidates report, is treating system design as a soft round you can improvise through, when in practice it's where pipeline knowledge, infrastructure tradeoffs, and Uber-specific context (Kafka into Hive, Presto query patterns over trip/rider schemas, SLA monitoring for marketplace signals) get stress-tested simultaneously.

Practice Uber-specific questions across all six areas at datainterview.com/questions.

How to Prepare for Uber Data Engineer Interviews

Uber's biggest bet right now is autonomous mobility layered on top of its existing marketplace. The company plans to deploy at least 1,200 WeRide robotaxis across the Middle East by 2027 and bring a Lucid/Nuro robotaxi to market later in 2026. Meanwhile, the core business hit $52 billion in revenue in 2025, up roughly 20% year over year.

For a data engineer, that dual focus creates a concrete challenge: ingesting third-party AV telemetry from WeRide and Nuro alongside Uber's own Kafka-based trip event streams, all feeding into the same Spark/Hive/Presto foundation that powers surge pricing and ETA models. When you're asked "why Uber," skip the brand story and talk about that tension. Reference a specific post from their tech stack blog series, or describe how merging heterogeneous AV sensor data with first-party marketplace signals creates schema evolution and data quality problems you'd be excited to solve.

Try a Real Interview Question

1from typing import Iterable, List, Tuple
2
3
4def sessionize_events(
5    events: Iterable[Tuple[str, int]],
6    gap_seconds: int,
7    watermark: int,
8) -> List[Tuple[str, int, int, int]]:
9    """Sessionize per-user events with a gap threshold and a watermark.
10
11    Args:
12        events: Iterable of (user_id, ts) events. Not guaranteed to be sorted.
13        gap_seconds: Gap threshold in seconds. Same session if next_ts - prev_ts <= gap_seconds.
14        watermark: Ignore late events where ts < watermark.
15
16    Returns:
17        List of (user_id, start_ts, end_ts, event_count) sorted by user_id then start_ts.
18    """
19    pass
20

1from typing import Iterable, List, Tuple, Dict
2
3
4def sessionize_events(
5    events: Iterable[Tuple[str, int]],
6    gap_seconds: int,
7    watermark: int,
8) -> List[Tuple[str, int, int, int]]:
9    """Sessionize per-user events with a gap threshold and a watermark.
10
11    Args:
12        events: Iterable of (user_id, ts) events. Not guaranteed to be sorted.
13        gap_seconds: Gap threshold in seconds. Same session if next_ts - prev_ts <= gap_seconds.
14        watermark: Ignore late events where ts < watermark.
15
16    Returns:
17        List of (user_id, start_ts, end_ts, event_count) sorted by user_id then start_ts.
18    """
19    if gap_seconds < 0:
20        raise ValueError("gap_seconds must be non-negative")
21
22    per_user: Dict[str, List[int]] = {}
23    for user_id, ts in events:
24        if ts < watermark:
25            continue
26        per_user.setdefault(user_id, []).append(ts)
27
28    sessions: List[Tuple[str, int, int, int]] = []
29
30    for user_id, ts_list in per_user.items():
31        ts_list.sort()
32        start = ts_list[0]
33        end = ts_list[0]
34        count = 1
35
36        for ts in ts_list[1:]:
37            if ts - end <= gap_seconds:
38                end = ts
39                count += 1
40            else:
41                sessions.append((user_id, start, end, count))
42                start = ts
43                end = ts
44                count = 1
45
46        sessions.append((user_id, start, end, count))
47
48    sessions.sort(key=lambda x: (x[0], x[1]))
49    return sessions
50

Uber's DE coding rounds sit closer to applied data manipulation than abstract puzzle-solving, from what candidates report. Sharpen that muscle at datainterview.com/coding, focusing on problems that involve transforming structured event data rather than pure algorithmic brain teasers.

Test Your Readiness

Gaps in your answers point you to exactly where to focus. Drill those weak spots at datainterview.com/questions before your loop.