Uber Data Engineer Interview Guide

From mock interviews we've run for Uber DE candidates, one pattern keeps showing up: strong coders who ace the PySpark round then can't sketch a real-time ingestion architecture for billions of Kafka events. Uber's data engineer role is platform engineering with a data flavor, and if you prep like it's just ETL work, you'll leave points on the table.

Uber Data Engineer Role

You're joining a team that builds and operates the data infrastructure behind every ride, every Eats order, and every freight shipment. Success after year one means you own a domain's pipelines end-to-end (say, the trips fact table or driver earnings) and at least one downstream team like pricing or safety considers your tables their source of truth. You're building the distributed systems that power Uber's sub-second dispatch and surge pricing decisions, not writing SQL for dashboards.

A Typical Week

The split that catches most candidates off guard is how much infrastructure work you do relative to pure analysis. Your mornings aren't spent exploring data; they're spent triaging SLA breaches on Hive tables that feed surge pricing, writing data quality monitors, and reclaiming storage on shared Hadoop clusters. If you're coming from an analytics-heavy DE role, recalibrate: this is closer to backend platform engineering where your PySpark dedup job for Kafka trip events is the product, not a means to a dashboard.

Projects & Impact Areas

Surge pricing pipelines and Eats restaurant ranking both depend on tables your team builds, so a schema change you propose on Wednesday can affect how millions of riders get priced by Friday. Uber's open-source projects like Cadence (workflow orchestration) and AresDB (real-time analytics) aren't just resume decoration; DEs actively contribute to these tools, which means you'll spend real cycles on platform improvements that shape how the entire company processes data. Data quality is a first-class ownership area too: you write the anomaly detection monitors, you own the pages when thresholds breach, and no separate QA team exists to catch your misses.

Skills & What's Expected

Software engineering and data architecture are both rated expert-level for this role, and that pairing tells you everything. ML knowledge sits at medium, which doesn't mean irrelevant; Uber explicitly expects you to understand how your pipelines feed ML-driven systems like fraud detection and driver-rider matching. What's underrated in most candidates' prep is business acumen, scored high but often neglected. Uber wants you to articulate why a 15-minute freshness SLA on the trips table matters to surge pricing accuracy, not just how to hit it.

Levels & Career Growth

The widget shows the level bands, but here's what it can't tell you: the jump where most people stall requires visible cross-team impact, not just flawless execution within your own pipelines. Did you define a data contract that three other teams adopted? Did you drive a platform migration that changed how the org thinks about table formats? Scope is the differentiator at every transition, and promotion committees at Uber look for evidence that you shaped decisions beyond your immediate domain.

Work Culture

Uber requires three days per week in-office (Tuesday, Wednesday, Thursday) at SF or Sunnyvale, with Monday and Friday flexible. The work schedule is demanding, with expectations of flexibility beyond standard hours, especially during on-call rotations when hundreds of downstream teams depend on your tables. The upside is genuine: you get direct product impact, real autonomy over your domain, and the kind of scale problems (petabytes of data, billions of daily events) that most companies can only describe hypothetically.

Uber Data Engineer Compensation

Uber's comp structure for Data Engineers breaks into three pieces: base salary, annual performance bonus, and RSUs that vest over four years (from what candidates report, often at 25% per year). Both base salary and RSU grants are considered the most flexible levers in negotiation, so don't assume either is locked. A sign-on bonus is also on the table, especially when you're holding a competing offer.

Competing offers are your strongest card here. Uber's recruiters expect candidates to shop around, and bringing a credible counter-offer gives you real room to push on equity or sign-on. If you're negotiating without one, focus your energy on clearly articulating the specific pipeline and platform experience you'd bring to Uber's Kafka/Spark/Flink stack, since that's the kind of scarcity the hiring team can use to justify a bump internally. Practice these conversations with real scenarios at datainterview.com/questions.

Uber Data Engineer Interview Process

From what candidates report, the most common reason people wash out isn't a single weak round. It's failing to write code that actually runs. Uber's two coding rounds and the SQL session all demand executable solutions, not pseudocode or hand-wavy logic. If your Spark job or Python script wouldn't pass a basic test harness, that's a rejection, even if your system design was solid.

The Bar Raiser round is where confident candidates get blindsided. It's run by an engineer outside your prospective team, and the round blends behavioral depth with technical pressure testing on past projects you've shipped. Treating it as a relaxed culture chat (instead of preparing STAR stories around ownership, cross-team influence, and pushing back on bad technical decisions) is the mistake that sinks people who cleared every other round cleanly.

