Uber Data Engineering Interview Q&A

Practice a proposed design, its critical trade-off, and a concrete way to validate it.

Question bank

39 likely follow-ups grouped by the part of the design an interviewer will challenge.

Interview answer

Design an end-to-end pipeline that processes Uber trip events in real time.

Proposed design

I would define immutable trip lifecycle events first, key them by trip_id in regional Kafka, and use an event-time stream processor to build the current trip state. The same events land unchanged in Bronze; Silver validates and deduplicates them, and Gold publishes reconciled trip facts.

Critical trade-off

The real-time projection is intentionally provisional. It must not become the financial source of truth because mobile events can be late, duplicated, or contradicted by payment and settlement systems.

How I would validate

I would replay one request through match, arrival, pickup, completion, payment, and cancellation paths. I would verify legal state transitions, duplicate handling, p95 event-time latency, source-offset lineage, and agreement between the online projection and the reconciled trip fact.

Whiteboard order

Move left to right from requirements to architecture, then close with operational proof and explicit trade-offs.

Frame

Define outputs

Live marketplace signals and trusted history

Set guarantees

Freshness, correctness, privacy, and regional scope

Size

Estimate traffic

GPS, trip lifecycle, rider, and payment events

Calculate capacity

Peak events/sec, throughput, and retention

Draw

Build the backbone

Producers to regional Kafka

Split the paths

Flink for seconds; lakehouse for trusted history

Deep dive

Defend the keys

Salted H3 partitioning and event-time state

Define the truth

Layer contracts, fact grains, and reconciliation

Close

Prove resilience

Quality SLOs, replay, privacy, and regional DR

State trade-offs

Cost, complexity, and one failure end to end