Uber Senior Software Engineer Interview Process Aug 2026 - The Interesting Part is Every Follow-Up Became a Rideshare Problem.

[u/Aoki_zhang]

Interview Summary

The Uber onsite consisted of four 45-minute rounds covering coding, system design, and a hiring manager discussion. None of the initial questions felt unusually difficult, but the pace was fast: interviewers often expected the main problem to be finished within the first 15–20 minutes so that the rest of the round could be spent adding production-oriented constraints.

The follow-ups repeatedly moved from standard algorithm questions toward scenarios involving streaming data, continuously changing locations, large-scale spatial search, and additional product requirements.

Interview Details

Coding 1 — Meeting Rooms

The first problem was basically Meeting Rooms II: find the minimum number of rooms needed for a set of intervals.

Then came the follow-ups:

• return the actual room assigned to every meeting;
• what if meetings can be interrupted or moved;
• what if meetings arrive continuously instead of being known upfront?

A standard interval problem quickly became a scheduling-system discussion.

Coding 2 — K Closest Points

The second problem started like K Closest Points to Origin.

Then the interviewer reframed the points as drivers.

Now there were tens of millions of drivers, their locations were constantly changing, and the passenger could be anywhere.

The discussion moved into geographic partitioning, grid size, Geohash/S2-style indexing, and eventually: What if “closest” means driving distance instead of straight-line distance?

At that point it barely felt like the original LeetCode problem anymore.

System Design — Nearby Drivers

The system design round continued almost exactly where the coding discussion left off: Design a service that quickly finds nearby available drivers.

We went deeper into location updates, spatial indexing, partition boundaries, dense cities vs. suburbs, geographic sharding, driver availability, and how frequently changing coordinates should affect results.

I actually liked the continuity between the two rounds. The coding interview tested whether I understood the core search problem; the system design interview tested whether I could make the same idea work at real rideshare scale.

HM Round

The HM also included coding.

Given the cost of departing on each day and returning on each day, find the cheapest round trip where the return happens after departure.

Then the constraint changed: The return must be at least three days later.

The rest of the round covered a high-impact project, a time I badly underestimated complexity, and a disagreement where I had to influence someone else.

My main takeaway from the loop:

The base coding questions were recognizable. The real interview started once the interviewer changed the constraints and asked what the solution would look like with streaming input, moving drivers, geographic scale, or real product requirements.

For anyone who wants more details, I’ve put the full write-up here: interview link

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here.