How to Pass the Google Technical Phone Screen in 45 Minutes

Passing the Google technical phone screen comes down to 7 steps: rehearse in a plain doc, clarify the problem, talk through approaches, write complete code, state complexity, test by hand, and handle follow-ups. Each one maps to something the interviewer writes down during a session that Google's own recruiting guidance describes as about 45 minutes long. Follow the plan for 2 to 3 weeks and you should be able to finish a medium problem, with tests and complexity, inside that window. This guide is for software engineers with a Google screen on the calendar. It is not a data structures course, so if arrays, hash maps, trees and graphs are still new to you, learn those first.

What you need before you start

• One language you know well enough to write without autocomplete, including its standard library for strings, maps, sets, heaps and sorting.
• Working knowledge of core data structures and Big-O analysis.
• A blank Google Doc and a 45-minute timer for every practice session.
• About 1 hour a day for 2 to 3 weeks, plus at least two timed sessions with another person watching.

Step 1: Rehearse coding in a plain Google Doc

Do every practice problem in a shared document, not an IDE: no syntax highlighting, no compiler, no run button. Before the real call, open Tools, then Preferences, and turn off automatic capitalization, smart quotes, link detection, list detection and automatic substitution, then switch to a monospace font.

Why it matters: Google's recruiting guidance, as summarized by a 2014 Google intern, says remote rounds use a video chat and a collaborative document. Unchanged defaults fight you: Code Fellows notes that auto-capitalization turns var into Var and smart quotes break string literals.

Example: Before: an editor closes brackets for you and you run code after every edit. After: you type into a blank doc on a timer, read the code aloud once, and only then check it against a judge.

Common mistake: Only discovering on the day that the doc capitalized the first word of every line.

Step 2: Clarify the problem before you type code

Restate the question in your own words, then ask about input size, data types, duplicates, empty input and what to return when there is no answer. Write the answers as a comment at the top of the doc.

Why it matters: Google's guidance says it is "okay and encouraged to question your interviewer" and to verbally check any assumption. Input size also tells you the target complexity: the USACO Guide's reference table puts the ceiling at roughly O(n log n) for n up to 5 x 10^5 and O(n^2) for n up to about 7,500.

Example:

// Problem: return the k most frequent words
// Clarified:
// - n up to 10^5 words, lowercase ASCII only
// - ties broken alphabetically
// - k is always between 1 and the number of distinct words
// - return a list, order: most frequent first

Common mistake: Asking ten questions you could answer yourself. Ask the two or three that change the algorithm.

Step 3: Talk through a brute force, then an improvement

Say the simplest correct approach and its complexity out loud, then explain the bottleneck and how a better data structure removes it. Ask the interviewer whether they are happy for you to code the improved version.

Why it matters: Communication is graded on its own. In interviewing.io's study of FAANG phone screens, interviewers rated candidates on technical ability, problem solving and communication separately. Google's guidance is blunt: "Continue talking!"

Example wording: "Brute force: count every word, then sort all distinct words by count. That is O(n + m log m) where m is the number of distinct words. If m is large and k is small, I can keep a min-heap of size k instead and get O(n + m log k). Shall I go with the heap?"

Common mistake: Going silent for three minutes while thinking. Narrate even half-formed ideas.

Step 4: Write complete, readable code in one language

Write real, compilable code, not pseudocode. Use clear names, small helper functions, and the standard library, and keep indentation consistent because the doc will not do it for you.

Why it matters: Former Google engineer Steve Yegge's widely cited prep post says you should "know at least one programming language really well" and that you will be expected to write code. In a doc, fluency is the only autocomplete you have.

Example:

from collections import Counter
import heapq

def top_k_words(words, k):
    counts = Counter(words)
    # heapq.nsmallest with key (-count, word) handles the tie rule
    return heapq.nsmallest(k, counts.keys(),
                           key=lambda w: (-counts[w], w))

Common mistake: Switching languages mid-prep. Pick one at least two weeks out and stay with it.

Step 5: State time and space complexity without being asked

When the code is written, give time and space complexity in one sentence each, naming every variable you use (n words, m distinct words, k results).

Why it matters: Yegge's post puts it plainly: "If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired." Google's own guidance adds that you "must be able to know or approximate it well", even if no formal proof is needed.

Example wording: "Counting is O(n). Selecting the top k is O(m log k). Space is O(m) for the counter and O(k) for the heap, so O(m) overall."

