Google Coding Interview: Process, Questions & How to Prepare

Google's coding interview is widely considered the highest bar in the industry. More engineers have written guides, Reddit posts, and Twitter threads about cracking it than any other company. Most of that advice is incomplete. Start by exploring Google's official careers page to understand their engineering roles and what they're looking for.

This guide is the complete picture: the process, what Googlers actually look for, the types of problems that appear, and a specific preparation plan calibrated to Google's bar.

The Google Interview Process

A standard Google software engineering loop consists of:

1. Recruiter screen (30 min) — background, motivation, experience overview
2. Technical phone screen (45 min) — 1 coding problem, sometimes 2 easy/medium
3. On-site / Virtual on-site loop — 4–5 rounds:
   • 2–3 coding rounds
   • 1 behavioral/Googleyness round
   • 1 system design round (SDE-2+) — see our system design questions for beginners to start prepping

All rounds are conducted with Google engineers — not contractors or HR. The interviewer submits a detailed feedback form and a hiring signal (Strongly recommend hire / Recommend hire / Lean no hire / Strongly no hire).

After the loop, a hiring committee reviews all feedback. The committee doesn't know the candidate's name, GPA, or school — only the interview feedback. The HC makes the final hire/no hire recommendation, which then goes to the VP for final approval.

This means: one bad interview round doesn't automatically fail you. The committee calibrates across all signals.

Interview Process Flow

flowchart TD
    A["Apply Online"] --> B["Recruiter Screen"]
    B --> C["Phone Screen"]
    C --> D{"Pass?"}
    D -->|"No"| E["Reapply in 6-12 months"]
    D -->|"Yes"| F["On-site Loop"]
    F --> G["Coding Round 1"]
    G --> H["Coding Round 2"]
    H --> I["Coding Round 3"]
    I --> J["Googleyness Round"]
    J --> K["System Design (L4+)"]
    K --> L["Hiring Committee Review (blind)"]
    L --> M{"HC Decision?"}
    M -->|"Hire"| N["VP Approval"]
    N --> O["Offer Extended"]
    M -->|"No Hire"| E

What Google's Bar Actually Means

Google uses a concept called "the bar" — a threshold of quality above which candidates get offers. The bar is calibrated to the question: "Would I be confident pairing with this person on a hard problem?"

In practice, this means:

• You need to arrive at an optimal or near-optimal solution without significant prompting
• Your code should be production-quality — well-named variables, no unnecessary edge cases left out, modular
• You should be able to derive and explain complexity without being asked
• Your communication should make your reasoning visible at every step

Google explicitly deprioritizes "got lucky on the exact problem" — interviewers are trained to probe deeper with follow-up questions to distinguish real understanding from pattern matching.

Types of Problems Google Asks

Google's problems tend to be:

• Graph and tree heavy: BFS, DFS, topological sort, lowest common ancestor
• Dynamic programming: both 1D and 2D; memoization vs. tabulation
• String manipulation: palindromes, anagrams, substring search
• Mathematical reasoning: number theory, combinatorics, probability
• Design-within-algorithm: problems that require combining data structures creatively

Google rarely asks pure array/hash map problems at the on-site level — those are more common in phone screens. On-site problems tend to require more creative combinations. This contrasts with Meta, which tends to use more standard LeetCode-style problems.

Problem topics to prioritize for Google (in order):

1. Trees and graphs (BFS, DFS, shortest path)
2. Dynamic programming (coin change, LCS, matrix problems)
3. String problems (sliding window, two pointers, trie-based)
4. Intervals (merge intervals, meeting rooms)
5. Math and bit manipulation

Algorithm Decision Tree

Use this flowchart to decide which algorithmic approach to use when you see a problem:

flowchart TD
    A["Read Problem"] --> B{"Shortest path in unweighted graph?"}
    B -->|"Yes"| C["BFS with Queue"]
    B -->|"No"| D{"Explore all paths or find cycles?"}
    D -->|"Yes"| E["DFS with Recursion/Stack"]
    D -->|"No"| F{"Optimal substructure + overlapping subproblems?"}
    F -->|"Yes"| G["Dynamic Programming"]
    F -->|"No"| H{"Process nodes level by level?"}
    H -->|"Yes"| I["Level-order Traversal"]
    H -->|"No"| J{"Find minimum cost/weight?"}
    J -->|"Yes"| K["Dijkstra / BFS with Weights"]
    J -->|"No"| L{"Array/string with two pointers?"}
    L -->|"Yes"| M["Two Pointers / Sliding Window"]
    L -->|"No"| N{"Handle ranges or intervals?"}
    N -->|"Yes"| O["Sort + Sweep Line"]
    N -->|"No"| P["Re-evaluate from start"]

