System design guide
The Uber system design interview: real-time, geospatial and prep
Uber's design questions tend to come straight from its own products: moving drivers on a map, matching in seconds, ETAs, surge, and payments at the end of every trip. If you can reason about real-time geospatial systems, you're most of the way there.
This page summarises public candidate reports and prep guides (sources at the end). Uber's process varies by team and level; confirm with your recruiter.
Where design sits in the loop
Prep guides describe a loop with a recruiter call, coding assessments, and an onsite (usually virtual) with coding, system design, and behavioural or collaboration rounds. The design round is typically 45–60 minutes. Senior candidates are expected to drive the discussion and go deep on real-time behaviour and failure handling.
Themes that come up
- Real-time location: ingesting frequent GPS updates from many drivers, indexing them geospatially, and pushing live positions to riders.
- Matching and dispatch: finding candidates quickly, ranking by ETA, never assigning one driver twice.
- ETAs and routing: road graphs, live traffic, and caching to keep estimates fast.
- Marketplace dynamics: surge pricing from supply and demand per area, computed on streaming data.
- Payments: authorise up front, capture at the end, handle retries and disputes.
- Delivery products: carts, restaurant orders, courier assignment.
Prompts candidates report
| Prompt | What to go deep on | Our guide |
|---|---|---|
| Ride-sharing core / dispatch | Geo index, matching, trip state machine | Design a ride-sharing app |
| ETA service | Routing graph, traffic data, caching per cell pair | Ride sharing, ETA section |
| Driver heatmap / surge | Streaming aggregation per cell, windows | Top-K and streaming aggregation |
| Payments for trips | Idempotency, state machine, ledger | Design a payment system |
| Messaging / live updates | Persistent connections, fan-out | Design a chat app |
| Distributed logging | Log shipping, partitioned storage, retention | Sharding (partitioning patterns) |
What strong answers include
- Latency budgets: break "match within a few seconds" into time for location lookup, ETA ranking, and offer round trips.
- Cell-based partitioning and how queries cross cell or region boundaries.
- Clear consistency boundaries: positions can be eventually consistent; driver claims and trip states can't. See consistency models.
- Mobile realities: flaky networks, offline buffering, idempotent updates from apps that retry.
- Regional isolation so one city's problem stays in that city.
Example: the first 15 minutes of "design an ETA service"
- Scope (3–5 min). Pickup ETA (driver to rider) and trip ETA (pickup to drop-off); called during matching, on the request screen, and during the trip. Latency target: tens of milliseconds per call, because matching ranks many candidates.
- Estimates (3 min). Ride requests × candidate drivers per request, plus periodic in-trip refreshes, gives a call rate well above the request rate; that argues for caching.
- Diagram (5–7 min). A routing service over a road graph with precomputed shortcuts, a live traffic feed updating edge weights, and a cache of cell-to-cell travel times for quick ranking.
- Deep dive. Two-stage ETA: cheap cached estimates to shortlist drivers, exact routing for the top few. Then cover traffic freshness and how you'd evaluate ETA accuracy against actual trip times.
Prep plan
- Learn one geospatial indexing approach well enough to explain cell sizes and neighbour searches.
- Work through the ride-sharing design twice: once focused on matching, once on location ingestion and live tracking.
- Practise one payments problem and one streaming-aggregation problem.
- Use the 45-minute framework and practise stating latency targets up front.
Sources
- Dataford, Uber software engineer interview guide: dataford.io/interview-guides/uber/software-engineer
- Codemia, Uber software engineer guide: codemia.io/guides/uber-software-engineer
- PracHub, candidate-reported Uber questions: prachub.com/companies/uber
- Jobright, Uber technical interview guide (2026): jobright.ai
FAQ
Will I be asked to design Uber at Uber?
Possibly, but candidates more often report narrower pieces of the business: an ETA service, a driver heatmap, dispatch, an airport driver queue, a cart service for food delivery, or infrastructure like logging and messaging. Knowing the full ride-sharing design helps with all of them.
How important is geospatial knowledge?
Quite. Expect to explain how you'd find nearby drivers efficiently (geohash, quadtrees, or a hexagonal grid such as H3, which Uber open-sourced), how you'd partition by region, and how often locations update.
How long is the round?
Prep guides commonly describe a 45 to 60 minute system design interview as part of the onsite loop for mid-level and senior candidates.