Google Software Engineer Technical Phone Screen

The phone screen decides one thing: whether Google brings you in for a full onsite loop.

The bar is lower than the onsite, and a borderline result can lead to a second phone screen instead of a rejection. The problems themselves are usually familiar territory for the candidates who reach this stage. The environment is where many people get surprised.

You'll write code in a shared Google Doc with a Google engineer on the other side of the conversation. No syntax highlighting, no autocomplete, no compiler, and no way to run your code. Most engineers spend years building instincts around tools that catch mistakes, suggest completions, and help them move faster. The phone screen strips all of that away and leaves you with a problem, a blank document, and your ability to explain what you're thinking.

If your entire preparation has happened in an IDE, the first time that feels unusual should not be the day it counts.

The rest of this guide walks through the phone screen from beginning to end, including how Google scores the round, what generates signal in each part of the interview, recently reported questions, the 2026 Gemini code-comprehension pilot, and the preparation habits that seem to make the biggest difference.

Google uses the same broad evaluation framework in the phone screen that it uses during the onsite. The phone screen is shorter and carries a different consequence, but interviewers are looking at many of the same things.

Most candidates experience the round as a coding interview. Interviewers experience it slightly differently. By the time the session ends, they have formed opinions about how you communicate, how you reason through unfamiliar problems, the quality of the code you write, and how effectively you apply fundamental algorithms and data structures.

Google's scoring rubric is commonly described as a four-point scale across those areas. The exact internal labels are not publicly documented, but interview feedback consistently revolves around the same themes: communication, problem solving, coding ability, and algorithmic reasoning.

It is useful to know how interviewers typically talk about those scores in practice. A 4 is usually associated with a candidate who solves the problem cleanly, communicates clearly throughout the discussion, and leaves enough room for deeper follow-ups. A 3 generally reflects a successful interview with some imperfections. A 2 often indicates a solution that required substantial guidance or never fully came together. A 1 reflects an interview where meaningful progress was difficult to establish.

Those descriptions come from Prepfully interviewers who have conducted Google software engineering interviews. Put differently, this is what it sounds like when a Google interviewer explains how they think about candidate performance once the interview is over.

The opening minute or two of this round usually contain some combination of clarifying questions, assumptions, constraints, expected outputs, and a rough description of the approach. None of that is particularly remarkable, most experienced engineers do some version of it every day.

What is remarkable is how much of the Communication signal in the round gets generated there.

Candidates sometimes treat those first couple of minutes as overhead standing between them and the problem. Interviewers often experience them differently. By the time the first line of code appears, one candidate has already given the interviewer a page of notes about how they approach unfamiliar problems, while another has given them almost nothing to write down.

Candidates who explain why they're choosing a particular approach, why they're abandoning another one, or what tradeoff they're making at a particular point in the solution make the interview easier to evaluate. Candidates who keep most of that reasoning to themselves often create the strange situation where the code is visible but the thinking behind it is not.

Phone screen questions usually sit around LeetCode medium difficulty, but candidates often spend too much time trying to calibrate the difficulty and not enough time paying attention to how the problem evolves.

Google interviewers frequently write their own questions. A problem may resemble something you've seen before, right up until the moment it stops resembling it. A familiar array problem acquires a memory constraint. A straightforward graph question grows an additional requirement. A solution that looked complete five minutes ago suddenly has to operate under a different set of assumptions.

That is one reason memorisation has a shorter shelf life here than many candidates expect.

Complexity analysis appears unusually early in many Google interviews. Candidates who arrive at an approach often state the time and space complexity before they begin implementing it, partly because complexity is one of the ways interviewers understand whether someone sees the broader shape of the problem before getting lost in the details. The conversation is often less about calculating complexity than about understanding what level of efficiency the problem can reasonably support.

Data structures play a similar role. Many questions reveal their preferred solution surprisingly early if you pay attention to the operations being repeated. Frequent lookups tend to point toward a hash map. Repeated membership checks often suggest a set. Problems that naturally break into smaller versions of themselves frequently become simpler once recursion enters the discussion. Interviewers are usually interested in whether candidates recognise those patterns from the problem in front of them. It’s never about memorising the solution to it.

Coding ability and problem solving are scored separately, but they often become difficult to separate in practice. A clean solution written around the right structure tends to make both easier to evaluate.

The following two questions show a pattern that comes up repeatedly in Google phone screens. These two examples show how interviewers commonly extend a solution once the baseline approach is established.

Find all pairs in an array that sum to a target value.