8. None of the above?
   • → Think about problem constraints — re-evaluate from step 1

Code Examples: Google-Style Problems

Example 1: BFS — Rotting Oranges (Graph Traversal)

Problem: Given a 2D grid where 0 = empty, 1 = fresh orange, 2 = rotten orange, each minute all fresh oranges adjacent to a rotten one become rotten. Return the minimum minutes until no fresh orange remains.

from collections import deque

def oranges_rotting(grid: list[list[int]]) -> int:
    rows, cols = len(grid), len(grid[0])
    queue = deque()
    fresh = 0
    
    # Find all rotten oranges and count fresh ones
    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == 2:
                queue.append((r, c, 0))  # (row, col, time)
            elif grid[r][c] == 1:
                fresh += 1
    
    # BFS from all rotten oranges simultaneously
    directions = [(0, 1), (0, -1), (1, 0), (-1, 0)]
    max_time = 0
    
    while queue:
        r, c, time = queue.popleft()
        max_time = max(max_time, time)
        
        for dr, dc in directions:
            nr, nc = r + dr, c + dc
            if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == 1:
                grid[nr][nc] = 2
                fresh -= 1
                queue.append((nr, nc, time + 1))
    
    return max_time if fresh == 0 else -1

# Test case
grid = [
    [2, 1, 1],
    [1, 1, 0],
    [0, 1, 1]
]
print(oranges_rotting(grid))  # Output: 4

Complexity: O(m × n) time, O(m × n) space — each cell processed at most once.

Why Google likes this: Tests multi-source BFS, grid traversal, and the ability to track multiple state changes simultaneously.

Example 2: Dynamic Programming — Coin Change

Problem: Given coins of different denominations and a target amount, find the minimum number of coins needed. If not possible, return -1.

def coin_change(coins: list[int], amount: int) -> int:
    dp = [float('inf')] * (amount + 1)
    dp[0] = 0
    
    for i in range(1, amount + 1):
        for coin in coins:
            if coin <= i and dp[i - coin] != float('inf'):
                dp[i] = min(dp[i], dp[i - coin] + 1)
    
    return dp[amount] if dp[amount] != float('inf') else -1

# Test cases
print(coin_change([1, 5, 10, 25], 30))  # Output: 2 (25 + 5)
print(coin_change([2], 3))               # Output: -1

Complexity: O(amount × len(coins)) time, O(amount) space.

Google follow-up questions:

• "Can you reconstruct which coins were used?"
• "What if coins have unlimited supply vs. limited supply?"
• "How would you handle a system with 10^6 different coin types?"

Example 3: Binary Tree — Maximum Path Sum

Problem: Find the maximum path sum in a binary tree. A path can start and end at any node.

class TreeNode:
    def __init__(self, val=0, left=None, right=None):
        self.val = val
        self.left = left
        self.right = right

def max_path_sum(root: TreeNode) -> int:
    max_sum = float('-inf')
    
    def dfs(node: TreeNode) -> int:
        nonlocal max_sum
        if not node:
            return 0
        
        # Get max gain from left and right subtrees
        left_gain = max(dfs(node.left), 0)
        right_gain = max(dfs(node.right), 0)
        
        # Path passing through this node
        path_through = node.val + left_gain + right_gain
        max_sum = max(max_sum, path_through)
        
        # Return max gain if we continue path through parent
        return node.val + max(left_gain, right_gain)
    
    dfs(root)
    return max_sum

# Build tree:     1
#                / \
#               2   3
root = TreeNode(1)
root.left = TreeNode(2)
root.right = TreeNode(3)
print(max_path_sum(root))  # Output: 6

Complexity: O(n) time, O(h) space where h is tree height.

Key insight: At each node, we compute two things: the max path through this node (stored globally) and the max gain we can contribute to a parent node (returned to caller).

Example 4: Two Pointers — Container With Most Water

Problem: Given n non-negative integers, find two lines that together with the x-axis form a container holding the most water.

def max_area(height: list[int]) -> int:
    left, right = 0, len(height) - 1
    max_water = 0
    
    while left < right:
        water = min(height[left], height[right]) * (right - left)
        max_water = max(max_water, water)
        
        # Move the shorter line inward
        if height[left] < height[right]:
            left += 1
        else:
            right -= 1
    
    return max_water

# Test case
heights = [1, 8, 6, 2, 5, 4, 8, 3, 7]
print(max_area(heights))  # Output: 49

Complexity: O(n) time, O(1) space.

Why Google likes this: Tests the insight that moving the shorter pointer can only increase (or maintain) potential area, enabling an O(n) solution instead of brute-force O(n²).

Google's "Googleyness" Round

Google's behavioral round assesses culture fit under the label "Googleyness." This is not a soft round — Google gives it equal weight to coding rounds in the committee debrief.

Google interviewers are looking for:

• Intellectual curiosity — genuine enthusiasm for hard problems
• Comfort with ambiguity — can you operate without being told exactly what to do?
• Collaborative spirit — do you attribute success to the team or just yourself?
• Constructive challenge — have you pushed back on bad decisions with data?

Common Googleyness questions:

• "Tell me about a time you worked on a team project where things went wrong."
• "Describe a situation where you had to learn something new very quickly."
• "Tell me about a time you challenged the status quo."

Use the STAR method. Ground every answer in specific, verifiable details.

Common Google Interview Mistakes

Many candidates fail not because they lack technical ability, but because of avoidable mistakes that signal weakness to Google-caliber interviewers.

Mistake 1: Jumping into Code Before Thinking

The problem: Candidates start typing immediately after hearing the problem. This signals you're solving without understanding.

The fix: Spend 3–5 minutes clarifying constraints, identifying edge cases, and verbalizing your approach. Google interviewers explicitly note whether you "rushed to code."

Instead of: "Okay, I'll use a hash map..."
Say: "Let me make sure I understand the constraints first. Are there negative numbers?
     Can the array be empty? How large can it get? I'm thinking a hash map approach
     because..."

Mistake 2: Ignoring Edge Cases

The problem: Writing a solution that works for the happy path but crashes on empty inputs, single-element arrays, or negative numbers.

The fix: Before coding, list 3-4 edge cases out loud. After coding, trace through at least one edge case manually.

Edge cases to always check:
- Empty input (null, [], "")
- Single element
- All elements identical
- Maximum/minimum values (overflow, INT_MAX)
- Negative numbers (if allowed)

Mistake 3: Not Explaining Your Thought Process

The problem: Solving the problem silently. Google interviewers cannot give you credit for reasoning they don't see.

The fix: Think out loud continuously. Narrate your decisions: "I'm choosing BFS here because I need the shortest path and all edges have equal weight."

Mistake 4: Writing Inefficient Code Without Justification

The problem: Presenting an O(n²) solution when an O(n) or O(n log n) solution exists, without acknowledging the inefficiency.

The fix: State the complexity explicitly, then ask: "Would you like me to optimize this?" Even if you can't optimize, showing awareness signals engineering maturity.

Mistake 5: Not Handling Follow-Up Questions

The problem: Google interviewers will modify your solution mid-interview: "What if the graph has cycles?" "How would you parallelize this?" Failing to adapt signals shallow understanding.

The fix: Practice variations. After solving any problem, ask yourself: what would change if the input was 10x larger? What if it was a stream? What if we needed real-time updates?

Mistake 6: Poor Testing Habits

The problem: Writing code and immediately saying "I think it's done" without testing.

The fix: Walk through 2-3 test cases before declaring completion. Include an edge case, a normal case, and a large input case.

# After writing your solution, ALWAYS do this:
print(f"Test 1 (edge case): {solution([])}")           # Expected: edge behavior
print(f"Test 2 (normal): {solution([1,2,3,4,5])}")     # Expected: correct result
print(f"Test 3 (large): {solution(range(10000))}")     # Expected: no timeout

Google Interview Scorecard

Google interviewers fill out a structured feedback form. Here's what they're evaluating and the weight each signal carries:

What "Leans Hire" vs "Strong Hire" Means

A "Leans Hire" signal means the interviewer believes you probably meet the bar but isn't fully confident. In committee, this often gets balanced against other rounds. Two "Strong Hires" can compensate for one "Leans Hire." However, even one "Strong No Hire" is extremely difficult to overcome.

Real Google Interview Walkthrough: 45 Minutes

Here's a minute-by-minute breakdown of what a successful Google coding interview actually looks like.

The Problem

"Given a binary tree, return the level order traversal of its nodes' values (i.e., from left to right, level by level)."

Minute 0–3: Clarification

