Google Software Engineer Interview Guide

Google receives roughly 3M+ applications each year. The attention is hardly surprising. A Google software engineering offer can change the trajectory of a career.

If your interview is less than three weeks away, you can book 1-1 sessions with them to get personalized advice and prep much more efficiently. 

The standard interview loop for Google software engineers looks like this:

• Recruiter Phone Screen (30 minutes)
• Google Hiring Assessment (~60 minutes)
• Technical Phone Screen (1–2 rounds, 45-60 min each)
• Onsite (4-hour compressed block)
• Coding Rounds (2–3), 
• System Design (L4+)
• Googleyness & Leadership
• AI-Assisted Code Comprehension Round (2026 pilot, some US teams)
• Hiring Committee Review and Team Match (2-6 weeks)

Google evaluates every candidate across four attributes: 

1. General Cognitive Ability is measured against how you break down problems you haven't seen before. This is the most heavily weighted dimension 

2. Role-Related Knowledge covers data structures, algorithms, system design, and the specific technical skills for the role 

3. Leadership or what Google calls "emergent leadership" is stepping up when your expertise is needed, regardless of title and 

4. Googleyness, a characteristic officially described as a mix of intellectual humility, comfort with ambiguity, bias to action and collaborative instincts. This framework goes back to Laszlo Bock’s experience as Google's head of People Operations (which he discusses in his book Work Rules!)

Every round you face in the Google SWE interview feeds into these four evaluation dimensions. You can see how Google defines these hiring rubrics in their official re:Work guide. 

This is a non-technical 30 minute conversation with your recruiter. On this call they'll walk through your background and lock in your target level (L3, L4, or L5). The level decision here cascades through the interview loop, but please keep in mind that the final decision is up to the Hiring Committee which can and does down level based on the panel’s feedback. carries weight: if you push for L5 but your resume and screening conversation support L4, the hiring committee can downlevel or reject. 

Google recruitersThey will typically ask you questions like:

• What teams have you worked on? What have you built and what is the scale you've operated at?
• What are you looking for in your next role and why Google?
• What's your timeline? Are you actively interviewing elsewhere?

We’ve also heard from candidates that Google recruiters are quite willing to share information. You can find out a few details like which orgs have active headcount at your level or how long team matching has been taking, but you have to ask first - they won’t necessarily volunteer it themselves.

Added to the process in early 2025, the GHA is an asynchronous behavioral questionnaire with no coding or no design problems. Most candidates finish it within an hour or so. 

You're shown three workplace statements and asked to pick which is most like you and which is least. 

For example, you will be asked to pick from:

• I deliver work on time even when some details aren't fully polished.
• I dig into edge cases and edge cases of edge cases before I call something done.
• I loop in the right people early, even if it slows down the first draft.

This is how Google gets a clear idea of how you handle ambiguity, collaborate with your team, etc. 

The GHA carries less weight than live interview rounds, but the stakes aren't zero. 

If you fail this assessment, you are barred from reapplying for that role for 6-12 months. If you pass, it’s valid for 24 months across other Google applications too.

We suggest that you don't try to reverse-engineer an ideal answer or guess what Google wants. 

• 1 or 2 rounds of 45-60 minutes focused on DSA  (some L3 candidates have reported a shortened 35-minute version)
• Another SWE as the interviewer
• Conducted on Google Meet
• Frequently asked categories: Arrays/Strings, Hash Maps, Trees/Graphs, Two Pointers/Sliding Window, and Priority Queues

The interviewer in this round will be evaluating if you can clarify an ambiguous problem and articulate your approach to it. You'll code in a shared Google Doc with no syntax highlighting, autocomplete or compiler. You are expected to walk through edge cases and dry-run your code

If you are L4 and above, your interviewer could also engage in a short system design discussion toward the end. They will probably spend 10 minutes on something like "how would you design a URL shortener for 10K users." 

Here are some problems candidates have described being asked in their screens:

• How would you find the top K most frequent elements in a massive, continuous stream of data when memory is limited?
• Given a matrix representing a map with dynamic obstacles, how would you find the shortest path between two points if certain paths unlock only after specific conditions are met?
• How would you parse and evaluate a complex string that contains deeply nested brackets and custom operational rules?
• Given a long string, how do you find the longest continuous substring that contains at most K distinct characters using an optimal runtime?