The brute force solution checks every pair and runs in O(n²) time. Most candidates quickly arrive at the more practical approach: a single pass through the array while storing previously seen values in a hash set. For each element, check whether target - current already exists. The result is O(n) time and O(n) space, and for the original problem that is usually enough.

The follow-up often changes one of the assumptions that made the solution attractive in the first place.

What if the array is too large to fit in memory?

The hash set approach depends on fast in-memory lookups. Once memory becomes the constraint, the conversation shifts. A common direction is an external merge sort followed by a two-pointer scan from opposite ends of the sorted data. The complexity discussion starts revolving around disk access patterns, streaming reads, and how much data can be processed without loading everything into RAM at once.

What makes this follow-up interesting is that it isn't really asking for a different algorithm. It is asking whether you recognise which assumption the original solution depended on and how the design changes once that assumption disappears.

Determine whether a linked list has a cycle.

The standard solution uses Floyd's cycle detection algorithm. One pointer advances one node at a time, another advances two nodes at a time, and if a cycle exists they eventually meet. The solution runs in O(n) time and O(1) space.

Many candidates arrive there without much difficulty.

The follow-up is where the discussion usually becomes more interesting.

Find the node where the cycle begins.

The extension rewards understanding more than memorisation. After the two pointers meet, one pointer returns to the head while the other remains at the meeting point. Advancing both pointers one step at a time causes them to meet again at the start of the cycle.

Candidates who understand why Floyd's algorithm works often reason their way to this extension even if they have never seen it before. Candidates who memorised the technique as a standalone trick usually have a much harder time extending it.

That pattern shows up repeatedly in Google interviews. The first solution establishes a baseline. The follow-up explores how well the underlying idea survives once the problem becomes slightly more demanding.

Most engineers reading this already know how to review their own work. The reason this section exists is not because edge cases are a novel concept. It's because a surprising number of candidates mentally finish the interview the moment they arrive at a working solution.

The interviewer usually doesn't.

The last few minutes are often spent doing the things good engineers do anyway: walking through an example, checking assumptions, thinking about boundary conditions, and looking for places where the implementation and the intended behaviour have drifted apart. The difference is that, in an interview, those habits are visible.

Most of the time there is nothing dramatic waiting to be discovered. Occasionally there is an off-by-one error, a missing edge case, or an assumption that looked reasonable twenty minutes earlier and looks less convincing now. Finding one of those issues yourself is usually a much better outcome than leaving it for the interviewer to find thirty seconds later.

In May 2026, reporting from Business Insider and Entrepreneur, confirmed by a Google spokesperson, described a pilot interview format for junior and mid-level software engineering roles on select US teams. The pilot replaces one traditional coding round with an open-ended code comprehension round and allows candidates to use Gemini during the interview.

The format shifts the focus from building something from scratch to understanding something that already exists. Candidates are given a codebase to read, debug, and improve while explaining their decisions along the way. The discussion is less about arriving at an algorithm and more about building an accurate mental model of unfamiliar code, identifying what is broken, and deciding what should happen next.

Part of the evaluation includes how candidates work with the model itself. Can you ask useful questions? Can you recognise when the answer is incomplete? Can you spot when the model sounds confident but is heading in the wrong direction? Anyone who has spent time with modern coding assistants will recognise the skill being tested.

What's interesting about the pilot is that it aligns much more closely with how many engineers already spend their day. Most production work involves understanding code that somebody else wrote, investigating behaviour that was not anticipated, and making changes to systems that already exist. The classic coding interview starts with a blank page. This format starts with a codebase.

The traditional coding round remains the standard experience for most candidates today, so the rest of this guide reflects the process most people will encounter. The pilot is worth paying attention to because it offers a useful hint about where software engineering interviews may be heading and what skills companies are becoming more interested in evaluating directly.

• Find all pairs in an array that sum to a target value. (extends into an out-of-memory constraint, worked above)
• Determine whether a linked list has a cycle. (follow-up: find the node where the cycle starts)
• Reverse a linked list in place. (common opener, used to establish baseline fluency before a harder problem)
• Check whether three given binary trees are identical.
• Find the longest sequence in a binary tree where each node equals the next.
• Find the longest increasing subarray. (follow-up: if you may replace one element, how does the answer change)
• Convert a sorted array into a height-balanced binary search tree.
• Find a missing element in a sorted array using binary search. (follow-up: what if more than one element is missing)
• Find the longest increasing path in a grid, horizontal and vertical moves only. (grid traversal that extends into a graph problem with memoisation)
• Find the longest palindromic substring in a given string.

Most software engineering interview preparation looks broadly the same. Study data structures and algorithms, solve problems consistently, review common patterns, and get enough repetitions that the mechanics stop consuming mental energy. There is no need to repeat all of that here.

