Google Technical Phone Screen: Format, Rubric, and How to Pass
- Google technical phone screen is a 45-60 min live coding session in a plain Google Doc with no IDE, syntax highlighting, or autocomplete
- Four scored dimensions (Algorithms, Coding, Communication, Problem-solving) are all required; a correct solution written in silence still produces a No Hire
- Coachability is a scored signal: taking hints gracefully and explaining the new direction is what a score-4 Problem-solving write-up documents
- Arrays, strings, trees, graphs, and hash maps dominate; target LeetCode mediums solved in under 25 minutes while narrating out loud
- Practice in a plain Google Doc with a 45-minute timer before the interview; the gap between IDE solving and plain-text spoken performance is larger than most candidates expect
- After a working solution, proactively offer the optimized approach and its complexity tradeoff to score Algorithms and Communication simultaneously
More candidates fail at the Google phone screen than at the onsite. That's the part nobody tells you. Most people treat it like a warmup lap, a polite formality before the real event. Then they get a No Hire on a problem they fully knew how to solve, and spend a week re-reading their solution going, "but that was right."
This is the first gate where a Google engineer decides whether your file moves forward, and it uses a rubric that rewards a behavior most candidates have never practiced.
How the Google Technical Phone Screen Fits Into the Process
Google's standard pipeline:
| Stage | What it is | Notes |
|---|---|---|
| Resume screen | Recruiter review | Automated + human |
| Online Assessment | 2 coding problems, timed | ~70 min, proctored |
| Technical Phone Screen | Live coding with an engineer | 45-60 min, this guide |
| Virtual onsite | 4-5 rounds in one day | Algorithms, system design, behavioral |
| Hiring committee | Decision review | No new interviews |
Referrals and experienced hires sometimes skip the OA and land directly at the phone screen. Regardless of how you arrive, this is the first round where a Google engineer is in the room watching you think.
What Actually Happens
The interview runs over Google Meet. Your interviewer is a software engineer, not a recruiter. They paste a problem into a shared Google Doc. You write your solution there.
No IDE. No syntax highlighting. No autocomplete. No compiler. No tab key.
Well, technically tab works. It inserts a tab character at the start of every line because this is a word processor and the cursor is in the wrong mode. You will discover this 10 minutes into your first practice session, alone, at your desk, furious. Better to get it out of the way now.
One problem, sometimes two. The more common format is one problem with a significant follow-up. Expect 20 to 50 lines of code total. The recruiter will ask which language you prefer beforehand. Python and Java are the most common choices. Google accepts any mainstream language. Whitespace-sensitive languages are especially fun in Google Docs. Choose Python if you enjoy chaos.
What Topics Show Up
The phone screen leans on medium-difficulty problems. Based on candidate reports:
- Arrays and strings: Nearly every phone screen. Sliding window, two pointers, prefix sums, in-place manipulation.
- Trees and graphs: BFS and DFS appear often, especially where traversal order matters.
- Hash maps and sets: Frequently the core of the optimal solution even when hashing is not the stated topic.
- Linked lists: Less common but present. Fast-slow pointer patterns show up.
- Dynamic programming: Less frequent than at onsite, but basic 1D DP does appear.
What you will not see at this stage: Dijkstra, Floyd-Warshall, segment trees, obscure math. Those live at the onsite. If you are stressing about suffix trees at the phone screen stage, you have optimized for the wrong thing.
The right calibration: if you can solve LeetCode mediums in under 25 minutes while explaining your thinking out loud, you are ready.
Four Dimensions, All Required
Google scores coding rounds on four dimensions, 1 to 4:
| Dimension | What it measures |
|---|---|
| Algorithms | Choice of data structures, optimization, complexity analysis |
| Coding | Clean implementation, edge cases, correct syntax |
| Communication | Clarity of explanation, responsiveness to hints, narration |
| Problem-solving | How you decompose the problem, how you recover from wrong turns |
These scores are not averaged. A brilliant solution written in complete silence can still produce a No Hire if the Communication and Problem-solving boxes are empty in the write-up. The hiring committee reads evidence, not just the headline recommendation. Your interviewer goes back to their desk and fills out a form. If you gave them nothing to write, the form is empty.
What the Phone Screen Is Actually Testing
Most candidates miss this. The phone screen is not primarily testing whether you can solve the problem. It is testing whether you solve problems the way Google engineers do.
A score-4 on Communication means: the candidate identified constraints before coding, articulated a brute-force approach and then improved it, explained the tradeoff, and narrated the implementation. That behavior is what produces a documentable write-up.
A candidate who reads the problem, pauses for two minutes in total silence, then writes a perfectly correct solution gives the interviewer nothing to document. The interviewer cannot write "candidate demonstrated strong problem decomposition" because they did not see it. The correct solution is in the doc. It just arrived out of nowhere, like magic, undocumentable. Congrats on the correct answer and the empty write-up.
Think of it this way: you are the narrator of a nature documentary, except the subject is your own brain solving a coding problem. The interviewer is the viewer at home. If you go silent, the show ends.
The second thing being tested is coachability. When the interviewer pushes back or offers a hint, your response is a scored signal. Defending a wrong approach after a redirect is one of the fastest paths to a No Hire. "I think my approach is correct because..." followed by three minutes of increasingly wrong reasoning is a thing that happens to real candidates. Incorporating feedback cleanly, explaining why the new direction is better, is what score-4 Problem-solving looks like.
Six Mistakes That Kill Candidates Who Know the Material
1. Jumping straight to code. Reading the problem and immediately typing is the most common failure mode. Take two minutes to restate the problem, ask at least one clarifying question, and state your constraints out loud before writing a single line. See what clarifying questions to ask first.
2. Going silent when stuck. If you hit a wall, narrate it. "I'm thinking about whether I need to preserve order here, which is why I reached for a hash map, but now I'm not sure that handles duplicates." That sentence gives the interviewer something to respond to. Silence gives them nothing, and nothing is a No Hire. More on this at coding interview communication.
3. Not practicing in Google Docs. This sounds trivial until you are 20 minutes in and realize auto-correct just changed null to Null and you have been coding in a language that does not exist. No syntax highlighting means you will miss unmatched parentheses you would catch instantly with color. Practice in plain text before the interview, at least a few sessions. It feels terrible. That is the point.
4. Stopping after the first correct solution. Solve the problem in 20 minutes and then sit quietly, and you have left half the rubric empty. After you have a working solution, say: "This runs in O(n²) because of the nested loop. There might be a way to bring it to O(n) with a hash map. Want me to walk through that?" That one sentence scores Algorithms, Communication, and Problem-solving simultaneously. It costs you nothing to say it.
5. Shaky complexity analysis. You will be asked "what is the time and space complexity?" at the end, almost without exception. It is basically a closing ritual at this point. If you cannot walk through the derivation, you lose points on Algorithms. Derive complexity for every solution you write during prep, every time, until it is automatic.
6. Treating hints as failure. "Is there a more efficient approach?" is not the interviewer telling you that you failed. It is a coachability probe. Taking it gracefully and incorporating it is exactly what a score-4 write-up describes. Read more on how to handle coding interview hints.
How to Prepare
Four to six weeks out: Focus on LeetCode mediums across the core pattern families. Sliding window, two pointers, tree DFS/BFS, graph BFS, hash map problems, basic 1D DP. Get fluent in these before adding anything else. Fluency means you recognize the pattern within a minute of reading the problem, not that you've seen that exact problem before.
Two weeks out: Start practicing under timed, spoken conditions. Set a 45-minute timer, open a Google Doc, solve one problem out loud with no IDE. Most candidates skip this step entirely. It feels awkward. You feel like an idiot talking to your laptop. That awkwardness is exactly what you need to get past before the interview, not during it.
One week out: Run two or three mock interviews with voice feedback. The distance between solving correctly in your IDE and performing under time pressure while speaking clearly is larger than most people expect. SpaceComplexity runs voice-based mock interviews in this exact format, with rubric-aligned feedback on all four dimensions so you know what your write-up would actually say.
Day before: No new material. Review one or two already-solved problems. Confirm your Google Meet login, stable internet, headphones, and quiet space. Open the actual invite link in an incognito window and check audio and video before you need them. The last thing you want is to spend the first three minutes of the interview explaining to Google that your microphone works, actually, you just need to update Chrome.
Read Your Own Code, Every Time
There is no compiler in the Google Doc. The wrong response is to memorize syntax. The right response is to build the habit of reading your code top to bottom before you say you are done.
After writing, pause. Restart from line one. Trace through with a small example. Catch the off-by-one. Catch the empty input case. Catch the uninitialized variable. This habit is worth more than any amount of syntax memorization, and it gives you one more thing to narrate: "Let me just trace through this with the example to make sure." More points. Free.
What Happens After
Results come back within a few days via your recruiter. You will not receive the interviewer's write-up, which is probably for the best.
If you pass, the recruiter schedules the virtual onsite: four to five rounds in one day covering algorithms, system design, and behavioral. The rubric is the same. Everything that works at the phone screen works there too. For the full picture, see the Google software engineer interview guide.
If you do not pass, most candidates can re-apply after six months to a year. The phone screen is one gate. It is not a verdict on your ability as an engineer. It is a test of a specific set of behaviors that are very much learnable, and the fact that you are reading this means you are already ahead of the people who found out the hard way.