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 in the loop

Uber's full software engineer interview, as described in interviewing.io's Uber guide and corroborated by recent LeetCode Discuss reports, 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 ask questions mid-problem, push back on your approach, and suggest directions. They want to see how you think when someone else is in the room, not how fast you produce a binary tree traversal in silence. 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, CodeSignal's interview product lets both sides run code and add new test cases on the spot during the session. interviewing.io's Uber guide is explicit: you are expected to "write fully compilable code" and "run test cases." Pseudocode is a fail signal here.

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 often spends a few minutes on past work. Exponent's Uber guide notes that senior phone screens "may also include questions about your past work experience, particularly on the design and/or architecture of the project." Expect questions like "walk me through a scaling decision you made on your last service, and what you'd do differently now." Short. Designed to separate engineers who have shipped from engineers who have 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 (sourced from LeetCode Discuss and interviewexperiences.in):

Merge overlapping intervals (see Merge Intervals Problems)
Nearest k drivers to a location, given a stream of pickup requests (min-heap, see Top-K Heap Pattern)
Number of Islands II variant: process a stream of addLand(r, c) ops on a 2D grid and report the live island count after each op (Union-Find with union-by-rank, see Path Compression Union-Find)
Minimum number of characters to append to a string so it becomes a palindrome (KMP failure-function trick on s + "#" + reverse(s))
Implement a Counter class with put(n), count(n), and countAll() over a 5-minute rolling window, then discuss unit tests and production concerns
Longest substring with at most K distinct characters (Sliding Window)

Here's the shape of the min-heap "nearest k drivers" pattern, since it shows up roughly every other screen:

import heapq

def nearest_k_drivers(drivers, pickup, k):
    def dist_sq(d):
        return (d.x - pickup.x) ** 2 + (d.y - pickup.y) ** 2

    heap = []
    for d in drivers:
        heapq.heappush(heap, (-dist_sq(d), d))
        if len(heap) > k:
            heapq.heappop(heap)
    return [d for _, d in heap]

Max-heap of size k, negated distances, evict the worst each push. O(n log k) time, O(k) space. Squared distance avoids the square root since the ordering is the same. Stating both of those out loud is the kind of fluency Uber scores on.

The tricky part isn't the algorithms. It's the story wrapper. Uber engineers dress up standard DSA in domain clothing. A driver grid is a 2D matrix. A surge zone is a connected component. A route between two pins is a weighted shortest path. The algorithm is textbook. The framing can cost you two minutes of confusion before you spot the pattern underneath, especially if you only ever drilled the abstract version.

The four buckets Uber is actually scoring

Uber doesn't publish its full internal rubric, but the categories reported across interviewing.io, Exponent's guide, and recent candidate write-ups land in roughly the same four buckets: problem solving, engineering fundamentals (code quality plus complexity), communication, and ownership or collaboration.

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, and so does showing you arrived there through logic rather than typing variations until something compiled. One useful datapoint from interviewing.io's 100K-interview study: successful candidates first run their code at about 27% of the way into the interview, vs 23.9% for unsuccessful ones. Translation: think a little longer before you sprint into typing.

Engineering fundamentals. Readable code, named variables, complexity you can state without being asked, awareness of the tradeoffs against the alternative approach. Uber does not want hand-waving on complexity. "It's probably O(n) or something" is not the move. State it as part of the solution, not as a footnote when prompted.

Communication. This is where phone screens are won or lost more often than people expect. Most candidates know this in theory and then go silent for four minutes the moment they hit a hard part. The same interviewing.io study found that a candidate scoring 4-4-2 (strong code and problem-solving, weak comms) advances about 96% of the time, while one scoring 3-3-4 gets rejected 3x more often. Translation: silence won't sink you if your code is excellent, but a steady stream of narration is the cheapest way to add evidence the interviewer can actually write down. "I'm thinking about whether a hash map works here" beats five minutes of silent perfect code on the rubric.

Ownership. Catch your own bugs before the interviewer points them out. Run your code against an example before saying you're done. Suggest improvements without being asked. This bucket rewards engineers who treat the problem like something they actually own, not a homework drop-off.

Interviewers score each bucket separately and submit written feedback. A weak score on one bucket can be offset by strength elsewhere, but a complete blank on any of them 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.