Uber Data Engineer Interview Questions

from __future__ import annotations

from dataclasses import dataclass
from typing import Dict, Iterable, List, Tuple


@dataclass(frozen=True)
class Event:
    order_id: str
    ts: int
    status: str


def final_status_per_order(events: Iterable[Tuple[str, int, str]]) -> Dict[str, Tuple[int, str]]:
    """Return {order_id: (final_ts, final_status)}.

    Tie break: if ts is equal, later event in the input wins.
    """
    best: Dict[str, Tuple[int, int, str]] = {}
    # Store (ts, index, status) so that (ts, index) defines total order.
    for idx, (order_id, ts, status) in enumerate(events):
        if order_id not in best:
            best[order_id] = (ts, idx, status)
            continue

        best_ts, best_idx, _ = best[order_id]
        # Later timestamp wins; if tied, later index wins.
        if ts > best_ts or (ts == best_ts and idx > best_idx):
            best[order_id] = (ts, idx, status)

    return {oid: (ts, status) for oid, (ts, _idx, status) in best.items()}


if __name__ == "__main__":
    sample = [
        ("o1", 10, "CREATED"),
        ("o1", 12, "ACCEPTED"),
        ("o2", 8, "CREATED"),
        ("o1", 12, "CANCELED"),  # same ts as ACCEPTED, later in input so wins
        ("o2", 9, "DELIVERED"),
    ]
    out = final_status_per_order(sample)
    assert out["o1"] == (12, "CANCELED")
    assert out["o2"] == (9, "DELIVERED")
    print(out)

from __future__ import annotations

from collections import defaultdict
from typing import DefaultDict, Dict, Iterable, List, Tuple


def max_concurrent_trips_per_driver(
    events: Iterable[Tuple[str, int, str]]
) -> Dict[str, int]:
    """Compute max number of concurrent active trips per driver.

    event_type: 'START' or 'END'
    Ordering rule: if START and END share the same ts, END happens first.
    """
    per_driver: DefaultDict[str, List[Tuple[int, str]]] = defaultdict(list)
    for driver_id, ts, event_type in events:
        if event_type not in ("START", "END"):
            raise ValueError(f"Unknown event_type: {event_type}")
        per_driver[driver_id].append((ts, event_type))

    result: Dict[str, int] = {}

    # Define a stable total order: (ts, rank) where END rank 0, START rank 1.
    def sort_key(item: Tuple[int, str]) -> Tuple[int, int]:
        ts, event_type = item
        rank = 0 if event_type == "END" else 1
        return (ts, rank)

    for driver_id, evs in per_driver.items():
        evs.sort(key=sort_key)
        active = 0
        max_active = 0
        for _ts, event_type in evs:
            if event_type == "END":
                active -= 1
            else:
                active += 1
                if active > max_active:
                    max_active = active
        # If data is imperfect, active could go negative; clamp is a product choice.
        result[driver_id] = max_active

    return result


if __name__ == "__main__":
    sample = [
        ("d1", 5, "START"),
        ("d1", 7, "START"),
        ("d1", 7, "END"),  # END at same ts should apply first
        ("d1", 9, "END"),
        ("d2", 1, "START"),
        ("d2", 2, "END"),
    ]
    out = max_concurrent_trips_per_driver(sample)
    assert out["d1"] == 1
    assert out["d2"] == 1
    print(out)

/* Daily city-level completion funnel metrics */
SELECT
  city_id,
  trip_date,
  /* All requests, regardless of status */
  COUNT(*) AS total_requests,
  /* Completed requests only */
  SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) AS completed_trips,
  /* Unique riders who made a request that day */
  COUNT(DISTINCT rider_id) AS unique_riders,
  /* Safe decimal rate */
  (SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) * 1.0)
    / NULLIF(COUNT(*), 0) AS completion_rate
FROM fact_trip
GROUP BY
  city_id,
  trip_date
ORDER BY
  trip_date,
  city_id;

/* Latest known trip status as of a cutoff timestamp.
   Assumptions:
   - event_ts is the business event time
   - ingestion_ts is used only to break ties deterministically
   - :cutoff_ts is a bind parameter (timestamp)
*/
WITH filtered AS (
  SELECT
    trip_id,
    event_ts,
    status,
    ingestion_ts
  FROM raw_event_trip_status
  WHERE event_ts <= :cutoff_ts
), ranked AS (
  SELECT
    trip_id,
    event_ts,
    status,
    ingestion_ts,
    ROW_NUMBER() OVER (
      PARTITION BY trip_id
      ORDER BY event_ts DESC, ingestion_ts DESC
    ) AS rn
  FROM filtered
)
SELECT
  trip_id,
  event_ts AS latest_event_ts,
  status AS latest_status,
  ingestion_ts AS latest_ingestion_ts