Candidate: "Great, let me make sure I understand. We're returning a list of lists, where each inner list contains the values at that level. For example, if the tree is:

    3
   / \
  9  20
    /  \
   15   7

The output would be [[3], [9, 20], [15, 7]]?"

Interviewer: "Yes, that's correct."

Candidate: "What should I return for an empty tree? An empty list?"

Interviewer: "Yes."

Minute 3–8: Approach Discussion

Candidate: "I'll use BFS with a queue. BFS naturally processes nodes level by level, which is exactly what we need. I'll track the number of nodes at each level to separate the groups."

Interviewer: "Why BFS over DFS?"

Candidate: "DFS could work with a level parameter, but BFS gives us the levels for free since we process one level at a time. BFS is also O(n) time and O(w) space where w is the max width, which is the same space complexity as DFS for a balanced tree. For a very wide tree, DFS might use less space, but BFS is more straightforward here."

Minute 8–22: Coding

from collections import deque

def level_order(root: TreeNode) -> list[list[int]]:
    if not root:
        return []
    
    result = []
    queue = deque([root])
    
    while queue:
        level_size = len(queue)
        level_values = []
        
        for _ in range(level_size):
            node = queue.popleft()
            level_values.append(node.val)
            
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
        
        result.append(level_values)
    
    return result

Minute 22–27: Walkthrough and Edge Cases

Candidate: "Let me trace through the example. Starting with [3], we process level 0. level_size = 1, we pop 3, add [9, 20] to queue. Next iteration: level_size = 2, process 9 and 20, add [15, 7]. Final iteration: level_size = 2, process 15 and 7, no children. Result: [[3], [9, 20], [15, 7]]. ✓

Edge cases: empty tree returns [] because of the early return. Single node returns [[val]]."

Minute 27–32: Complexity Analysis

Candidate: "Time complexity is O(n) — we visit each node exactly once. Space complexity is O(w) where w is the maximum width of the tree, since that's the maximum number of nodes in the queue at any point. For a balanced tree, w is O(n/2) = O(n). For a skewed tree, w is O(1)."

Minute 32–38: Follow-Up Question

Interviewer: "What if we needed the right-to-left level order traversal?"

Candidate: "We could reverse each level's values before appending to the result, but a cleaner approach would be to process right children before left. Or we could just reverse the result at the end if the requirement was truly right-to-left."

Minute 38–42: Follow-Up Question

Interviewer: "What if the tree could have cycles? How would that change your solution?"

Candidate: "A standard binary tree can't have cycles by definition, but if we were dealing with a general graph, we'd need a visited set to avoid infinite loops. We'd add a visited set, check it before processing each node, and add nodes to it when we enqueue them."

Minute 42–45: Wrap-Up

Candidate: "Is there anything else you'd like me to clarify or optimize?"

This walkthrough demonstrates: clear communication, structured thinking, clean code, proactive testing, and the ability to handle follow-ups — all signals Google interviewers look for.

Time Management: Minute-by-Minute Breakdown

A 45-minute Google coding interview is structured. Here's how top candidates allocate their time:

Google Interview Time Allocation (45 min)

Minute-by-Minute Breakdown

Time Budget Rules

• If you spend more than 5 minutes clarifying, you're overthinking. Move to design.
• If you spend more than 20 minutes coding, your approach is too complex. Simplify.
• If you can't solve it after 30 minutes, ask for a hint. Getting stuck and staying stuck is worse than asking.
• If you finish early, use remaining time to optimize or test additional edge cases. Don't sit idle.

Level-Specific Preparation

Google interviews are calibrated differently depending on the level. Here's what changes:

L3 (SDE-1 / New Grad)

• Interview format: 2 coding rounds + 1 Googleyness (no system design)
• Problem difficulty: Easy to Medium LeetCode
• Focus areas: Array manipulation, hash maps, basic trees, simple DP
• What they're testing: Can you write clean, bug-free code with basic algorithms?
• Expected depth: You should know time/space complexity of common algorithms. You don't need to derive them from first principles.

Preparation priority:

1. Arrays and strings (two pointers, sliding window)
2. Hash maps (frequency counting, grouping)
3. Basic trees (traversals, BST operations)
4. Simple DP (1D problems like climbing stairs, house robber)

L4 (SDE-2 / Mid-Level)

• Interview format: 3 coding rounds + 1 Googleyness + 1 system design
• Problem difficulty: Medium to Hard LeetCode
• Focus areas: Trees, graphs, DP, system design fundamentals
• What they're testing: Can you solve complex problems independently and design simple systems?
• Expected depth: You should be able to discuss algorithm tradeoffs, optimize solutions, and handle follow-up questions without hints.

