Four rounds, questions weren't hard but the pace was really fast
Let me lead with the conclusion: Uber's problems really aren't hard, but they move fast. 45 minutes a round, and the interviewer practically wants you to knock out the main problem in 15 minutes so there's a full half hour left for piling on requirements. It felt less like solving problems and more like sitting in a requirements review meeting.
I'm going to describe the problems by what they actually are rather than naming them directly, so bear with the paraphrasing.
Round 1 — Coding
The interviewer opened with "let's just get started" — less than thirty seconds of small talk.
The problem: given a bunch of time intervals, find the minimum number of meeting rooms needed.
Sort by start time, maintain end times with a min-heap — a template problem, done in ten minutes.
Then the requirements started piling on:
"What if instead of the count, you need to return which room each meeting is assigned to?" — store (end_time, room_number) in the heap, and reuse the room number that gets popped.
"What if a meeting can be interrupted and moved to a different room?" — I had to think about this one for a bit. Said it turns into a sweep line: +1 at each start, -1 at each end, and you only care about the concurrent count.
"What if the intervals arrive as a stream and you can't sort them upfront?" — I answered this one so-so, just said you could maintain it with a balanced tree or segment tree, didn't go into detail.
The last follow-up was clearly steering toward a real business use case. It wasn't until after I finished that I realized — this is literally staff scheduling.
Round 2 — Coding
The interviewer was a woman, talked very fast the whole time.
The problem: given a bunch of points on a plane, return the K closest to the origin.
I asked first "how big is K relative to N?" She said K is much smaller than N. So: maintain a max-heap of size K, O(N log K). After I finished she asked if there was another way, and I said quickselect could get average O(N) — she had me write out the partition step too.
All the follow-ups pushed toward "this is a real system":
"What if the origin is replaced with an arbitrary rider's location?" — same thing, just change the distance function.
"What if there are tens of millions of points, and they're constantly moving?" — this is where we got into spatial indexing. I said grid partitioning or a QuadTree, coarsely filter candidates first, then compute exact distance. She pushed on how you'd decide the grid cell size, and I said it's a trade-off: too large and you get too many candidates, too small and you have to check too many neighboring cells.
"What if distance needs to be real road-network distance instead of straight-line?" — I said straight-line distance can only serve as a first-layer filter; the actual ranking has to go through a routing service, but straight-line distance can cut out 99% of the candidates up front.
This was the round that felt best, because her follow-ups were concrete — it felt like discussing a real problem rather than an interview question.
Round 3 — System Design
Design a nearby-driver / proximity service.
There were writeups about this exact question on the forum, and I'd read them beforehand, so it went pretty smoothly.
Clarifying questions: how many drivers are online, how often is location reported, how large is the query radius, do you need to account for differences between cities (downtown vs. suburbs have very different densities), how many results to return.
The core problem boils down to one thing: how do you quickly find all the points within a given radius among a huge number of moving points.
I laid out three options and compared them:
Uniform grid — simplest to implement, but when density is uneven the downtown cell blows up.
QuadTree — adapts to density, fast queries, but since drivers keep moving, maintaining the tree is expensive.
Geohash / S2 — collapse 2D coordinates into a 1D string; a shared prefix means spatial adjacency, so you can drop it straight into a KV store and querying becomes a prefix scan.
I picked Geohash as the primary approach, reasoning that this is a write-heavy, read-heavy, and needs-to-be-distributed system, and a 1D key shards naturally. The interviewer pushed on two things here:
"How do you handle Geohash boundary issues?" — two points can be physically close but fall on either side of a cell boundary, giving them completely different prefixes. The fix is to query the current cell plus its 8 neighboring cells together.
"Drivers report their location every 4 seconds — how much write pressure is that?" — I worked out the QPS and said position updates should go through memory (Redis) without hitting disk, while historical trajectories get written asynchronously to a time-series database — split into two separate paths.
After that we also talked about partitioning (by city, since cross-city queries basically don't happen), driver status (filtering out idle/on-trip drivers), and one thing I hadn't thought of: whether the results need debouncing, since driver positions keep jumping around and cars would look jittery on the frontend map otherwise.
This round ran the full 45 minutes, and the whiteboard was completely full by the end.
Round 4 — Hiring Manager
Half about my experience, half a coding question.
The problem: two arrays, where A[i] is the price of an outbound flight departing on day i, and B[i] is the price of a return flight on day i. The departure day must be before the return day. Find the cheapest round-trip combination.
My first instinct was a nested loop, and I said "that's O(n^2)" — he said "okay, optimize it."
The key insight: for each departure day i, what you need is the minimum of B[i..n-1]. So scan B from back to front and track the suffix minimum:
B = [6, 8, 9, 7, 9]
suffix min (right to left) C = [6, 7, 7, 7, 9]
answer = min(A[i] + C[i])
One preprocessing pass plus one scan, O(n). After I finished, he asked "what if departure and return also have to be at least 3 days apart?" — I said you just shift the starting point of the suffix-min back by 3, the logic doesn't change.
The experience part mainly asked about: the most impactful project I'd worked on recently, whether I'd ever badly underestimated a project's complexity at the start, and how I handle disagreements with people. All fairly standard questions, but he kept drilling down — "so how did you convince them," "did you have data to back that up."
A few takeaways
The problems aren't hard, but you need to be fast. None of my four rounds had anything above medium difficulty, but in every round the main problem only took up less than half the time — the rest was all follow-ups. So when you're practicing, don't stop the moment you get an AC — spend more time thinking about what happens when constraints get added.
Follow-ups almost always lead toward real systems. The data gets bigger, the data moves, the data arrives as a stream, it needs to be distributed — it's basically always one of these directions. Thinking through a pass of this ahead of time makes you a lot calmer in the moment.
Heaps and binary search are hard currency. Heaps came up twice across the four rounds, and being able to write out the quickselect partition without hesitating is a real bonus.
Be proactive in the system design round. I was basically the one driving this round the whole time, with the interviewer only chiming in at key points. Sitting back and waiting to be asked questions makes you look passive.
This is written pretty loosely, just whatever came to mind as I wrote it. Wishing everyone good luck.
Discussion
Loading comments…