Common mistake: Forgetting hidden costs, such as string slicing or list.pop(0), which the Python wiki lists as O(n).

Step 6: Test your code by hand with edge cases

Trace one normal example line by line, tracking variable values in a comment, then run through edge cases: empty input, one element, all ties, maximum size. Fix bugs you find and say what you changed.

Why it matters: There is no run button, so the interviewer watches you verify. Google's advice is to "Ensure it works by using examples. Try to find edge cases."

Example:

# words = ["a","b","a","c","b","a"], k = 2
# counts = {a:3, b:2, c:1}
# keys sorted by (-count, word): a(-3), b(-2), c(-1)
# result = ["a","b"]  correct
# edge: all ties ["x","y"], k=1 -> (-1,"x") sorts before (-1,"y") -> ["x"]  correct

Common mistake: Announcing "I think it works" without tracing a single input.

Step 7: Handle follow-ups by revisiting your constraints

Expect the interviewer to change one constraint: the data no longer fits in memory, words arrive as a stream, or k is huge. Restate the new constraint, say which part of your solution breaks, then adapt.

Why it matters: Google interviews are tightly sampled. Google's People Analytics team found that four interviews gave 86% accuracy in predicting a hire, so each round carries real weight. Follow-ups are where strong and borderline answers separate.

Example wording: "If words arrive as an unbounded stream, I cannot keep exact counts for every word in memory. I would either shard counts by hash across machines and merge each shard's top k, or accept approximate counts with a count-min sketch. Which direction would you like?"

Common mistake: Rewriting everything from scratch instead of changing the one piece the new constraint breaks.

A suggested 45-minute time budget

Minutes	Activity	Step
0 to 5	Introductions, read the problem	-
5 to 10	Clarify and agree on constraints	2
10 to 15	Brute force, then improved approach	3
15 to 30	Write the code	4
30 to 37	Complexity and hand testing	5, 6
37 to 45	Follow-up and your questions	7

This split is a planning guide, not an official Google rule. Practice finishing the first problem by minute 30 in case a second one follows.

How to know it worked

• Within 2 weeks, you solve unseen medium problems in a blank doc in 30 minutes or less, including tests, on at least 3 out of 4 attempts.
• You state complexity correctly for every solution without looking anything up.
• Your hand trace catches your own bug before the interviewer points it out.
• Practice with others pays off measurably: in interviewing.io's data on 158 Google applicants, predicted phone screen pass probability rose from 69% with 2 mock interviews to 76% with 3.

Troubleshooting

• If you freeze on the approach: solve a small example by hand, then describe what you did as an algorithm.
• If you run out of time while coding: spend less time on clarifying and brute force, and practice writing helper signatures first, then filling them in.
• If your code has many syntax slips: drill 20 minutes a day of blank-doc coding in your chosen language until the standard library is muscle memory.
• If the interviewer keeps hinting: stop, repeat the hint back in your own words, and ask whether you have understood it before you continue.

FAQ

How long is the Google technical phone screen?

Google's recruiting guidance describes technical interviews as about 45 minutes each, and remote rounds take place over video with a shared document. Plan for around 30 to 35 minutes of actual problem solving, because introductions and your own questions at the end take up the rest of the slot.

Do I code in a Google Doc or an IDE?

Google has long used a collaborative document for remote coding, with no compiler and no autocomplete. Your recruiter will confirm the exact tool before the call. Either way, practice in a plain doc so that missing editor features never surprise you, and turn off autocorrect settings in advance.

Can I use any programming language?

Generally yes. Pick the language you know best and can write without an IDE. Python, Java, C++ and JavaScript are all common choices. What matters is fluency with the standard library, because you will not be able to look things up during the screen.

What happens if I do not finish the problem?

An incomplete solution is not an automatic fail, but it weakens the signal. A clear brute force, a well-explained optimization and partially written code are better than a silent attempt at the perfect answer. Always state what you would do next if you had more time.

To recap: rehearse in a plain doc, clarify, talk through approaches, write complete code, state complexity, test by hand and adapt to follow-ups. The fastest way to check all seven under pressure is a timed rehearsal with someone who has run these interviews: book an anonymous coding mock interview with a FAANG-level engineer and get a scorecard plus a recording. For more company detail, read the Google interview guide, then sharpen your method with how to solve any coding interview question in 7 steps.