Preparation priority:

1. Graph algorithms (BFS, DFS, topological sort, shortest path)
2. Advanced DP (2D problems, state machines)
3. Trees (LCA, serialization, advanced traversals)
4. System design basics (URL shortener, rate limiter) — start with our system design questions for beginners
5. Code organization and modularity

L5 (Senior SDE / Staff-track)

• Interview format: 3 coding rounds + 1 Googleyness + 1 system design (deep)
• Problem difficulty: Hard LeetCode + novel problems
• Focus areas: Complex algorithms, system design at scale, technical leadership
• What they're testing: Can you architect systems, mentor others, and solve ambiguous problems?
• Expected depth: You should derive algorithms from first principles, discuss production tradeoffs, and handle questions about distributed systems.

Preparation priority:

1. All L4 topics at deeper depth
2. Advanced system design (Google-scale problems: search, YouTube, Gmail)
3. Distributed systems concepts (CAP theorem, consistency models)
4. Leadership signals (how you've influenced technical direction)
5. Novel problem-solving (problems you haven't seen before)

Level Comparison Table

Google vs Meta vs Amazon: Interview Comparison

Key Differences to Prepare For

Google asks you to defend why your solution works. Be ready for "Why BFS?" "What if we add weights?" "What breaks at scale?"

Meta focuses on speed and correctness. You need to solve 2 problems in 40 minutes, so practice fast implementation.

Amazon emphasizes Leadership Principles. Half your interview is behavioral — prepare 10+ STAR stories covering each principle.

How to Prepare Specifically for Google

Phase 1 (Weeks 1–4): Core algorithms

Focus on trees, graphs, and DP. These three categories cover 60–70% of Google on-site problems. Don't move to Phase 2 until you can solve Medium tree and graph problems without hints.

Phase 2 (Weeks 5–8): Google-specific patterns

• Practice problems tagged "Google" on LeetCode
• Focus on problems that combine data structures (e.g., "Design a data structure that supports insert, delete, and get-random in O(1)")
• Practice explaining your solution before coding, not after

Phase 3 (Weeks 9–12): Mock interviews and calibration

• Simulate full 45-minute interviews with time pressure
• Use InterviewSkool to practice at Google-level calibration
• Practice your Googleyness stories — have 5–6 prepared

The thing most Google interview prep guides miss

Google interviewers probe why your solution works, not just that it works. After you present your approach, expect: "Why a BFS and not a DFS here?" "What happens to your approach if the graph has cycles?" "What would break at 10x scale?"

Avoid the most common coding interview mistakes that trip up Google candidates. Prepare to defend every design decision. The strength of your signal often comes from how you respond to pushback, not from whether your first solution was perfect.

Quick Reference Cheat Sheet

Data Structures — When to Use

Algorithm Patterns — Quick Reference

Complexity Cheat Sheet

Common Google Patterns to Recognize

"Shortest path in unweighted graph"     → BFS
"Shortest path in weighted graph"       → Dijkstra
"Is there a path?"                      → DFS
"Topological ordering"                  → DFS or Kahn's algorithm
"Minimum cost to reach end"             → DP or Dijkstra
"Maximum subarray"                      → Kadane's algorithm (DP)
"Check if BST is valid"                 → DFS with min/max bounds
"Find all connected components"         → DFS/BFS or Union-Find
"LCA of two nodes"                      → DFS with parent tracking
"Merge K sorted lists"                  → Min-heap

Google-Specific Tips

1. Always clarify constraints first. Google interviewers note this as a positive signal.
2. Discuss tradeoffs before coding. "I could use approach A with O(n²) time, or approach B with O(n log n) time and O(n) space. I'll go with B."
3. Name your variables well. visited_set beats v. current_max beats cm. Google cares about readability.
4. Test before declaring done. Walk through 2-3 examples, including an edge case.
5. Handle follow-ups gracefully. When asked "What if X changes?", pause, think, then adapt. Don't get defensive.
6. Practice explaining complexity. Don't just say "O(n log n)." Say "O(n log n) because we sort the array once, which dominates the O(n) pass we do afterward."

Frequently Asked Questions

Practice at Google's Bar

InterviewSkool's Alex asks the same probing follow-up questions Google interviewers ask — complexity challenges, edge case probing, and design justification. It's the closest to the real experience you can get without actually interviewing at Google.

Start a Google-style mock interview →