Uber runs one of the more predictable big-tech interview loops, which is good news: you can prepare for exactly what’s coming. The 2026 process for software engineers is a recruiter call, a CodeSignal assessment with four problems, a live technical phone screen, then a virtual onsite of four to six rounds. Start to finish it usually takes two to six weeks, and the whole thing leans harder on graph problems than almost any comparable loop.
That graph bias isn’t an accident. Uber’s product is a graph: riders and drivers on a road network, couriers on delivery routes. Interviewers pull problems from that world, so a candidate who has only drilled array puzzles hits a wall around round three.
The loop, stage by stage
The recruiter screen matters more at Uber than at most companies. Recruiters use it to shape your onsite, deciding whether the loop tilts backend, frontend, mobile, or specialized systems. Come in with a clear answer about what you want to work on. A vague answer gets you a generalist loop, and generalist loops at Uber carry more system design.
Next is the CodeSignal online assessment: 70 to 90 minutes, four problems, auto-scored. The typical mix is one easy array or string warm-up, two mediums, and one harder problem, usually graph traversal or dynamic programming. Uber cares about the score, not your elegant-but-unfinished fourth solution, so practice in CodeSignal’s own environment beforehand. The editor, the test-case format, and the clock pressure are a skill of their own.
Clear the assessment and you get a live phone screen with an Uber engineer, typically run in CodeSignal with a Zoom call alongside. Expect one or two medium problems in 45 to 60 minutes, with the interviewer paying attention to how you narrate decisions while you type. Silent coders do badly here even with working solutions.
The onsite, usually virtual, is where leveling happens. Four to six rounds at 45 to 60 minutes each: two coding rounds, one system design round (two for senior candidates), and a behavioral round that works like a bar raiser.
| Uber SWE interview stage | Format | What it evaluates |
|---|---|---|
| Recruiter screen | 30-minute call | Background, team direction, comp expectations; shapes the rest of the loop |
| CodeSignal assessment | 4 problems, 70 to 90 minutes, auto-scored | Arrays, strings, one graph or DP problem; speed under a clock |
| Technical phone screen | 45 to 60 minutes, live coding on CodeSignal plus Zoom | One or two medium problems; communication while coding |
| Onsite coding (two rounds) | 45 to 60 minutes each | Graphs (BFS/DFS, Dijkstra), heaps, sliding window, intervals, often framed as maps and routing |
| Onsite system design (one round, two for senior) | 45 to 60 minutes | Geospatial and real-time systems; depth here drives the leveling decision |
| Onsite behavioral / bar raiser | 45 to 60 minutes | Stories mapped to Uber’s cultural values, ownership of failure, conflict handling |
What the coding rounds actually ask
Recent candidates report problems dressed in Uber’s domain rather than abstract puzzle wording. The algorithms underneath are standard; the framing comes from maps and routing. A sample of the phrasing you’ll hear:
- “Given a city grid where some intersections are blocked, count the distinct routes between two points.”
- “You have trip start and end times. Find the minimum number of drivers needed to cover every trip.”
- “Pickup and drop-off events arrive out of order. Validate whether the trip log is consistent.”
- “Edge costs on this road network change by time of day. Find the cheapest route.”
Sliding window, heaps, BFS and DFS, and interval scheduling cover most of what shows up. Dijkstra appears often enough that you should be able to write it cold. Uber interviewers also weight working code more heavily than some peers: they’ll ask you to trace your own test cases and expect you to catch the off-by-one before they point at it. Language choice is open. Uber’s backend runs mostly on Go and Java, but nobody cares if you interview in Python, and most candidates should, since it’s faster to write under a clock.
System design has a geospatial accent
The design round is where Uber’s loop separates from generic big-tech prep. You might get “design a rate limiter,” but you’re at least as likely to get “design driver-rider matching,” “design order tracking for Uber Eats,” or “design a service that ingests millions of GPS pings a minute and answers nearby-driver queries.”
If you draw a geospatial prompt, talk about spatial indexing by cell. Uber built and open-sourced H3, its hexagonal grid system, and interviewers respond well to a candidate who shards location data by hex cell rather than waving at “dividing the map into regions.” You don’t have to know H3 internals. The concept is enough: bucket moving objects into cells and query a cell plus its neighbors, sizing cells to balance query fan-out against update churn.
For L4 candidates, a clean high-level design with sensible storage choices passes. For L5a and up, interviewers push on failure modes: what happens when a region’s datacenter drops, how matching latency holds during a surge event, where backpressure goes when ping volume spikes. The leveling decision often rides on this round. A senior candidate who breezes through coding but stays shallow in design usually gets a downlevel offer at L4 rather than a rejection.
The bar raiser round and Uber’s rewritten values
Uber’s behavioral round is a real filter. One interviewer, often from outside the hiring team, runs the session against Uber’s cultural values, rewritten after the 2017 era: “Go Get It,” “Trip Obsessed,” “Build with Heart,” “One Uber.” Recent candidates consistently advise mapping your stories to these names without reciting them like a pledge. Interviewers notice both the mapping and the reciting.
Expect prompts like “Tell me about a time you disagreed with your manager and turned out to be wrong” or “Describe a project you drove that failed, and what you owned.” The company’s post-2017 history makes interviewers allergic to candidates who claim credit and deflect blame. A story where you were plainly at fault and fixed it lands better than one where you were heroically right.
What Uber pays in 2026
Uber’s engineering ladder starts at L3 for new grads, L4 is mid-level, and senior splits into L5a and L5b, which gives Uber two senior bands where most companies have one. Per levels.fyi data as of mid-2026, L3 packages start around $195K total, the median US software engineer package sits near $335K, senior engineers land roughly between $330K and $510K, and staff (L6) runs about $510K to $680K. Bay Area medians run higher, around $404K. These numbers move quarterly and vary a lot by city, so check current data for your target level and location before you negotiate. Offers combine base, performance bonus, and RSUs vesting over four years, with the equity share growing quickly at higher levels.
How to spend four to eight weeks of prep
Four weeks is enough if your data structures are current. Take eight if you’re rusty, and closer to twelve if you’re starting cold. Whatever problem mix you’d use for a generic FAANG loop, double the graph weighting. Do at least two full timed sessions inside CodeSignal before the real assessment. For design, work the geospatial classics: design Uber itself, design nearby-place search, design live location sharing. Write your behavioral stories down and tag each with the Uber value it maps to, because retrofitting stories live in the room reads exactly like what it is.
Candidates who fail this loop mostly fail in predictable places. They run out of clock on CodeSignal because they never practiced timed, they hand-wave the sharding question in design, or they bring generic stories to a values-specific behavioral round. Each of those is fixable in a weekend. Uber tells you what it’s going to ask; the loop rewards people who listen.
Practice the behavioral round:
