Uber Onsite Interview: Every Round Explained

You cleared the phone screen. The recruiter sounds pleased. Now comes the part everyone warned you about but nobody fully explained.

The Uber onsite is four to six rounds across a virtual day. Most candidates spend six weeks preparing for the coding rounds and walk into the technical retrospective completely unprepared. That round ends more offers than any other, and it looks nothing like a system design question.

Here is the shape of the full loop.

What the Uber Onsite Loop Looks Like

The standard onsite has five rounds, each 45 to 60 minutes:

Round	Duration	Who Runs It
Coding Round 1	45-60 min	Senior IC
Coding Round 2	45-60 min	Senior IC
System Design	60 min	Senior or Staff IC
Technical Retrospective	60 min	Hiring Manager or Senior IC
Behavioral / HM Round	45-60 min	Hiring Manager

New grad and SWE-1 loops sometimes skip the retrospective or fold behavioral into the HM round. L4 and above get all five. Senior and staff candidates occasionally see a sixth round: a domain-specific architecture deep dive. You will not meet the same interviewer twice, which feels fine until you realize they are all comparing notes.

Five-round interview loop flow diagram

The Two Coding Rounds: Medium Difficulty, Maximum Narration

Expect medium-difficulty problems, leaning toward medium-hard for SWE-2 and above. The standard patterns that come up most often: graphs and BFS/DFS, sliding window, heaps and priority queues, dynamic programming on arrays, and two pointers.

The biggest difference from the phone screen is that both correctness and code quality get evaluated. Pseudocode is not enough. Interviewers want working, runnable code with edge cases handled before you declare yourself done.

The second coding round sometimes has a domain slant. A backend candidate might get "implement a rate limiter." An infrastructure candidate might trace through a cache invalidation scenario. The core algorithmic challenge is still medium-level. The framing just borrows from Uber's actual problem space, which is their polite way of asking: have you thought about any of this before?

What the rubric cares about:

Did you clarify constraints before writing a single line?
Did you name the brute-force approach first, even if you immediately knew the optimal?
Did you communicate your reasoning as you coded, not after?
Did you trace through at least one non-trivial example before saying "I think this is right"?

Silence is the most common failure mode. Not "I don't know the answer" silence. The "I solved it correctly and said nothing for eight minutes" silence. An interviewer watching you type without narration has nothing to write in the debrief. The best possible outcome there is a weak hire with a note that says "seemed smart, hard to tell."

For prep, work LeetCode mediums without tags and practice talking through brute force before writing optimal. The DSA for backend engineers guide covers the patterns that come up most at infrastructure-adjacent companies like Uber.

The System Design Round: Scale Math, Not Buzzwords

For L4 and above, this is the highest-stakes round. Uber matches rides across millions of trips daily, streams driver location at hundreds of thousands of writes per second, and routes requests through a microservices mesh of 2,000 plus services. The person interviewing you has probably been paged by several of those systems at 2am. They will notice when your design does not add up.

The mistake that eliminates most candidates is designing for maximum scale before confirming what scale the interviewer actually wants. Start with the questions: "Are we building for one city or globally? What's the expected daily active rider count? How stale can driver location data be?" Those answers change everything downstream.

After requirements, anchor your answer on four things:

A high-level component diagram with data flow
The data model: what you store, where, and why
The hottest bottleneck and how you address it
One concrete failure mode and your mitigation

There is a piece of documented rejection feedback that circulates in Uber prep guides: "You're building a rocket to deliver mail." It is aimed at candidates who immediately design a globally distributed, multi-region, event-sourced microservice architecture when the interviewer asked for a rate limiter. Start with the simplest thing that works. Add complexity only when you can point to a specific constraint that demands it.

The ride-sharing system design interview walkthrough covers the exact architecture Uber-style problems test: two data stores (PostgreSQL for trips, Redis for live positions), driver location at 500K writes per second, and the optimistic locking race condition that trips up most candidates. For the full 45-minute framework from clarification to close, system design interview tips breaks down the structure.