Interviewers will be paying attention to how you receive hints and react to them. If you go quiet when you’re stuck, you give them very little to write down into your packet. You could also risk a weaker Googleyness signal if you treat their hints as interruption because this signal is also measuring how well you collaborate.

It is better to maintain a dialogue with your interviewer to ask questions if you’re stuck or want to clarify expectations. 

• 2 or 3 45-minute rounds, each with a different engineer. 
• Google Doc environment for coding 
• Problem difficulty: typically LeetCode Medium, with a Hard follow-up 
• 1 core problem per round + at least one extension 
• Some rounds can ask you to implement an entire class with multiple methods rather than solve a single function
  

Google compressed the onsite into a single 4-hour virtual block in 2025 (it used to be spread across two days). Additionally, they are pilot bringing back at least one in-person round as a response to concerns that a lot of candidates are using AI to hack the process, though some candidates now get at least one in-person round as a response to AI-assisted interview concerns.

At L4, producing a correct solution with some interviewer guidance is within the range. At L5, the expectation moves toward optimal solutions that you should drive independently. 

If you are a senior engineer (L5+), the evaluation moves to software craftsmanship from algorithmic correctness. If you are asked to implement an entire class rather than a single function, you will be scored on extensibility, clean interface design, separation of concerns, etc.

Here are questions that have appeared in onsite coding rounds, pulled from LeetCode discussion threads and Prepfully candidate reports:

• You're handed a set of file names. Return the length of the longest prefix shared by any two files.
• Find the sum of all contiguous subarrays in an integer array where adjacent elements differ by exactly 1.
• In a binary tree, find the longest path where every node has the same value. The path can start and end anywhere, it doesn't need to go through the root.
• You're given points with integer coordinates on a 2D plane. What's the area of the largest axis-aligned rectangle you can form using four of them as corners?
• Schedule a list of tasks, each with a type. Same-type tasks must be at least N intervals apart. Return the minimum total intervals. Follow-up: you now have M CPUs running in parallel, what's the new minimum?

Advice from Prepfully coaches: The smarter approach to these questions is usually to begin with the brute-force solution and then walk through each optimization. Skipping straight to the optimal approach leaves no fallback if it doesn't come together in 45 minutes. If that happens, you’re not giving the interviewer a lot to work with, especially to score you for problem solving. 

• 45-60 minutes
• Standard at L5 and above; increasingly common at L4 in 2026

The format is a design conversation built around open-ended prompts. You will be asked to design the architecture of a complex system that needs to scale to Google's global volume. In doing so, you will have to  isolate the hardest components, and deep-dive into specific engineering trade-offs. 

Your interviewer will expect you to lead the discussion. Generally speaking, you need to get the basics right in this round. Define the scope, identify which parts of the problem are worth prioritizing, describe the system at a high level before moving into architecture drawings, identify tradeoffs proactively, adjust to constraints or requirements presented by your interviewer, and talk through how you scale up to the level Google needs. 

Expectations for this round scale directly with your target level: L4 candidates are typically expected to stay within provided scope boundaries and go deep on at least one component, while L5 and L6 candidates must drive the scope conversation, go deeper across multiple components, and demonstrate mastery over operational health, including failure cascades, cross-region replication lag, and modern AI infrastructure constraints. 

As an L5/L6 engineer, read through Google’s foundational Spanner research paper. It is a clear look at how they handle global consistency, set up Paxos replication, and use hardware like TrueTime in production, etc. 

Sample questions we have seen Google ask that are relatively unique to Google:

• Design a globally distributed key-value store.
• Architect a real-time collaborative editor (like Google Docs)
• Design a proximity-based service (such as Google Maps)

The System Design format is somewhat standardized across the industry, so we will not go in-depth within this guide; please refer to our System Design guide for more details. 

Some tips for this round:

1. Don’t rush into architecture drawings before you establish requirements or constraints because then, your interviewer will likely interpret it as a memorized approach.
2. Commit to clear engineering choices. When asked a direct trade-off question like "Would you use SQL or NoSQL for this?", commit to a choice and defend it for the specific scenario. Vague answers will negatively impact your General Cognitive Ability and Role-Related Knowledge scores.

• One 45-minute round, usually with a hiring manager or a senior engineer 
• 4-5 behavioral questions with follow-ups 

Googleyness rubric between 2024 and 2026 has tightened. Because of this, interviewers now score the behavior and signs you present during the interview heavily over plain statements about values. 

How you handle pushback on a design choice or handle disagreement during the round is also part of the signal.

Google also began folding a technical project retrospective into this session for candidates in the pilot.

Instead of pure behavioral questions, the interviewer may ask you to walk through a system you've already built asking questions about the architecture decisions and trade-offs you made. They will then drill into the engineering choices the same way a system design interviewer would.

Business Insider reported all these updates citing an internal Google document.

Questions that Prepfully candidates have reported:

• Tell me about a time you made a significant technical decision based on incomplete data. 
• Walk me through a situation where someone on your team disagreed with your technical approach. 
• Describe a project where you realized midway that your initial design wasn't going to work. 
• Tell me about a time you had to influence a decision without any formal authority over the people involved.
• Give me an example of a piece of feedback you received that was hard to hear.

For behavioral questions, we recommend that you use the STAR+L framework (Situation, Task, Action, Result, + the X factorLearning) to structure your stories. The X factor at the end, "Learning" at the end, giving you a much sharper story for Google. 

As an engineer, you’ve probably had a Learning in your experience that more or less sounds like

• We rushed the launch and skipped documentation, which gave us a ton of tech debt later. Now I write a quick design doc for any complex feature so the context isn't lost.

or

• Looking back, we should’ve just used an off-the-shelf cache instead of building our own. Now I always validate whether writing custom infra is actually worth the overhead

This is the stuff that shows your interviewer you’re capable of intellectual humility, which is a really good signal for Googleyness.

Google is piloting a 60-minute technical interview focused on AI collaboration and debugging where Gemini is the AI assistant. This round takes place in a CoderPad interface configured with three panels: the File explorer, the code editor and the Gemini chat window.

This format replaces one of the traditional whiteboard or scratch-coding rounds in the SWE interview loop. Instead of writing from scratch, you're handed an existing codebase that has bugs and performance issues.

Gemini can analyze the provided context and generate text or code snippets but it can’t modify the files in your editor directly. 

The round typically follows a direct progression:

1. Understanding the code
2. Fixing the bugs and
3. Optimizing it

The interviewer will be evaluating AI fluency, output validation and core debugging. 

Prepfully’s coaches make it very clear that “AI fluency” is measured as your ability to “structure clear, targeted prompts to generate actionable solutions from the model”. Steer clear of open-ended prompts like "find all the bugs” and exercise your engineering judgment. 

After your onsite, each interviewer writes up their round independently and a vote on the Strong Hire to Strong No Hire scale. These packets reach the hiring committee which consists of 4-6 senior engineers from unrelated teams.

The committee has full authority to override panel recommendations.

Consistency in the score from your interviewers matters to them. Someone with a 4 and a 2 for score averages the same as someone with two 3s, but the committee reads that fluctuation as risk. 

Committee approval does not mean you have an offer. It means you're cleared to enter team match. Some candidates match in a week because a team was already waiting for someone with their exact profile but more commonly, it takes 2-6 weeks.

There have been cases where despite team matching calls, the candidate doesn’t get an offer. 

It's entirely possible that a long wait is more likely about headcount availability than about the quality of your packet. Sometimes, a really good packet can help candidates get in touch with teams that wouldn't otherwise engage. 

Verified 2026 median comp ranges for Google Software Engineer compensation are roughly:

• L3: $212,000
• L4: $311,000  
• L5 (senior): $418,000
• L6 (staff roles): $589,000.
• L7 (senior staff): $837,000

View the latest compensation for Google SWEs on Levels.fyi

Google Software Engineer Interview Guides:

• Google Software Engineer Technical Phone Screen 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
• Life at Google
• How We Hire at Google
• Google's approach to structured interviewing