Uber's engineering interview is shaped by what the company actually does — move riders and drivers around the physical world at very high scale, in real time, in hundreds of cities with hundreds of regulatory regimes. That shows up in the loop in three specific ways. First, the coding rounds skew geospatial and real-time — K-nearest-neighbours, sliding-window leaderboards, density-based clustering — more than they skew toward dynamic programming or graph theory in the abstract. Second, the system design rounds almost always have a geospatial twist; even questions that look like generic distributed systems usually pivot to "now design it for rider-driver matching" or "now design it across 500 cities with regional sharding." Third, the behavioural rounds quietly screen for the post-Travis-era cultural values — judgment over heroism, ownership over blame, coordination across teams rather than lone heroics. The loop is typically a recruiter screen, a phone-screen coding round, then an onsite of two coding rounds, one or two system design rounds (two for Sr SDE), and a behavioural round with the hiring manager. Sr SDE candidates should expect at least one round explicitly probing leadership across teams. Senior-level signal lives in the trade-off discussions much more than in the algorithmic correctness; interviewers write detailed notes that another team of debriefers reads, and a correct answer with no reasoning often loses to a near-miss with strong reasoning visible.
Two coding rounds is standard. Expect Uber-flavoured framings — geospatial, streaming, marketplace dynamics. Talk through the trade-offs explicitly; the interviewer is grading reasoning, not just correctness.
Heap-based: maintain a max-heap of size K, push each point keyed by negative distance to Q (or use a max-heap keyed by distance directly), and pop when size exceeds K. End state — the heap holds the K nearest. Time is O(N log K), space O(K). KD-tree: build a balanced KD-tree by recursively splitting on alternating axes at the median, then query with a best-first traversal that prunes subtrees whose bounding box is farther than the current K-th best. After O(N log N) preprocessing you get O(log N) average per query — but the catch is the curse of dimensionality. KD-trees degrade sharply around 10+ dimensions because the pruning stops working; for 2D geospatial coordinates they are fine. For Uber’s actual rider-driver matching, neither of these is what production uses. The real approach is a geohash-based or H3 hexagonal grid index — bucket every driver into a cell, and for a rider lookup retrieve the candidate set from the rider’s cell and a one-ring of neighbours, then run exact distance filtering only on that small set. Trade-offs to surface: building the index (geohash inserts are O(1), KD-tree rebuilds are O(N log N)) versus query time versus index update cost as drivers move every few seconds — the grid wins because per-update cost is O(1).
Two structures cooperating. A hashmap from driver_id to current count, and a min-heap of size K holding (count, driver_id) tuples for the current leaders. On each trip-completion event: increment the count in the hashmap; if the driver is already in the heap, you need to update its key (lazy approach — push a new entry and skip stale ones at read time, or use an indexed heap); if the driver is not in the heap and the new count exceeds the heap’s minimum, replace the minimum and sift down. Query for top-K is O(K log K) to extract a sorted snapshot, or O(K) for an unsorted snapshot. The hard part is the sliding window — at the rollover from minute N to minute N+1, you must decrement events that fell out of the window. Two production-friendly options: per-minute buckets (60 buckets, each a hashmap of driver -> count; rotate the oldest bucket and subtract its contents from the global map every minute), or approximate counters with exponential decay (every event contributes weight that decays as e^(-t/tau), no rollover needed but the count is now approximate). For Uber’s actual scale, per-minute buckets sharded by region win because the math is exact and a city’s active driver count is small enough to fit in memory.
Start with the gridding approach — bucket coordinates into roughly 500-metre cells (a geohash precision of 7 or an H3 resolution around 8 gets you there). For each cell, compute the supply-demand ratio: a rolling 5-minute window of pickup requests divided by the current driver count in that cell. Threshold it — for example, a ratio greater than 2.0 means the cell enters surge state. Implementation: a hashmap from cell_id to a circular buffer of timestamps for the rolling window, plus a separate hashmap from cell_id to driver count maintained by the driver-location pipeline. On each new request, evict expired entries from the buffer, append the new timestamp, and recompute the ratio. The senior follow-up the interviewer is waiting for is the boundary problem — a hot zone in real life rarely lines up with the grid, so a request right at a cell edge contributes to one cell but not the adjacent one, and you get jagged surge boundaries. The two answers: (1) hierarchical grids — use S2 cells or H3 at multiple resolutions and roll up neighbours at the coarser level; (2) kernel density estimation — give each request a Gaussian footprint that bleeds into neighbouring cells. Production systems combine both.
Offline side: model the road network as a directed graph where nodes are intersections and edges are road segments, with edge weights equal to expected travel time at the current time of day. A naive Dijkstra over a continent-scale graph would take seconds — far too slow. Production systems preprocess with Contraction Hierarchies (CH) or Customizable Route Planning (CRP) so that point-to-point shortest-path queries become sub-millisecond. CH does this by repeatedly contracting low-importance nodes and adding shortcut edges that preserve shortest-path distances; CRP partitions the graph into a multilevel overlay so weights can be changed quickly without rebuilding the full structure. Online side: at query time, look up the source and target nodes (snapping GPS coordinates to the nearest road segment), then run a bidirectional CH or CRP query against the preprocessed structure with current traffic-weighted edge costs. Discuss freshness — traffic edge weights come from probe data (active rides reporting their speed every few seconds), aggregated into per-segment current speed and updated roughly every minute. Cover the cold-start problem — a newly-mapped road segment has no historical or live traffic data, so the system falls back to road-class defaults (e.g., residential = 30 km/h, highway = 100 km/h). The ML correction layer on top of the structural ETA is usually the L5 follow-up question.
Sr SDE candidates get two system design rounds; at least one will be explicitly geospatial or marketplace-flavoured. Drive — name the requirements, capacity numbers, and the API surface before drawing anything.
Two-phase architecture. Phase one: a geospatial index of active drivers — Uber’s production system uses H3, their hexagonal hierarchical grid (S2 cells from Google are the equivalent at other companies). Drivers report location every 4 seconds; their cell membership is updated in an in-memory store sharded by region. Phase two: a matching engine that for each incoming rider request looks up the K nearest available drivers (using the cell plus a one-ring of neighbours, then exact distance filtering) and runs the matching algorithm — which is not just nearest-driver but a scoring function over ETA, driver acceptance probability, surge state, and trip profitability. Regional sharding is critical: a city is mostly independent of every other city (no rider in Mumbai is ever matched to a driver in Bangalore), so each city runs on its own cluster and the global system is really hundreds of independent city services with a thin global routing layer. Consistency: a driver can be in only one active offer at a time, which requires either distributed locks (Redis-based, with a short TTL) or optimistic concurrency (the matcher writes a tentative offer with a version number and the driver-acceptance event compare-and-sets it). Fallbacks: when no driver is within range, expand the search radius progressively, then surface a no-cars-available message; do not silently hold the request forever. Latency budget: 200ms for the geospatial query, 500ms for the scoring pass, 1s for the driver-offer round-trip, leaving headroom for retries.
Two layers stacked. Layer one is the structural model — the road network as a directed graph with current traffic-weighted edge costs, preprocessed with Contraction Hierarchies so point-to-point queries are sub-millisecond. This gives you a physics-grounded baseline ETA. Layer two is an ML correction model that learns the residuals — the systematic gap between the structural ETA and observed reality. Features include time of day, day of week, weather, recent local events (a concert venue letting out), driver-specific historical speed, vehicle type, and recent same-route trip durations. The model output is a multiplier or additive correction on top of the structural ETA. Training pipeline: replay millions of historical trips against the road graph as it existed at the time, compute the structural ETA for each, take the residual versus the actual observed duration, train a gradient-boosted model or a small neural net on the residuals. Freshness: traffic edge weights refresh every minute from probe data emitted by active rides; the ML model is retrained nightly or weekly. Calibration is the make-or-break property — a 5-minute ETA must actually average 5 minutes in reality, not 5 plus or minus 3. Apply isotonic regression as a post-hoc calibration layer on the ML output, and track calibration drift per region as a primary metric. The hardest part of the system in practice is the live traffic ingestion plumbing, not the model itself.
Per-zone supply-demand ratio computation: bucket the city into cells (H3 resolution 8 or 9), compute a rolling 5-minute window of pickup requests divided by the current available-driver count in each cell. Apply a smoothing function — exponential moving average or a low-pass filter — so the multiplier does not jump from 1.0 to 2.5 within seconds, which infuriates riders mid-booking. The price multiplier function is continuous, not stepped (e.g., a sigmoid mapping the ratio to a multiplier between 1.0 and the cap). Rider-facing cap: never let the multiplier exceed N times (Uber publicly committed to caps after the 2017 storm-surge controversy and the cap is now enforced even in extreme events, with rationing implemented as a queue instead of unbounded price). Driver-facing incentive: drivers see a heatmap of where surge is high so they can position themselves there — this is the actual mechanism that resolves the imbalance, not the price increase to riders. The L5+ discussion the interviewer wants: the cold-start gaming problem — sophisticated riders sometimes wait for surge to drop, which itself smooths demand but creates a perverse incentive to communicate surge as ephemeral rather than persistent. The fairness debate: variable pricing during emergencies (medical, weather) is reputationally costly even when economically efficient — Uber’s answer has been hard caps during declared emergencies, even at the cost of long wait times. Engineering-wise, this is implemented as a feature-flag override that forces the multiplier to 1.0 in declared-emergency regions.
One round with the hiring manager, sometimes a second with a cross-functional partner for Sr SDE. The interviewer wants specific stories, not values-page recitations.
Uber’s scale means incidents are not a hypothetical — they are part of the job, and the interviewer wants to see you have lived through one with ownership. Structure the story around five beats: (1) detection time — the alert that fired versus the symptoms users were actually seeing, and whether there was a gap (named that gap honestly if there was one); (2) the diagnostic journey — the specific dashboards you opened, the metrics that confirmed or ruled out hypotheses, the moment you found the smoking gun; (3) immediate mitigation — rollback, traffic shift to a healthy region, feature-flag disable, manual database intervention, whatever the action was, and the time-to-mitigation; (4) the root cause — what actually caused it, written out in the kind of language you would put in a public post-mortem; (5) the post-mortem follow-through — the action items you personally owned and shipped, not just the ones assigned to other teams. The senior signal the interviewer is looking for is the systemic-fix step, not the mitigation. Anyone can roll back. Senior engineers ask what would have caught this in CI, what monitoring would have shortened detection, what design pattern would have made the failure mode impossible — and then they do those things.
Uber’s microservices culture means almost no real project lives in a single service — most cross-cutting features touch 5 to 10 services across as many teams. The shape of a strong answer: a feature or migration required coordinated changes across multiple services; you ended up serving as the de facto tech lead even without the title; you wrote a design doc that aligned every team on the shared contracts and the rollout sequence; you tracked the rollout with explicit milestones and weekly check-ins; you handled the inevitable scope cuts gracefully. Strong candidates name the trade-offs they made — what they cut from scope and why, which usually means dropping a nice-to-have to keep the critical path on schedule. Stronger candidates name the human dynamics — the team whose priorities conflicted with the project, how you found the alignment by understanding what that team needed in return, the conversation with their tech lead that unblocked things. Avoid the heroic-individual framing. Uber’s engineering culture has actively moved away from rewarding lone wolves and toward rewarding people who multiply the team. Close with a concrete metric — the launched feature’s impact, the migration’s reduced incident rate, the number of services successfully cut over.
Uber’s culture has historically valued speed — the Travis-era wartime CEO playbook lionised shipping fast over polish — but the culture matured considerably after the leadership change, and modern Uber engineering interviewers want to see judgment, not bias. Pick a real example with stakes: you had to ship something with known imperfections to meet a regulatory deadline (a market’s new TNC regulation), capture a market opportunity (a launch tied to an event date), or unblock a major launch (an upstream dependency for another team’s critical path). Show that you made the call with eyes open: name the specific risks you accepted (the test coverage you skipped, the edge case you knew would break for a small user segment, the manual operational toil you committed to absorb until the proper fix landed), name the specific remediation plan (the follow-up ticket already filed, the on-call runbook updated, the date by which the proper fix would land), and name the outcome (the call paid off, or it did not — and if it did not, what you did about it). The bad version of this answer sounds like “we just shipped it and figured it out later”; the senior version sounds like “here is the exact scope of the corner we cut, here is the cost we agreed to pay for it, and here is how we paid it down.”
Reading sample answers is preparation. The loop itself is performance under pressure — and Uber’s debrief process means every hesitation, every half-finished thought, every "wait, let me restart" ends up in the notes the team reads together. Use PhantomCodeAI as your real-time coding copilot during the actual Uber loop, and browse the full interview-questions hub for other companies you’re onsite at this cycle. The transcript afterward shows exactly what the debrief will discuss — where you paused, what trade-offs you named, what the interviewer typed back — and you can prep the next round the same evening.