The phone screen introduces a few conditions that candidates often underestimate until they experience them.

The first is the environment itself. Writing code in a Google Doc feels like a small adjustment when you read about it and a much larger one when you experience it. There is no syntax highlighting, no autocomplete, no compiler, and no way to run your code. Most engineers have spent years building instincts around tools that catch mistakes early. The easiest way to remove that variable from the interview is to remove it from your preparation. For the final week or two before the screen, solve every practice problem in a Google Doc and get comfortable holding the entire solution in your head.

The second is the follow-up. Many candidates prepare for the initial problem and treat the follow-up as something that happens if there is time left. Google interviewers often treat it as part of the interview from the beginning. Once you solve a problem, spend another ten minutes changing the assumptions underneath it. What happens if the input becomes a stream? What happens if memory becomes constrained? What happens if a property the solution depends on is no longer true? A surprising amount of preparation stops at the first working solution even though many Google interviews do not.

Most candidates practice until they can solve a problem. Google interviews often continue past that point. During preparation, it can be useful to spend as much time discussing why a solution works, where it breaks, and how it changes under new constraints as you spend implementing it. The implementation is usually the part people practice naturally. The discussion often isn't.

Communication deserves practice of its own. Not because engineers do not know how to explain their thinking, but because explaining it continuously while solving a problem is a separate skill. Get into the habit of stating your approach before you start coding, explaining why you are choosing one direction over another, and talking through tradeoffs as they appear. By the time the interview arrives, it should feel automatic.

One habit that comes up repeatedly in Google interviewer feedback is stating complexity before implementation rather than after it. Many candidates solve the problem, finish coding, and only discuss complexity when prompted. The stronger interviews often make that decision much earlier. Once an approach has been chosen, the candidate already has a rough idea of the time and space complexity they are targeting and whether the solution is likely to survive follow-up constraints.

Pacing is another area where preparation and interview performance often diverge. It is easy to spend thirty minutes chasing the perfect solution when practicing alone because there is no penalty for doing so. In a phone screen, time spent on one problem is time unavailable elsewhere. Giving yourself a hard time limit during practice is often a more useful habit than solving a larger number of questions.

Finally, do the thing most engineers already do at work and review your own solution before declaring it finished. Walk through an example. Check an edge case. Revisit an assumption. The last few minutes of the interview are still part of the interview.

If you are already solving medium-level problems comfortably, the highest-leverage preparation is often not another fifty problems. It is reducing surprises. The Google Doc should not feel unusual. Explaining your thinking should not feel unusual. A follow-up constraint should not feel unusual. By the time the interview arrives, as many parts of the environment as possible should feel familiar.

The challenge with all of these habits is that they are difficult to evaluate on your own. Most people can tell whether a solution works. It is much harder to tell whether you communicated enough, spent too long in one part of the problem, explained a tradeoff clearly, or missed opportunities to generate signal elsewhere in the interview.

A second phone screen is usually better news than you'd assume.

Many people interpret it as a near miss. In practice, it often means Google saw enough positive signal to continue investing time in the process but not enough signal to make a confident decision from a single interview.

A rejection usually means the interviewer felt they had enough information. A second screen means Google wants more.

That distinction is worth keeping in mind because candidates often respond by completely changing their preparation. They switch topics, rebuild their study plan, or spend days trying to work out what happened in the first interview.

Most of the time, the more useful exercise is reviewing the parts of the interview where the signal may have been incomplete. Perhaps the solution arrived late, a follow-up exposed a gap in the original approach, or there was simply not enough time left in the interview for the discussion to develop.

The second screen is usually a continuation of the first one, and many candidates who receive a second screen go on to clear it.

Many candidates treat the first screen as the real interview. In hindsight, it's often the most expensive practice run they'll ever get. The goal is to make sure the second one benefits from everything the first one taught you.

Prepfully Google Software Engineer Interview Guides:

• Google Software Engineer Interview Guide
• Google Software Engineer Coding Interview Guide
• Google Software Engineer System Design Interview Guide
• Google Googleyness and Leadership Interview Guide
• Google Software Engineer Interview Question Bank
• Google Software Engineer Mock Interview Coaches
• Mock Interviews: Google Job Interview Success

Related interview guides:

• Meta Software Engineer Interview Guide
• Amazon Software Engineer Interview Guide
• Netflix Software Engineer Interview Guide
• Spotify Software Engineer Interview Guide

Google resources:

• Google Careers
• How We Hire at Google
• Google's approach to structured interviewing