I Failed Uber’s System Design Interview Last Month Here’s Every Question They Asked

Uber’s onsite loop consists of 4–5 rounds, each lasting about an hour and typically spread over two days. The system design round is the make-or-break moment for senior candidates. You can ace every coding round, but if you stumble here, rejection is likely. Emily used Excalidraw for diagramming during her virtual interview, a tool she recommends having ready before you start. The interviewer’s main question was to design Uber’s real-time surge pricing engine—a system that ingests millions of GPS pings per second, calculates supply versus demand, and updates pricing multipliers every 30 seconds. 01:05 The interviewer framed the challenge clearly: Uber needs a system that calculates dynamic pricing for every hexagonal zone in a city, in near real-time. The system must consider current ride requests, available drivers, historical demand patterns, and external factors like weather or events. The pricing multiplier must update at least every 60 seconds. This isn’t just a simple box-and-arrow diagram; it’s a complex, high-scale, real-time solution. Emily’s first instinct was to start drawing boxes, but she paused to clarify requirements—a move that distinguishes senior candidates. 01:37 Before jumping into the design, Emily asked clarification questions—a key step for senior-level thinking. She confirmed functional requirements: the system must compute surge multipliers per geographic zone, ingest real-time supply and demand, and reflect current conditions. Non-functional requirements included latency (multiplier recalculated within 60 seconds), scale (supporting millions of users across hundreds of cities), availability (99.99% uptime), and accuracy versus speed. Asking about fallback behavior on failure signaled her senior mindset, earning a positive response from the interviewer. 02:14 Emily’s secret weapon was her knowledge of Uber’s H3 open-source library. She explained how geographic space is partitioned using H3 hexagonal indexing at resolution 7, resulting in hexagons roughly 5km² in area. Each hex has a unique 64-bit ID, and hexagons have uniform neighbor distances, making demand spread calculations more accurate than square grids. This impressed the interviewer and set Emily apart. She described the high-level data flow: driver GPS pings and ride requests are mapped to hex IDs, counters are updated, and the surge calculator computes multipliers. 02:50 The surge pricing system consists of several key components. First, the H3 Hex Mapper converts raw latitude and longitude into H3 hex IDs in sub-millisecond time. Supply and demand counters use sliding windows, storing data in Redis keyed by hex ID. The Surge Calculator, implemented as a streaming job (like Apache Flink), runs every 30–60 seconds to compute multipliers. Finally, the Pricing Cache writes results to a low-latency Redis cluster, which the Pricing Service reads from to display surge pricing to riders. Each component plays a vital role in real-time operation. 03:25 The interviewer pushed Emily to explain how the Surge Calculator actually computes the multiplier. She started with a simple formula: surge_multiplier = max(1.0, demand_count / (supply_count * target_ratio)). However, she quickly noted this was the naive version. The real calculation layers in neighbor hex blending, historical baselines, and external signals like weather and events. Neighbor hex blending prevents extreme surges in isolated hexes by considering supply in adjacent zones. Historical baselines distinguish normal demand from event-driven spikes, and external signals add context.