The Technical Retrospective: Not What You Think It Is

This is the round that catches experienced engineers most often. Candidates who prepare for it like a system design question walk in and describe what their system does. That is not the same thing.

A technical retrospective is a forensic conversation about decisions you actually made, not a design exercise.

The interviewer picks a project from your resume, usually the one that sounds most complex, and asks you to walk through it. Then they probe.

Why did you choose Postgres over DynamoDB at that scale?
What would you do differently now?
Who else was involved, and how did you make the final call?
What broke in production after you shipped?

The round surfaces two things at once: technical depth and self-awareness. "We chose microservices because it scales better" with no concrete reasoning does not pass. Neither does a project where the answer to every probing question is "the team decided."

Pick two or three projects ahead of time. For each one, know: the original constraints, at least one decision where you weighed real alternatives, something that broke in production and how you diagnosed it, and what you would change with hindsight. You should be able to defend the technical details for 45 minutes. If you cannot, pick a different project.

Do not prepare a project where someone else made all the interesting decisions. The interviewer will find that gap inside of five minutes.

The Behavioral Round: Numbers, Not Narratives

The hiring manager leads this round. Expect experience-based questions ("tell me about a time you disagreed with a product decision") alongside hypotheticals about values and judgment.

Come prepared with actual numbers. "We reduced p99 latency by 40%" lands in a debrief. "We improved performance significantly" does not. The hiring manager cannot quote vague outcomes to a hiring committee. They will write "mentioned performance improvement" and move on.

Uber's cultural principles around customer obsession, doing the right thing, and acting like an owner frame the evaluation. You do not need to memorize them. Your stories should reflect decisions made from conviction, not from instruction. There is a difference between "I was on the team that reduced latency" and "I decided to rewrite the serialization layer after benchmarking three alternatives." The hiring manager is listening for ownership, not just involvement.

Why Good Candidates Get Rejected

The Uber loop rejects candidates for two reasons that look similar on the surface: missing the signal and giving the wrong signal.

Missing the signal means going silent, writing code without narrating, or solving the problem correctly but leaving the interviewer nothing to write in the debrief. A correct solution in silence is a weak hire at best.

The wrong signal is more specific to Uber's loop:

Jumping to code. Uber interviewers flag this consistently. Not clarifying before coding reads as poor judgment, not impressive speed.

Skipping brute force. If you go straight to optimal, the interviewer cannot tell whether you understood the problem or just recognized the pattern. Name the naive approach. State its complexity. Then improve it.

Over-engineering the system design. See: rocket, mail.

Treating the retrospective as a team story. If every interesting decision is "we," the interviewer has no signal on you specifically.

Not testing your code. Trace through a non-trivial example before you say you are done. The interviewer is watching for this specifically and has a line on the rubric for it.

The technical interview communication post covers what interviewers are actually writing down while you solve.

How Long to Prepare

For candidates actively interviewing, four to six weeks is enough with consistency. Eight to ten weeks is more realistic after a gap.

Weeks one and two: Cover the core DSA patterns. Graphs, trees, sliding window, heaps, DP on arrays. Work mediums without hints or tags. Do not grind hundreds of problems. Grind the same patterns in different framings until you can identify the structure on sight.

Weeks three and four: Run three to five full system design sessions. One ride-sharing design, one feed or notification system, one rate limiter or API gateway. Timebox each to 45 minutes and practice narrating aloud. Out loud. To yourself if necessary. Your housemates will understand eventually.

Week five: Retrospective prep. Write two pages on each of your three strongest projects. Then practice answering probing questions from someone else, or record yourself and listen back. If neither option is available, answer out loud anyway.

Week six: Mock interviews. At least two or three full-length sessions. The point is not to practice getting answers right. It is to practice performing under conditions that actually feel like an interview. If your mock sessions feel comfortable, they are not doing what you need.

SpaceComplexity runs on-demand voice-based DSA mock interviews with rubric-based feedback. Useful for training the narration habit before the real loop, especially if your current practice involves solving problems silently and hoping that somehow translates to talking through them under pressure.