How Uber interviews — Question to Offer

1. The shape of an Uber loop

Uber runs the most real-time-flavored loop of the big tech companies. Engineers here spend their careers thinking about maps, dispatch, and marketplaces that have to balance every few seconds. The loop reflects that. If you can't talk about geo and real-time fluently, you'll feel it by minute fifteen.

A standard onsite is five rounds. Two are coding, two are system design, one is behavioral with a senior IC or manager. The system design rounds are 45 minutes each. The first one is usually a product-shaped problem (design rider-driver matching, design surge pricing). The second is closer to infrastructure (the geo-index, the dispatch ring, the trip-state store).

Levels run L4 through L6 for IC. L4 is entry senior. L5 is the bar for a normal senior. L6 is staff and the system design rounds carry more weight than coding. At L6, the second design round will push hard on the geo primitives and on what happens at city scale during a Friday night spike.

2. What Uber grades you on

Three things, in order of how much they matter for design rounds:

Real-time mindset. Most of Uber's systems read and write every few seconds per active user. Driver location updates every 4 seconds. Surge recomputes every minute. Match decisions happen in under 2 seconds. If you scope a problem as if it's a daily batch job, you're in the wrong building.
Geo literacy. You should know what a geohash is. You should know what S2 cells are. You should ideally know what H3 is, since Uber published the library. You don't need to derive the math. You need to use the vocabulary right and pick the right resolution for the question.
Marketplace thinking. Uber is a two-sided market. Riders need cars. Drivers need fares. Every product decision changes the incentives on both sides. If you design only the rider side, you're missing half the answer.

In a typical 45-minute round, the interviewer will set up a city-scale constraint inside the first five minutes. Something like "assume we're talking about San Francisco, 50K active drivers, peak Friday night." That constraint is the implicit ceiling on everything you say after it. Scope above the constraint and you sound naive. Scope below it and you sound like you've never seen production.

3. What's different here

The implicit constraint is always a city. Not the planet. Not one user. Uber thinks in metros. Most of your back-of-envelope numbers should start from "one large metro" and scale outward only if the interviewer asks.
Latency budgets are tight. Match decisions in under 2 seconds end to end. Geo queries in under 50ms. Surge map updates within a minute. State these budgets early and the interviewer relaxes.
The driver side is graded. Many candidates design the rider experience and forget the driver app exists. The driver app has its own real-time read path (the heatmap, the dispatch ping, the surge map). Bring up the driver side unprompted.
H3 is well-known here. Uber published the H3 hexagonal indexing library. You don't need to recite the paper, but if you can say "I'd use H3 at resolution 9 for dispatch and resolution 7 for surge" and defend the choice, the interviewer warms up.
Failure modes lean toward GPS and connectivity. Phones lose signal. Drivers go through tunnels. The system has to handle the location going stale without dropping the trip. This is a common deep-dive push.

4. The level bar

How the bar shifts:

L4 — design at the competent IC level. You should be able to draw a clean two-tier architecture, name a database, size the traffic correctly. Depth is shallow. One seam discussed properly is enough.
L5 — design at the senior IC level. One deep dive that survives three pushes. Geo primitive named and defended. Marketplace mentioned even if shallow.
L6 — design at the staff level. Two seams defended at depth. The marketplace tradeoff is part of every choice (what does this do to driver supply, what does this do to rider conversion). Failure modes structured by tier.

Ch 14 units target L5 by default, with notes on what L6 needs.

5. The Uber-flavored mistakes

Watch for:

Scoping for the planet instead of for a city. Designing a global geo-index when the question is about Manhattan at peak. The interviewer wants the city-scale answer first; the global answer is a stretch question.
Forgetting the driver app. Drivers see a heatmap. Drivers see the surge map. Drivers get a 10-second dispatch ping. If your design doesn't have a driver-facing read path, you missed half the system.
Treating GPS as accurate. Real driver locations are noisy. Tunnels. Urban canyons. Map snap. If you design ETA assuming the GPS coordinate is the truth, you'll get pushed on what happens when it isn't.
Hand-waving the matching algorithm. "We pick the nearest driver" is not enough. The interviewer wants to hear about ETA versus distance, driver acceptance rates, fairness across the driver fleet, and what happens when two riders compete for the same driver.
Skipping the back-of-envelope on location update throughput. 100K active drivers updating every 4 seconds is 25K writes per second from just the location pipeline. That number drives most of the storage choices. If you don't compute it, you can't defend the choices.

6. The seven scenarios in this chapter

Each unit walks one question end to end:

14.1 Rider-driver matching — the dispatch decision. Bipartite vs greedy. Pre-positioning drivers.
14.2 ETA at city scale — batch route evaluation for matching, not single-route serving.
14.3 Surge pricing — per-cell multipliers, smoothing, locked-in quotes for riders.
14.4 Dispatch with H3 and geohashing — Uber's hexagonal geo-index and why hexagons.
14.5 Trip state machine and payments — lifecycle states, pre-auth, payout, the Stripe-flavored idempotency layer.
14.6 Driver demand heatmap — the driver-facing real-time aggregate, with personalization.
14.7 Take-home: real-time driver location tracking — the full design doc for the location subsystem at city scale.

7. The next page

The first scenario: rider-driver matching. The single most-asked Uber design question.