What topics are tested in Uber Senior SDE interviews?

Uber Senior SDE interviews test: Graphs, Spatial Algorithms, Advanced DP, Heaps, Distributed Systems, Real-time, Geo-indexing, Kafka.

Does Uber Senior SDE have a system design round?

Yes, Uber Senior SDE includes a system design round.

Uber

Q: How many rounds are there in Uber Senior SDE interviews?

Uber Senior SDE typically has 5 rounds. Uber Senior SDE (L5A/L5B) interviews include two Architecture Design rounds and hold a higher coding bar than most Senior-level loops in big tech. The first architecture round covers Uber's real-time, geo-distributed systems (dispatch, matching, surge pricing); the second covers data platforms and infrastructure. The single coding round is Hard — optimal solution expected with no warm-up. Uber Senior engineers are expected to have strong, reasoned opinions on geo-distributed tradeoffs, not just pattern-matching to 'use Kafka and Redis.' Interviewers will push back if your design doesn't account for Uber's actual global-scale density problems.

Mobility / Tech · San Francisco, CA

Uber's real-time dispatch platform connects riders, drivers, and couriers across 70+ countries at massive scale.

Related Companies

Rounds: 5 rounds
Focus: Architecture Design + Coding
System Design: Yes
Timeline: 3–4 weeks to offer

Role:

Rounds 1–2 are fully visible · Round 3+ unlocked with a free account

Technical Phone Screen

Round 1 of 5DSA / Coding

60 min

GraphsSpatial AlgorithmsAdvanced DPHeaps

Hard problem. Senior-bar — optimal solution must be produced, not just described. Uber expects multiple approaches to be discussed before coding begins, with complexity guarantees stated upfront. The problem often has a graph or spatial flavor relevant to routing or proximity at scale.

Hard

What to expect

1 hard problem; stating only the brute force and not converging on optimal is an automatic screen-out at Senior level
e.g., 'Given a real-time stream of driver locations and ride requests, implement a function that returns the nearest idle driver to a given (lat, lon) point in O(log N)' — expected to propose a spatial index structure (quad tree, k-d tree, or explain why Redis GEORADIUS is more practical at scale)
Multiple approaches discussed: interviewer is evaluating whether you reason about tradeoffs or just recall patterns
Production-code standards: variable naming, separation of concerns, explicit error handling for null/empty — not 'assume valid input'

Practice on KnowEase.AI

DSA Practice — Graphs →DSA Practice — 2D DP →

Architecture Design 1 — Real-time Systems

Round 2 of 5System Design

60 min

Distributed SystemsReal-timeGeo-indexingKafkaRedis

Design a core Uber geo-distributed system from scratch. At L5, interviewers expect full component breakdown, sharding strategy, failure recovery, and SLA reasoning. The canonical question pool includes: ride-matching service, surge pricing engine, driver location update pipeline, and ETA prediction service. Generic 'load balancer → app server → DB' architecture is a straight rejection — you need to show depth in real-time stream processing and geospatial indexing.

Hard

What to expect

e.g., 'Design Uber's ride-matching system to match riders to drivers in under 200ms globally' — expected to cover H3 geo-sharding, Redis GEORADIUS proximity queries, Kafka for location event ingestion, and the cascading fallback when the nearest driver declines
e.g., 'Design the surge pricing engine: GPS pings → per-H3-hexagon surge multiplier in under 60 seconds, serving 5M+ concurrent users' — expected to discuss rolling supply/demand windows, hexagon resolution tradeoffs (H3 resolution 7 vs 9), and cache invalidation strategy
Exactly-once delivery semantics under driver app network flakiness — how do you avoid double-counting a driver's location in demand computation?
Designing only for a single city without addressing cross-region consistency and density variance (Manhattan vs rural Iowa) is explicitly called out as a Senior-level failure mode
SLA targets must be quantified: sub-200ms matching, sub-60s surge refresh, 99.99% uptime for payment authorization

