Uber Coding Interview Questions: what the 2026 loop really tests
Searching for Uber coding interview questions turns up a wall of tagged problems and little sense of the room. An Uber coding round is a 45-minute live working session with a distinctly practical, graph-heavy flavour — ordering dependencies, scheduling overlaps, searching a grid — because that is the shape of the problems Uber actually solves at scale. The interviewer cares that you reach a correct, efficient answer on a tight clock and can reason about what happens when the input is not a toy example but millions of trips a day.
This is a map of that loop for 2026 — the stages from the Uber phone screen through the onsite, the handful of coding interview patterns that account for most of the questions, and the follow-ups that separate a working answer from an offer. It is framed the way the round is framed: not "here are the exact questions" but "here is the pattern, here is the kind of problem it wears, and here is the probe that decides it." Read it as a prep plan, because the code is table stakes — the round is won on pace, graph fluency, and what you say when the interviewer asks "now it's millions of trips a day — what breaks?"
How the Uber coding loop runs (2026)
Uber's process is a loop of several rounds — phone screen, then an onsite of back-to-back coding and design rounds. In the modelled version, the phone screen runs 45 minutes at medium difficulty and the onsite coding round runs 45 minutes and leans hard. The interviewer is in the room (by voice), so performance is part of the grade: you narrate the plan before you type, handle the edge cases out loud, and answer the follow-up after every submission. The 45-minute clock means pace matters — and Uber's quiet signal is whether your solution would still hold up at the scale the company operates.
On a live Uber round the interviewer often pushes from the algorithm into scale. "Your course-schedule solution works. Now it's a dependency graph of ten million tasks updated in real time — what breaks first, and how would you adapt?" That scale-aware, graph-flavoured push — reasoning past the toy input — is what the Uber round is really testing, and the one a memorised solution can never rehearse.
The rounds on Zynter are modelled on how the Uber loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a 45-minute clock, real code that compiles and runs, a lean toward graphs and scheduling, and a follow-up after every submission.
What the interviewer is really testing
An Uber coding answer is read on the same four dimensions as any coding round. Problem solving — do you recognise the graph or interval structure hiding in the prompt and reach the right algorithm (BFS, topological sort, a sweep)? Communication — can you narrate your approach and your scale reasoning clearly? Technical execution — is the code correct and efficient, with the cycle and boundary cases handled? Time management — do you get a clean, correct answer inside the tight 45 minutes? Reading this guide teaches the patterns; it does not teach you to reason about scale while someone multiplies your input by a million.
The coding patterns Uber tests
You do not need five hundred problems; you need the handful of coding interview patterns that account for most of them, and Uber leans unusually hard on graphs. The table is the shortlist: the pattern, the kind of problem it shows up in, and the follow-up that decides the round.
| Pattern | Example problem type | The follow-up that decides it |
|---|---|---|
| Graphs (BFS / DFS) | Word ladder, word search II | "Is there a cycle or a disconnected node, and does your code handle it?" |
| Topological sort | Course schedule II, alien dictionary | "Where's the cycle check, and what order do you emit?" |
| Intervals / scheduling | Meeting rooms II | "What's your sort key, and how do you count peak overlap?" |
| Trees (BFS / DFS) | Binary tree right side view | "Recursion or a queue — what's the depth on a skewed tree?" |
| Backtracking | Word search, valid sudoku | "Where do you prune, and what's the worst-case branching factor?" |
| Strings / hashing | Word break | "What's your memo, and what's the cost at scale?" |
Graphs and topological sort: the Uber core
If one family decides an Uber onsite, it is graphs. Course schedule, alien dictionary and word ladder are all graph problems in disguise, and the question hiding inside most of them is "is there a cycle, and in what order do I process the nodes?" Have topological sort automatic.
from collections import deque
def topo_sort(num_nodes, edges):
graph = [[] for _ in range(num_nodes)]
indegree = [0] * num_nodes
for u, v in edges: # u must come before v
graph[u].append(v); indegree[v] += 1
q = deque(i for i in range(num_nodes) if indegree[i] == 0)
order = []
while q:
node = q.popleft(); order.append(node)
for nxt in graph[node]:
indegree[nxt] -= 1
if indegree[nxt] == 0:
q.append(nxt)
return order if len(order) == num_nodes else [] # shorter => a cycle
Narrate the cycle check — if the emitted order is shorter than the node count, there is a cycle — because that is the Uber follow-up before it lands.
Intervals and scheduling
Uber's other staple is scheduling overlaps, which fits a ride-and-logistics company. Keep the sort-then-sweep automatic.
# Meeting rooms II: sort by start, sweep a min-heap of end times
import heapq
intervals.sort(key=lambda x: x[0])
heap = []
for start, end in intervals:
if heap and heap[0] <= start: # a room freed up before this meeting
heapq.heappop(heap)
heapq.heappush(heap, end)
return len(heap) # rooms = peak concurrency
State the sort key and the sweep invariant — that is the follow-up for every interval problem.
What Uber looks for
Uber rewards the engineer who sees the graph in the problem and reasons about scale. Three signals matter most:
- Graph fluency. Recognise when a prompt is a graph or a scheduling problem and reach for BFS, topological sort or a sweep without hesitation.
- Scale-aware reasoning. When your solution works, say what happens at Uber scale — millions of events — and how you would adapt (streaming, sharding, an index). This is the signature Uber follow-up.
- Pace and clean code. The 45-minute clock rewards getting to a correct, efficient answer and stating its complexity, not a slow perfect one.
Say it plainly: I'd name the graph, reach for the right traversal, handle the cycle, state the complexity, and then say what I'd change at ten-million scale. That framing is what reads as an Uber hire.
Coding
Uber · Onsite coding · 45 min
Practise an Uber onsite coding round with follow-ups
How to prepare: a two-week plan
You do not need a hundred new problems in the last fortnight. You need the graph patterns automatic, the cycle check reflexive, and scale reasoning you can speak. Here is a realistic two-week pass for Uber coding interview prep.
- Days 1–4: Live in graphs — BFS, DFS, and especially topological sort (course schedule, alien dictionary) — until the cycle check is automatic. This is the highest-leverage block for Uber.
- Days 5–8: Intervals and scheduling (meeting rooms, merge intervals) and trees, stating each solution's complexity and edge cases.
- Days 9–11: Backtracking (word search, sudoku) and string problems (word break), narrating where you prune and your memo.
- Days 12–14: Full timed 45-minute rounds — narrate the plan, handle the cycle and boundary cases out loud, and answer a "now it's millions of events" follow-up on each. The goal is correct, efficient code on a tight clock.
The most common mistake in the last week is grinding problems in silence. By day 12 the bottleneck is not another algorithm — it is speaking your cycle check and your scale reasoning. If you want raw volume to drill the problems themselves, PipeCode is a sister platform built for exactly that; use it for reps, then come back here to rehearse out loud.
Coding
Uber · Phone screen · 45 min
Run the Uber phone screen out loud
The follow-ups that decide an Uber coding round
Scan the right-hand column of the pattern table and the questions rhyme. Master these five cross-cutting follow-ups and you are ready for prompts that are not even on the list.
- "Now it's millions of events — what breaks first?" → Name the cost (memory, a full rebuild, a quadratic scan) then the fix (streaming, sharding, an index). This is the defining Uber probe. (problem solving)
- "Is there a cycle, and how do you detect it?" → For any ordering problem, narrate the cycle check — a non-zero in-degree left over, or a grey node seen twice. (technical execution)
- "Why that traversal — BFS or DFS?" → Tie it to the goal: BFS for shortest path in an unweighted graph, DFS for connectivity or ordering. (communication)
- "What's the time and space complexity?" → Say it the moment your code runs, in terms of nodes and edges for a graph. (communication)
- "Handle the boundary — empty graph, single node, disconnected component." → Volunteer these before you are asked. (technical execution)
Each maps to the four-dimension debrief: reach the right algorithm (problem solving), narrate it and the scale clearly (communication), write correct efficient code (technical execution), and finish inside 45 minutes (time management). Reading this list teaches the answers; it does not teach you to deliver them while someone multiplies your input by a million — that only comes from saying them out loud.
Frequently asked questions
What coding questions does Uber ask in 2026?
Uber leans unusually hard on graphs — BFS, DFS and especially topological sort (course schedule, alien dictionary, word ladder) — plus intervals and scheduling (meeting rooms), trees, backtracking (word search, sudoku) and string problems, at medium-to-hard difficulty. The flavour is practical and scale-aware, fitting a logistics and real-time company, so expect follow-ups that push your toy solution toward millions of events. No one can hand you "the actual questions," and you should be wary of anyone who claims to; the rounds here are modelled on how the loop runs, not sourced from leaked prompts.
How long is the Uber coding interview?
In the modelled version, the Uber phone screen runs 45 minutes at medium difficulty and the onsite coding round runs 45 minutes and leans harder, within a larger onsite loop that also includes design and behavioural rounds. The 45-minute clock means pace matters: get to a correct, efficient answer, state its complexity, and leave room for the scale follow-up, rather than polishing a slow perfect solution.
Which patterns should I focus on for Uber?
Prioritise graphs above all — BFS, DFS and topological sort, with the cycle check automatic — because Uber leans on them more than most companies. Next, intervals and scheduling (meeting rooms, merge intervals), then trees, backtracking and string problems. Across all of them, practise the scale-aware follow-up: when your solution works, be ready to say what breaks at millions of events and how you would adapt, because that is the signature Uber probe.
What does Uber look for in a coding interview?
Graph fluency, scale-aware reasoning, and pace with clean code. Uber interviewers want to see you recognise the graph or scheduling structure in a prompt and reach for the right traversal without hesitation, handle the cycle and boundary cases, and — crucially — reason about what happens at the scale the company operates. When your solution works, saying how it would hold up (or what you would change) at millions of events is the move that distinguishes an Uber hire on a tight 45-minute clock.
Does Uber ask system design too?
For most roles, yes — the onsite loop typically includes a design round alongside the coding rounds, often with a real-time or logistics framing that fits Uber's products, plus behavioural. This guide focuses on the coding spine (phone screen and onsite coding) because that is what the modelled Zynter Uber rounds cover; prepare system design as a separate track to sit alongside it, especially given how often Uber coding follow-ups spill into scale.
How do I practise Uber coding questions out loud?
Reading a topological-sort solution is not the same as defending it — and reasoning about its scale — while an interviewer multiplies your input by a million. On Zynter, the Coding track runs live voice rounds modelled on the Uber loop — a real editor where your code runs against visible and hidden tests, and a voice interviewer that asks the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.
Practise it on Zynter
You can code the graph. The Uber round is won on the cycle check and the scale follow-up — out loud.
Pick an Uber coding round, write code that runs against real test cases, and defend it out loud to a voice interviewer that keeps asking "is there a cycle?" and "now it's millions of trips a day — what breaks?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including Uber phone screen and onsite coding rounds (Sep 2026).
Top comments (0)