FROM ranked
WHERE rn = 1;

Uber's loop punishes candidates who prep like it's a generic algorithms screen. The sample questions reference Uber Eats order idempotency, trip-level fraud detection on rolling windows, and star schemas built around ride/promo fact tables, so your answers need to reflect how Uber's marketplace actually moves data, not abstract whiteboard patterns. The single costliest mistake is grinding coding problems while ignoring pipeline design and system design, which together dominate the evaluation and frequently overlap in the same question (designing a near-real-time Sales anomaly system, for instance, tests both simultaneously).

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

How to Prepare for Uber Data Engineer Interviews

Uber is making its biggest platform bet since Eats: autonomous mobility. The Lucid/Nuro partnership targets a robotaxi launch in 2026, while a separate WeRide deal aims to deploy at least 1,200 robotaxis across the Middle East by 2027. For data engineers, that translates to entirely new pipeline domains: sensor telemetry, vehicle state streams, and safety-critical SLAs that don't exist in human-driver trip data.

Meanwhile, the core business posted $52 billion in revenue, up roughly 20% year over year. Existing pipelines feeding pricing, dispatch, and Eats ranking still need to scale with that growth. You'd be building new autonomous data infrastructure while keeping a massive, revenue-critical foundation healthy.

When interviewers ask "why Uber," don't talk about robotaxis in the abstract. Talk about the specific data engineering problem they create. Autonomous trip events need different dimensional models than human-driver trips (sensor fusion dimensions, safety-incident fact tables, sub-second latency budgets for vehicle routing). Framing your answer around that gap, and why your background prepares you to close it, shows you've studied Uber's actual roadmap rather than skimming a press release.

Try a Real Interview Question

from typing import Iterable, List, Tuple


def sessionize_events(
    events: Iterable[Tuple[str, int]],
    gap_seconds: int,
    watermark: int,
) -> List[Tuple[str, int, int, int]]:
    """Sessionize per-user events with a gap threshold and a watermark.

    Args:
        events: Iterable of (user_id, ts) events. Not guaranteed to be sorted.
        gap_seconds: Gap threshold in seconds. Same session if next_ts - prev_ts <= gap_seconds.
        watermark: Ignore late events where ts < watermark.

    Returns:
        List of (user_id, start_ts, end_ts, event_count) sorted by user_id then start_ts.
    """
    pass

from typing import Iterable, List, Tuple, Dict


def sessionize_events(
    events: Iterable[Tuple[str, int]],
    gap_seconds: int,
    watermark: int,
) -> List[Tuple[str, int, int, int]]:
    """Sessionize per-user events with a gap threshold and a watermark.

    Args:
        events: Iterable of (user_id, ts) events. Not guaranteed to be sorted.
        gap_seconds: Gap threshold in seconds. Same session if next_ts - prev_ts <= gap_seconds.
        watermark: Ignore late events where ts < watermark.

    Returns:
        List of (user_id, start_ts, end_ts, event_count) sorted by user_id then start_ts.
    """
    if gap_seconds < 0:
        raise ValueError("gap_seconds must be non-negative")

    per_user: Dict[str, List[int]] = {}
    for user_id, ts in events:
        if ts < watermark:
            continue
        per_user.setdefault(user_id, []).append(ts)

    sessions: List[Tuple[str, int, int, int]] = []

    for user_id, ts_list in per_user.items():
        ts_list.sort()
        start = ts_list[0]
        end = ts_list[0]
        count = 1

        for ts in ts_list[1:]:
            if ts - end <= gap_seconds:
                end = ts
                count += 1
            else:
                sessions.append((user_id, start, end, count))
                start = ts
                end = ts
                count = 1

        sessions.append((user_id, start, end, count))

    sessions.sort(key=lambda x: (x[0], x[1]))
    return sessions

Uber's job postings for data engineers call out strong Java/Python and distributed systems experience, so expect coding rounds that reward clean, well-structured code over brute-force solutions that merely pass. Practice with problems at datainterview.com/coding that let you build that muscle in a timed setting.

Test Your Readiness

Gaps in SQL optimization or pipeline design are the fastest to close with targeted reps. Work through Uber-relevant scenarios at datainterview.com/questions.