Uber Staff Software Engineer Interview: What Changes at L5B

You passed the senior bar at Uber. Maybe you're L5A already, or you're coming in from another company targeting the staff title. Either way, the Uber staff software engineer interview you're about to face is a different animal. Same round names. Same conference rooms. Completely different expectations in every single one.

Uber runs over 1,000 interviews a month on a standardized rubric, with roughly 30% of candidates clearing the bar. At staff level (L5B in Uber's internal ladder), that rate drops further. The loop tests whether you think like someone who owns problems across teams, quarters, and org boundaries. Not someone who writes great code inside a Jira ticket.

Pam from The Office comparing two engineers who look different but are the same, like L5A and L5B candidates walking into the same interview loop When HR says "it's the same interview process for all levels."

Wait, Is It L5B or L6?

Uber's leveling history could fill its own blog post. Before 2022, the senior level (L5) became overcrowded. Engineers with wildly different scope sat at the same level, which is like calling both a studio apartment and a three-bedroom house "medium." Uber split it: L5A became the industry-standard "senior engineer" (team-scope projects), and L5B mapped to what most of Big Tech calls "staff engineer" (cross-team, multi-quarter projects). The old L6 got renamed to Senior Staff, and everything above shifted up.

If you're interviewing for "Staff Software Engineer" at Uber today, you're targeting L5B. If someone mentions L6, they're either using old terminology or talking about Senior Staff (a much rarer opening).

Uber Level	External Title	Scope
L5A	Senior Software Engineer	Complex, team-level projects
L5B	Staff Software Engineer	Cross-team projects spanning multiple quarters
L6 (new)	Senior Staff Engineer	Organization-wide technical strategy
L7	Principal Engineer	Company-wide impact (fewer than 1% of engineers)

What Does Each Round Test?

Expect five rounds across a single onsite day (or two days for remote). That's a full workday of being evaluated. Bring water.

Round	Duration	What It Tests
Coding	60 min	DSA fundamentals, runnable code, edge cases
Specialization Depth	60 min	Domain-specific problem-solving (backend, infra, mobile)
System Design	60 min	Architecture at scale, explicit tradeoffs, capacity math
Collaboration & Leadership	75 min	Project deep dive, cross-team influence, conflict resolution
Bar Raiser	60 min	Leveling calibration, project retrospective, or gap probing

The Bar Raiser is the round that doesn't exist at most other companies. An interviewer from outside your hiring team acts as an objective third party. They can probe anywhere. If your earlier rounds had a weak spot, expect the Bar Raiser to find it. They hold effective veto power: one strong rejection blocks the offer even if every other round went well. Think of them as the friend who always asks "but did you actually test it?"

The entire panel meets afterward, and the decision must be unanimous. Our general Uber SWE guide covers how the panel makes decisions. If you're weighing L5A versus L5B, the Uber senior engineer breakdown covers the L5A bar.

How DSA Changes at Staff Level

You still get LeetCode-style coding problems. Medium difficulty, occasionally medium-plus. Uber's coding rounds are not where staff candidates differentiate themselves, but they are absolutely where staff candidates get eliminated. You can't charm your way out of a TLE.

The problems stay the same. The standard rises.

At L5B, interviewers expect:

Runnable code, not pseudocode. Uber wants you to compile and execute. Test cases should pass. This isn't a whiteboard shop where you can wave your hands and say "you get the idea."
Proactive edge case coverage. You identify edge cases before the interviewer asks and test them without prompting. At staff level, waiting to be told "what about an empty array?" is a signal, and not the good kind.
Complexity analysis with reasoning. "O(n log n) because we sort once and binary search k times," not just "O(n log n)" followed by hopeful eye contact.
Clean structure. Modular functions, readable names, no magic numbers. Code quality signals how you'd write production code. If your variable names look like a cat walked across the keyboard, that's going in the write-up.

Common topics: hash maps, graphs, binary search, arrays, linked lists, matrices, and parsing. DP shows up occasionally but isn't the primary focus.

Joey from Friends looking shocked when the interviewer asks can we do better after getting O(1) Staff-level bar: they wanted O(1) and then asked for tradeoff analysis.

The specialization round goes deeper into your domain. For backend, this might mean implementing a distributed event batcher or buffered file writer. This round often includes concurrency follow-ups at the staff level, testing whether you think beyond the algorithm and into production concerns. "It works in a single thread" stops being a complete answer somewhere around year five.

Uber System Design: Where Staff Candidates Win or Lose

At senior level, you produce a reasonable architecture. At staff level, you produce a defensible one. With numbers. Real numbers, not "a lot of requests."

Uber's system design interviewers want math. TPS calculations, latency budgets, throughput limits, storage estimates. Not hand-wavy "we'll use Kafka." How many partitions? What's the consumer lag tolerance? What happens when a broker goes down during a Manhattan surge at 2 AM on New Year's Eve?

What Gets Asked

Questions grounded in Uber's actual problem domain:

Ride matching and dispatch. Match riders to nearest drivers across millions of concurrent users. Geospatial indexing (geohashing, S2 cells, quadtrees), driver location update frequency (~4 seconds), and fan-out math for broadcasting requests.
Real-time location tracking. Show every active driver on a map. WebSocket vs polling tradeoffs, battery drain, eventual consistency for stale positions.
Surge pricing. Data inputs, demand zone partitioning, graceful degradation when the pricing service is down. (Hint: "charge nothing" is not the right answer.)
Notification pipelines. Delivery guarantees, deduplication, multi-region fanout at scale.

Standard distributed systems questions show up too, scaled to Uber constraints.

Astronaut meme: wait it's all cache? Always has been. The universal system design truth Every system design answer, eventually.

What L5B Answers Look Like

A senior candidate draws boxes and picks reasonable technologies. A staff candidate does that and then makes you believe the system would actually survive a Tuesday.

Runs capacity math. "5 million active drivers updating every 4 seconds = 1.25M writes/sec. At ~100 bytes each, that's 125 MB/s before replication." This separates a reasonable design from a defensible one.
Makes tradeoffs explicit. "Eventual consistency for driver locations because a 2-second stale position is acceptable for matching. Strong consistency for the payment ledger." Say it out loud with the reasoning. The interviewer can't give you credit for thoughts that stay in your head.
Volunteers failure modes. What happens when dispatch crashes? How does the system degrade? Staff candidates don't wait for "what if X fails." They bring it up like they've been paged at 3 AM before. Because they have.
Raises operational concerns. Zero-downtime deployment, multi-region strategy, monitoring. These are staff-level signals that senior candidates rarely hit.

Your Stories Determine Your Level

The hiring manager round. This round determines your level, not just hire or no-hire. You can pass every technical round and still land L5A if your stories only show team-scope work.

The format: a deep dive into one or two past projects. At L5B, the project should span two to three quarters, involve multiple teams, and have measurable business impact. "I refactored our API layer" is a senior story. "I designed the migration strategy, negotiated the timeline with three dependent teams, and built the rollback mechanism" is a staff story.

The interviewer probes:

Your contribution versus the team's. "I designed the migration strategy, negotiated the timeline with three dependent teams, and built the rollback mechanism." Not "we migrated the service." Every "we" without a follow-up "I specifically" is a missed opportunity.
Architecture tradeoffs. What did you consider and reject? What would you change now? Hindsight is 20/20, and interviewers love candidates who use it.
Cross-team coordination. How did you align teams with different priorities? How did you handle pushback? Bonus points if you can describe the pushback without sounding bitter about it.
Quantified impact. "Reduced cold-start latency by 32%" beats "improved performance significantly." If you don't have numbers, you'll lose signal in the write-up. Interviewers can't write "vibes were excellent" on the scorecard.
Handling failure. What broke, how you diagnosed it, how you recovered. A stronger signal than a project that went perfectly. Everyone loves a comeback story.

If you say "we" for everything, they'll write "unclear individual contribution." This is the same evidence problem that kills candidates everywhere: the write-up only captures what you said, not what you know.

The Bar Raiser Can Veto Your Offer

Not a repeat of any earlier round. The Bar Raiser ensures the hire clears Uber's company-wide bar, not just the team's. They're the quality control department, and they take the job seriously.

For staff candidates, it runs one of two formats:

Reverse system design. You present a project you've built, and the interviewer interrogates it. They'll challenge architecture choices, push on scaling limits and failure modes, and test whether you understand the system deeply or just managed it. "I inherited the architecture" is not a great opening line here.
Targeted gap probing. If your coding was shaky, they run another technical problem. If your leadership stories were thin, they dig into influence and conflict. They fill the scorecard wherever it's weakest. It's like the boss fight that adapts to your play style.

For L5B leveling, the Bar Raiser wants a multi-quarter initiative where you set technical direction beyond your immediate team. Single-team, single-quarter stories may earn L5A but not L5B.

Why Staff Candidates Fail the Uber Staff Engineer Interview

Generic system design prep. Uber's questions are grounded in real-time systems, geospatial problems, and high-throughput event processing. "Design Twitter" prep won't cover the scale math and domain specificity. You wouldn't study French for a Spanish exam.

Code that doesn't run. Surprisingly common among experienced engineers who treat the coding round as a formality. Uber requires compilable, executable code with tested edge cases. Seniority doesn't grant you a pseudocode pass.

Behavioral answers without numbers. "I led a migration of 14 services over two quarters, cutting deploy time from 45 to 8 minutes and incident rate by 60%" is a staff answer. "I led a large migration" is not. One gets written down. The other gets a polite nod.

Single-team scope in every story. If every project happened within your team's boundaries, the panel can't justify L5B. The entire staff definition at Uber is cross-team. It's in the name.

Uber Staff Software Engineer Interview Prep: Six Weeks Is Enough

Weeks 1 to 3 (Coding). Solve 40 to 50 mediums across hash maps, graphs, binary search, trees, and arrays. Uber's coding bar is medium, not hard, but execution standards are high. Time yourself at 35 minutes including testing. Review concurrency if you're targeting backend.

Weeks 3 to 5 (System Design). Read Uber's engineering blog for posts on dispatch, geospatial indexing, and Kafka. Practice capacity math until it's automatic. Run at least three mock system designs on SpaceComplexity, focusing on ride matching, location tracking, and surge pricing.

Weeks 5 to 6 (Leadership and Bar Raiser). Pick two to three projects with cross-team scope and quantified results. For each, prepare: hardest technical decision, what went wrong, how you handled disagreement, what you'd change. Practice the reverse system design format to simulate the Bar Raiser.

Timeline. Uber's process typically takes four to six weeks. Referrals may skip the phone screen. The onsite is usually within two weeks of passing the screen.

What to Remember

Uber's staff level is L5B: cross-team, multi-quarter projects, not just senior execution done well.
Five rounds, unanimous decision required. One rejection can block the offer.
DSA stays at medium difficulty, but execution standards rise. Runnable code, proactive edge cases, clean structure.
System design is the differentiator. Capacity math, explicit tradeoffs, failure modes, and Uber-domain problems.
The leadership round determines your level. Cross-team scope, concrete metrics, honest failure analysis.
The Bar Raiser has veto power. Prepare for reverse system design or targeted probing of your weakest round.