Practice on KnowEase.AI

HLD Practice →

Architecture Design 2 — Data Platform

Round 3 of 5System Design

60 min

Data PipelinesKafkaML Feature StoreData LakeScalability

Design Uber's data infrastructure: event pipelines, ML feature stores, analytics, or observability. At Senior level, this round tests whether you can reason about streaming vs batch trade-offs, cross-region replication, and cost/latency optimization — not just draw boxes on a whiteboard.

What to expect

e.g., 'Design Uber's ML feature store for real-time surge pricing — features must be available in under 50ms at inference time' — expected to discuss online vs offline feature serving, Redis for low-latency feature retrieval, and Kafka + Flink for real-time feature computation
e.g., 'Design the trip events pipeline that feeds both real-time dashboards (sub-1-minute lag) and historical analytics (petabyte scale)' — Lambda vs Kappa architecture debate expected
Cross-region data replication: how do you replicate trip data across US/EU/APAC while respecting data residency regulations?
Candidates who can only describe the data lake and not the serving layer for real-time use cases fail to clear the Senior bar here
Cost reasoning is explicitly tested: 'your design would cost $40M/year at Uber's scale — what's the single highest-ROI optimization?'

Full details unlocked with a free account

API & Component Design

Round 4 of 5LLD / OOD

60 min

API DesignOOPDesign PatternsIdempotencyVersioning

Low-level design of a service interface or platform SDK. Uber's microservice architecture means Senior engineers routinely design APIs consumed by 10+ internal teams — interviewers test whether your contracts are clean, versioned, and extensible without breaking changes.

What to expect

e.g., 'Design the API for Uber's driver earnings service — it must support real-time balance queries, weekly statement generation, and third-party integrations for driver financing partners'
Versioning strategy: how do you evolve a payment API without breaking 20 downstream consumers that you don't control?
Class hierarchy and composition: when would you use an interface vs an abstract class for a dispatch event handler?
Idempotency design for ride-booking mutation endpoints — Uber's unreliable mobile network means duplicate requests are the rule, not the exception

Full details unlocked with a free account

Director Round

Round 5 of 5Behavioral / HM

60 min

Technical LeadershipCross-team InfluenceVisionOwnership

Strategic alignment and cross-team leadership depth. At L5, Uber is hiring engineers who drive technical direction across teams — this round probes whether you can operate at that scope. The Director will push on the limits of your impact: where did your influence stop and why?

What to expect

Describe the largest cross-team technical initiative you drove — 'the team built X' is not an answer; they want your specific decisions and where you pushed against resistance
How do you balance technical debt against shipping velocity when you own the decision? — Uber's culture values speed; a purely risk-averse answer is a yellow flag
Tell me about a time your technical vision was wrong — and what changed your mind — Senior engineers who can't recall being wrong are viewed with skepticism
Long-term alignment: Uber operates rides, Eats, Freight, and Ads on shared infrastructure — where do you think the biggest unsolved technical problems are?

Full details unlocked with a free account

Questions — coming soon.

Company Guide — coming soon.

About Uber Senior SDE Interviews

Uber Senior SDE (L5A/L5B) interviews include two Architecture Design rounds and hold a higher coding bar than most Senior-level loops in big tech. The first architecture round covers Uber's real-time, geo-distributed systems (dispatch, matching, surge pricing); the second covers data platforms and infrastructure. The single coding round is Hard — optimal solution expected with no warm-up. Uber Senior engineers are expected to have strong, reasoned opinions on geo-distributed tradeoffs, not just pattern-matching to 'use Kafka and Redis.' Interviewers will push back if your design doesn't account for Uber's actual global-scale density problems.

See interview loops for other companies:

Microsoft Amazon Flipkart Razorpay Walmart Coupang Rippling Rubrik Target

Start your Uber Senior SDE prep plan

Practice the exact topics tested in each round — DSA, system design, SQL, and LLD.

Start free →