Uber Software Engineer Interview Guide
Published 4 October 2026
Uber's SWE loop is not just LeetCode. For backend roles it scores four separate competencies, and only one of them is classic algorithms. People who grind only puzzles tend to do fine in the first coding round and then struggle in the others.
Solve it, make it run, then keep it correct when the interviewer changes the rules. Most Uber rounds get interesting after your first answer works.
What makes Uber different¶
Most of Uber's state stands for something happening in the real world: a driver driving, a rider waiting, a courier holding food, a payout leaving a bank account. When the software is wrong, a real person feels it right away. So interviewers keep asking the same few questions in different forms:
- Which copy of this state is the source of truth?
- What is allowed to be stale, and for how long?
- What happens if this message arrives twice, or never?
- Is this operation safe to retry?
Have answers ready for those, from the coding rounds through to system design.
The four competencies¶
Uber publishes its own interview prep material for engineering, split by domain (backend, frontend, mobile, data, ML, security, production engineering and more). For backend, it names four areas:
| Competency | Question it answers | Where it shows up |
|---|---|---|
| Algorithms & Data Structures | Do you know your CS fundamentals? | Phone screen, coding round 1, sometimes an OA |
| Depth in Specialization | Can you build real software in your area? | Coding round 2, machine coding |
| Design & Architecture | Will it survive scale and failure? | System design, mostly for L5 and up |
| Collaboration & Leadership | Can you own it alongside other people? | Behavioral / hiring manager round |
Levels for backend run L3, L4, L5A, L5B, L6+, and the loop shifts with level. L5A vs L5B is a real difference in scope and pay, so ask which one you're being considered for.
The loop¶
The exact sequence depends on the team, the level and the location. A typical experienced backend loop looks like this:
- Recruiter call (~30 min): background, motivation, level.
- Online assessment (some pipelines only): a timed HackerRank-style test.
- BPS (Business Phone Screen) (~60 min): live coding. It can turn into design questions partway through.
- Onsite / virtual onsite, usually some subset of:
- Coding: algorithms & data structures
- Coding: depth in specialization (practical / machine coding)
- Low-level design
- System design
- Project deep dive (more common for senior and above)
- Collaboration & leadership
- Debrief and leveling: the panel decides both whether to hire and at what level.
Ask your recruiter¶
Loops vary across Uber, so get your own loop from the recruiter instead of trusting someone else's interview story:
- How many rounds, and what is each one?
- Which level, and is it L5A or L5B?
- Is there an OA? What does the BPS cover?
- Is there a machine coding or LLD round? A separate system design round?
- Will my code need to run? Which languages are allowed?
- Are AI tools allowed in any round? (Assume no unless told otherwise.)
- Is this for a specific team? What does that team own?
- Is there prep material you can share? (Uber has real prep docs. Ask for them.)
Recruiter call¶
The recruiter is trying to place you: what kind of engineer you are, which part of Uber fits, and whether your past scope backs up the level you're aiming for. Uber's orgs differ a lot (Rides, Eats, Payments, Maps, Ads, infra, autonomous), so "generic big-tech backend engineer" is a weak pitch.
Lead with the kind of system you're good at, and attach numbers to it:
| Vague | Specific |
|---|---|
| "I do backend in Go." | "I build stateful event-driven services. I own our order pipeline end to end: schema, Kafka topics, dedupe, deploys, on-call." |
| "I worked on payments." | "I owned refunds, where paying out twice is the worst bug you can ship, so I designed the idempotency keys and the nightly reconciliation job." |
| "I want Staff, I have 10 years." | "For the last two years my designs have been adopted by teams outside mine, and I set the migration plan three teams followed." |
Have a two-minute career story ready, plus a "why Uber" that's about the problems, not the brand.
Coding round 1: algorithms¶
Expect standard medium-to-hard problems. Topics that come up often:
- Graphs: BFS/DFS, topological sort, union-find
- Sliding window, including the monotonic-deque variants
- Heaps and scheduling
- Intervals, trees, binary search
- Caches (LRU) and counters
Practice prompts in the Uber style:
- Longest subarray where max − min stays under a limit (window + two deques).
- Recover the alphabet order from a sorted list of words (topological sort).
- Count hits in the last 5 minutes when there are millions of writes per second.
- Keep track of which regions connect as cells come online one by one (union-find).
- Assign incoming jobs to the least-loaded worker (heap).
How to run the round¶
- Repeat the problem back and pin down the edge semantics: inclusive or exclusive bounds, sorted input or not, duplicates.
- Give the brute-force answer and say why it's slow.
- Give the better approach and its time and space complexity.
- Write the code cleanly, because follow-ups will build on it.
- Trace through one example, then test the edge cases on purpose.
Worked example: the hit counter¶
"Count requests in the last 300 seconds. Writes are extremely frequent."
A queue of timestamps works and is amortised O(1). But at millions of writes per second
you're storing millions of objects, and memory becomes the real problem. If one-second
resolution is acceptable, use a ring of 300 buckets indexed by t % 300, each holding
(second, count). A write is a single increment. A read sums the buckets that are still
in the window, or you keep a running total and subtract buckets as they expire if reads
are frequent too.
The interviewer wants to see you shape the solution around the workload (lots of writes, fixed window), not just pick the textbook structure.
Coding round 2: depth in specialization¶
This round is the one people don't prepare for. Instead of one function you build a small stateful component. Then the interviewer adds requirements, one at a time.
| Puzzle round | Practical round |
|---|---|
| One function | A class with several operations |
| Fixed spec | The spec changes every 10 minutes |
| Output is all that matters | State and invariants matter |
| Single-threaded | "What if two threads call this?" |
| Done when it passes | Done when it survives the follow-ups |
Typical shapes: restaurant availability, rate limiter, TTL cache, trip state machine, assigning drivers without double-booking, "now publish an event on every change, and what if publishing fails?"
Worked example: open restaurants by zone¶
Round one: open(id), close(id), countOpen(). A set of open IDs is enough.
Then: "Restaurants serve one or more delivery zones. Return the open count for a zone."
Leave the open/closed state alone and add an index next to it: restaurant → zones, and
zone → count (or zone → set of IDs if a later API needs the IDs). When a restaurant
opens or closes, you update the zones it belongs to. Before you write the code, ask:
can a restaurant change zones while it's open? That's another state transition, and
asking about it is part of what's being graded.
Habits that score well:
- State the invariants out loud ("count for a zone = number of open restaurants in it").
- Ship a complete simple version first, then extend it.
- When the spec changes, refactor only the part it affects, and keep the old tests passing.
- Finish by explaining what would change in production: persistence, concurrency, failure handling.
Low-level design / machine coding¶
When this is its own round, it means working, well-organised code, not a UML diagram and not a quiz on design pattern names. Use a pattern only when a requirement actually calls for it.
Good practice problems: ride-hailing core (rider, driver, trip lifecycle), parking lot, reservation system with concurrent bookings, rate limiter with pluggable strategies, elevator, in-memory file system.
| LLD | HLD |
|---|---|
| Classes and interfaces | Services |
| In-memory state | Durable, replicated state |
| Method contracts | Network APIs |
| Locks and thread safety | Distributed coordination |
| Unit tests | SLOs and alerting |
System design¶
For L5 and above this round often decides the level. A generic "load balancer → service → cache → DB" answer won't get you far. Uber problems combine high write volume, state that changes every few seconds, and real-world harm when the system gets it wrong.
Uber-shaped prompts to practice:
- Nearby drivers / live location tracking
- Rider–driver matching and dispatch
- Surge pricing
- Driver payouts
- Trip state and receipts
- Food delivery order lifecycle
- Notifications at fan-out scale
Design notes already on this site that fit: nearby drivers, Uber payout system, live location tracking, payment processor.
For every design, answer these explicitly:
- Source of truth. Which store owns each piece of state?
- Staleness. Driver locations can be a few seconds old. A payout ledger can't be wrong at all.
- Duplicates and retries. Idempotency keys, dedupe windows, exactly-once effects.
- Disagreement. Two services disagree about a trip. Who wins, and how do you reconcile?
- Hot spots. Stadium letting out, New Year's Eve, a single busy city cell.
Project deep dive¶
Pick one project you know very well and can defend for 45 minutes. Know:
- The problem, and why it mattered in numbers.
- The architecture, and the options you rejected.
- What you personally decided, separate from what the team did.
- How it failed in production, and what you changed afterwards.
- What you'd do differently now.
"We built a service" is weak. "I picked Postgres over Dynamo because of X, and that cost us Y when Z happened" is strong.
Collaboration & leadership¶
These are STAR answers, but give them technical substance. Prepare stories for:
- A production incident you owned.
- A design argument you won, and one you lost.
- Pushing back on a deadline or a requirement.
- Unblocking another team.
- Raising the bar: reviews, mentoring, standards.
- A mistake, and what you changed because of it.
The same story should sound different at different levels. At L4, I fixed the bug. At L5, I found the class of bugs and fixed the system. At Staff and above, I changed how several teams build so the bug class stopped happening.
Level expectations¶
| Level | Roughly |
|---|---|
| L3 | Solid coding, needs guidance on scope |
| L4 | Owns features end to end on their own |
| L5A | Owns a system; leads design within the team |
| L5B | Owns larger, ambiguous systems; influences beyond the team |
| L6+ | Sets direction across several teams; multiplies other engineers |
Common mistakes¶
- Preparing only LeetCode and getting caught off guard by practical coding.
- Coding before clarifying the semantics.
- Over-building the first version and running out of time for follow-ups.
- Writing pseudocode when the round expects code that runs.
- Ignoring concurrency until the interviewer brings it up.
- Giving a generic system design with no idempotency, staleness or reconciliation story.
- Telling behavioral stories with no technical detail, or at the wrong level.
Prep plan¶
| Area | Mid-level (L4) | Senior (L5A/B) | Staff+ |
|---|---|---|---|
| Algorithms | 40% | 25% | 15% |
| Practical / LLD | 30% | 25% | 15% |
| System design | 10% | 30% | 40% |
| Deep dive + behavioral | 20% | 20% | 30% |
A good capstone: build a small local delivery dispatch service. Couriers send location updates, orders get assigned without double-booking, the order state machine publishes events, and a payout calculation runs at the end of a shift. It touches every round above.
Final week: stop learning new topics. Do timed mixed problems, rehearse two designs out loud end to end, and say your project and STAR stories aloud until they're tight.