Uber Phone Screen Interview: What to Expect and How to Pass

One Uber engineer is about to watch you code for 45 minutes. They're taking notes the whole time. When it's done, they'll score you on four dimensions and write up feedback that either opens the onsite loop or closes the process entirely. There is no partial credit round.

That's the phone screen. One shot. Here's how to not blow it.

Where This Round Sits

Uber's full software engineer interview looks like this:

Stage	Format	Duration
Recruiter screen	Video/phone call	30-60 min
Online assessment (some roles)	CodeSignal, 4 problems	70-90 min
Technical phone screen	Live coding with engineer	45-60 min
Onsite loop	3-5 rounds	4-5 hours
Bar Raiser	Standalone round	45-60 min

The online assessment is not universal. Referrals and sourced candidates often skip it and go straight to the live screen. If you applied cold and haven't heard about an OA, just ask the recruiter.

The recruiter call before the technical screen is worth treating as actual prep. It covers your target level, which Uber org you're interested in (Rides, Eats, Freight, Core Platform), and the interview structure. Use it to confirm whether you'll face an OA or go straight to live coding.

What Actually Happens

The screen is 45-60 minutes on Zoom with a shared CodeSignal editor. One or two algorithmic problems. One Uber engineer on the other side, who is not just watching you type in silence.

Uber interviewers are interactive. They'll ask questions mid-problem, push back on your approach, and suggest directions. This is intentional. They want to see how you think when someone else is in the room, not just whether you can produce a working binary tree traversal. This is closer to pair programming than to a coding test.

Code actually runs. Unlike some phone screens where you sketch pseudocode and everyone pretends it's fine, Uber's CodeSignal setup supports live test cases. You write working code and verify it.

Follow-up questions are standard. Once you have a solution, expect the interviewer to ask about alternative approaches, edge cases you might have missed, or what happens when the constraints change by an order of magnitude. Build time for this into your mental model of the session. Candidates who sprint through implementation and have nothing left for follow-ups look like they memorized the solution, not like they understand it.

For senior roles (L5 and above), the interviewer may briefly probe how you've thought about technical tradeoffs in past production work. Not a full system design round. Just enough to see whether you've actually shipped software, or whether you've mostly shipped LeetCode solutions.

The Patterns That Show Up Most

The phone screen pulls from a predictable set of topics. Difficulty skews medium, harder for senior candidates.

High-frequency topics:

Arrays and strings
Graphs and grid traversal (Uber's business is literally routing, so expect domain-flavored framing)
Heaps and priority queues
Sliding window
Intervals
Union-Find
Tree traversal and tree DP for senior roles

Problems reported from recent screens:

Merge overlapping intervals
Nearest k drivers to a location (min-heap)
Number of Islands II variant (Union-Find, dynamic island merging)
Minimum appends to make a string a palindrome
String evaluation with recursive function calls

The tricky part isn't the algorithms. It's the story wrapper. Uber engineers dress up standard DSA in domain clothing: a driver grid, a surge pricing zone, a map region. The underlying algorithm is textbook, but the framing can cost you two minutes of confusion before you recognize the pattern underneath. If you've only ever drilled abstract versions, you'll spend precious time wondering whether this is a new problem type instead of just doing BFS.

The Four Things Uber Is Actually Scoring

Problem solving. Did you break the problem down deliberately? Did you recognize the pattern? Did you catch edge cases before the interviewer had to mention them? Getting the correct answer matters, but so does showing you arrived there through logic rather than through typing variations until something compiled.

Engineering fundamentals. Is your code readable? Can you state time and space complexity without being asked? Do you know the tradeoffs between your approach and the alternatives? Uber does not want hand-waving on complexity. "It's probably O(n) or something" is not the move.

Communication. This is where phone screens are won or lost more often than people expect. Most candidates know this in theory and then go completely silent for four minutes the moment they hit a hard part. If you go quiet during implementation, your communication score is dropping regardless of what your code does. Narrating "I'm thinking about whether a hash map works here" is worth more than five minutes of silent perfect code. The interviewer needs something to write down.

Ownership. Do you catch your own bugs before the interviewer has to point them out? Do you run your solution against an example before declaring done? Do you propose improvements without being asked? This dimension rewards candidates who treat the problem as something they're responsible for, not a task they're just trying to complete and hand back.

Interviewers score each dimension separately and submit written feedback. A weak score on one dimension can be offset by strength elsewhere, but a complete blank on any dimension is very hard to recover from.

Your Framework for the 45 Minutes

Run the same structure on every screen. It sounds rigid and it works.

The 45-minute Uber phone screen broken into five phases: clarify, approach, implement, optimize, and ask questions

Minutes 1-5: Understand the problem. Ask clarifying questions before touching the keyboard. What are the input bounds? Are there duplicates? What if the input is empty? Can values be negative? A candidate who starts coding at minute two without asking anything is already flagging a weak problem-solving score. The question is always underspecified. That's not a bug, it's the test.

Minutes 5-10: State your approach out loud. Describe the algorithm in plain language, estimate complexity, and check with the interviewer before you implement. If they redirect you here, follow them. That's valuable information, not a setback. Candidates who get redirected at minute seven and adapt gracefully score better than candidates who got the right approach immediately and talked past the interviewer the whole time.

Minutes 10-30: Implement. Clean code, descriptive variable names, no single-letter variables unless you're writing i in a for loop. Run your test cases in CodeSignal and verify the output. Keep narrating. Yes, the whole time. "I'm going to use a min-heap here because I need to pop the smallest element in log n time" is exactly what the interviewer is hoping to write down.

Minutes 30-40: Optimize and handle edge cases. Walk through at least two edge cases without being asked: empty input, single element, all duplicates, integer overflow, whatever applies. If you have a brute-force solution working, discuss what it would take to get to optimal. Don't wait for the interviewer to prompt this. That's the whole ownership dimension in action.

Minutes 40-45: Questions for the interviewer. Prepare two or three genuine questions about the role, the team, or the engineering culture. Candidates who ask nothing leave signal on the table. Candidates who ask "what do you like most about working at Uber" look like they found this question on a generic interview prep site, because they did.

What to Actually Practice

For the phone screen specifically:

Heap problems: k closest points, k most frequent elements, merge k sorted lists
Grid BFS/DFS: number of islands, rotting oranges, matrix region problems
Sliding window: longest substring without repeating characters, minimum window substring
Intervals: merge intervals, insert interval, meeting rooms
Two pointers: 3Sum, container with most water, trapping rain water

You do not need to grind 300 problems. The phone screen is one or two mediums. Knowing 40-50 patterns well and being able to explain your reasoning out loud is worth more than recognizing 200 solutions you can't articulate to a human being.

Most candidates massively underinvest in the narration habit. Set a timer, open a blank editor, and solve a medium problem while talking through every thought out loud. Keep going until it stops feeling like you're having a mental health episode. It will feel awkward at first. That's fine. The awkwardness goes away. If you can only solve problems in silence, you are not ready for Uber's format, regardless of how many problems you've done.

SpaceComplexity simulates exactly this: voice-based mock interviews with rubric-based feedback across the same four dimensions Uber scores. Running five or six sessions builds the narration habit faster than solo LeetCode practice ever will.

What Gets Phone Screens Killed

Starting to code without clarifying. The question is always underspecified on purpose. If you don't ask, you're either making assumptions the interviewer knows are wrong, or you miss a constraint that changes the whole approach. Either way, you've already handed them a weak problem-solving score.

Going silent during implementation. The interviewer is writing feedback while you code. Silence reads as "no evidence of strong communication." You can code in silence and solve the problem correctly and still walk away with a bad communication score. This happens more than people think.

Skipping complexity analysis. State it as part of your solution presentation, not as something you reveal when asked. If you wait to be asked, it looks like you didn't think about it until they reminded you.

Declaring done without testing. Run your code against at least one example before you say you're finished. Walk through an edge case. Uber treats self-testing as an explicit scoring criterion, not just good engineering hygiene.

Defending a wrong approach when redirected. If the interviewer pushes you in a different direction, go with them. Candidates who argue get a lower ownership score. The ability to take feedback gracefully and update your thinking quickly is exactly what the ownership dimension is measuring. The interviewer knows what the right answer is. They don't want to watch you debate it.

For more patterns that get candidates rejected even when their code is correct, see Coding Interview Red Flags.

A Prep Timeline

Weeks out	Focus
4-6 weeks	Pattern coverage: arrays, graphs, heaps, sliding window, intervals
2-3 weeks	Timed problem-solving (35-minute timer per problem, no hints)
1 week	Mock interviews with narration, edge case drills, complexity fluency
2-3 days	Light review of highest-frequency problems, rest

If you're coming back to DSA after a gap, add two to four weeks for the pattern-coverage phase. The phone screen isn't unreasonably hard, but it requires a kind of fluency you genuinely cannot fake under pressure. Recognizing a min-heap problem at 2am while relaxed is very different from recognizing it while someone is watching you and taking notes.

For a complete picture of the full Uber loop, see Uber Software Engineer Interview Guide. For the mechanics of communicating effectively during live coding, see Technical Interview Communication.