What the round is like
Candidates and Uber's own guide call this round Design and Architecture, and it's often the bar raiser. You can expect it if you're mid-level or above. New grads usually don't get one. They get a smaller design-in-code round instead, like modeling an employee hierarchy or a file system.
Your interviewer will poke at how it scales, what happens when things fail, and why you picked what you picked. Some phone screens also fit in about 15 minutes of design or past-project talk before the coding.
What people have been asked
These come up in candidates' own write-ups of their interviews. Some are problems Uber actually has, and some are classics like a chat app. We wrote the example prompts ourselves, so the wording you get will be different.
Match riders with nearby drivers
Recent reports have the Uber Eats version: an order's ready, so assign a nearby delivery partner and track them to the restaurant and then the customer. We've written it as rides, but the moving parts are the same.
Drivers and delivery partners are always moving, so you need a fast way to search them. And you can't let two riders or two orders grab the same one.
How it might be asked
Let's design the part of a ride-hailing app that matches riders with drivers. When someone requests a trip, find a nearby available driver and offer them the ride. If they decline or don't respond, try someone else. A driver should never have two trips at the same time, and this needs to work in lots of cities at peak times. How would you build it?
Key concepts to know
Try this Interview
Track driver locations
Every active driver sends GPS updates every few seconds. Take all of that in and make the latest positions available to other services.
That's a ton of writes, and each one is out of date a few seconds later. Saving every single update to a database probably isn't where you want to start.
How it might be asked
Drivers' phones send their GPS position every few seconds while they're online. Design the system that takes in those updates and lets other services ask where a driver is right now, or which drivers are in a certain area. Assume millions of drivers around the world.
Key concepts to know
Try this Interview
Stock price alerts
A price feed comes in. Notify everyone who follows a stock when it moves more than a set percent from the previous close. Candidates report this one more than any other.
One big move can mean a flood of notifications at once. You don't want to send the same alert twice, and you need a plan for sends that fail.
How it might be asked
We get a stream of stock prices with the symbol, current price and previous close. Users subscribe to stocks. When a price goes up or down more than 5% from the close, send them a push notification. Design it.
Key concepts to know
Try this Interview
Build a driver heatmap dashboard
Show where drivers are in a city, both over the last few minutes and hour by hour for the day before.
It's the same data going to two very different places. One needs to be fresh and the other needs to stick around.
How it might be asked
Our analytics team wants a dashboard with a heatmap of drivers in a city. They need one view of the last 20 minutes, close to real time, and another where they can look at yesterday hour by hour. Design the backend for it.
Key concepts to know
Try this Interview
Nearby restaurants for Uber Eats
Store restaurants and quickly return the ones near a customer, then deal with packed city centers and places with nothing around.
A normal index can't search by distance. Candidates say interviewers dig into the schema and how you store locations, then push on latency.
How it might be asked
Design the backend that shows a customer the restaurants near them when they open Uber Eats. Focus on how you store restaurant locations and query them fast. What happens in a dense city center, or where there's nothing nearby?
Key concepts to know
Try this Interview
Chat app
One-to-one and group messaging with offline delivery, receipts and history, scaled to Uber's size.
Messages have to reach people who might be offline, in order, without getting lost. Receipts add a pile of tiny writes on top.
How it might be asked
Design a chat app like Messenger. Support one-to-one and group chats, people who are offline, delivered and read receipts, and message history. Then tell me how it scales.
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| Location data | How do you search by distance when a normal index can't? |
| Lots of writes | What takes millions of tiny updates without melting your storage? |
| Fan-out | One event, lots of people to tell. How do you send it to all of them, and only once? |
| Freshness | What has to be current, and what can show up later? |
| Correctness | Where's close enough fine, and where is it a real bug, like giving one partner two orders? |
| Failure | What does a rider or driver actually see when something goes down? |
Worked example: a driver heatmap
You've got to build an internal dashboard showing drivers in a city, both for the last 20 minutes and hour by hour the next day. One candidate got this as their bar raiser design round. It's a nice example because the same data has to work for two very different views.
One way to build it
Each location gets turned into a map cell. Send everything for the same cell to the same worker, and that worker can count it up over time. Then each view reads from its own place:
| Live view | Next-day view | |
|---|---|---|
| Shows | The past 20 minutes | Hourly totals |
| Stored in | A fast in-memory store | A relational database |
| Organized by | City, map cell and minute | City, map cell and hour |
| Kept for | Minutes | As long as the business wants it |
How to work through a question
- Figure out what you're building. Who's using it, what does it need to do, and what can you ignore?
- Do some rough math. How many requests, how much data, more reads or more writes? Those answers decide a lot.
- Walk through one request. Draw the simplest thing that works before you add anything fancy.
- Pick storage last. Once you know what gets read, how often and how fresh it has to be, the choice gets a lot easier.
- Then try to break it. What happens in a traffic spike? What if a server dies?
Key concepts to know
If you're rusty on any of these, start here.
- Geospatial indexingFind what's nearby with map grids like geohashes and H3.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Stream processing and windowingCount things in data that never stops coming in.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
- Consistency and the CAP theoremWhat happens when copies of your data can't agree.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Real-time deliveryPush updates to users the moment they happen, with WebSockets and friends.
- Search and inverted indexesFind text fast, rank what comes back, and keep the index fresh.
Sources
- LeetCode Discuss: Uber L5A SSE experience (2025)
- LeetCode Discuss: Uber SE II, 6 rounds, rejected (2026)
- LeetCode Discuss: Uber L4 US offer (Sept 2025)
- LeetCode Discuss: Uber L5-A Bangalore (2025)
- LeetCode Discuss: Uber onsite, Bay Area Maps Routing (2024)
- LeetCode Discuss: Uber L5A, delivery partner matching (2026)
- Jointaro: Uber senior SWE, Amsterdam (2024)
- Uber Engineering: H3 geospatial index
- Uber Engineering: Ringpop
These questions come from candidates' own write-ups, so yours might be different. Practice Loop is independent and isn't affiliated with or endorsed by Uber.