5 Google Technical Interview Questions You Should Be Able to Solve

Getting an interview at Google is one thing. Getting through the technical rounds is another. Google’s software engineering interviews are known for testing much more than whether you can write working code. Interviewers typically want to see how you break down an unfamiliar problem, choose the right data structure, reason about complexity, communicate your approach, and respond when the problem is changed halfway through. A solution that works is often only the beginning of the discussion.

Based on reported Google interview questions and commonly referenced Google-tagged problems, here are five high-impact questions worth knowing. They cover binary search, hashing, sliding windows, graph traversal, and tree serialization, giving you a good snapshot of the kind of algorithmic thinking these interviews can demand. Video walkthrough of these questions coming soon!

Important: Interview questions can vary by role, level, interviewer, and interview loop. These should be treated as representative reported questions and preparation targets, not a guaranteed list of questions Google will ask.

1. Median of Two Sorted Arrays

Difficulty: Hard
Core concepts: Binary Search, Partitioning, Arrays

This is one of those problems that looks deceptively simple until you see the complexity requirement.

The problem

You are given two sorted arrays:

A = [1, 3]
B = [2]

Find the median of the combined sorted array.

The combined array would be:

[1, 2, 3]

So the answer is:

2

The catch is that the expected efficient solution uses binary search rather than simply merging the arrays.

The reported interview formulation is essentially to find the median of two sorted arrays efficiently, with follow-ups around generalizing the solution to the kth element and handling odd and even total lengths.

The obvious approach

You could merge both arrays:

A = [1,3]
B = [2]
Merged = [1,2,3]

Then find the middle element.

That takes:

O(m + n)

But the interesting part of the interview is getting to:

O(log(min(m,n)))

The key idea: partition the arrays

Instead of merging the arrays, divide them into left and right partitions.

Suppose:

A = [1, 3, 8]
B = [7, 9, 10, 11]

We want the left side of the combined data to contain half of all elements.

We choose a partition in A and calculate the corresponding partition in B.

The correct partition must satisfy:

max(left A) <= min(right B)

and

max(left B) <= min(right A)

Once both conditions are true, we have found the correct median boundary.

Why binary search works

If:

max(left A) > min(right B)

we moved too far to the right in A.

Move the partition in A left.

If:

max(left B) > min(right A)

we need to move the partition in A right.

This gives us binary search.

Complexity

Time:  O(log(min(m,n)))
Space: O(1)

What the interviewer may ask next

Don’t stop at the answer.

You may be asked:

• What happens if one array is empty?
• What happens with duplicate values?
• How do you handle an even number of elements?
• Can you find the kth smallest element instead?
• Why is binary search valid here?
• What is the exact space complexity?

This is precisely the kind of problem where the interviewer is evaluating your reasoning, not just whether you remember a solution.

2. Two Sum

Difficulty: Easy
Core concepts: Hash Tables, Arrays

Two Sum is much easier than the previous problem, but don’t underestimate it.

The question is straightforward:

Given an array of integers and a target value, return the indices of two numbers whose sum equals the target.

For example:

nums = [2, 7, 11, 15]
target = 9

The answer is:

[0, 1]

because:

2 + 7 = 9

The reported approach uses a hash map to remember values already seen and look up the required complement in constant average time.

Brute-force solution

The first solution that probably comes to mind is checking every pair.

2 + 7
2 + 11
2 + 15
7 + 11
...

For n elements, that produces roughly:

n²

comparisons.

Complexity:

Time: O(n²)
Space: O(1)

It works, but we can do much better.

The HashMap solution

For every number, ask:

What number do I need to reach the target?

That number is:

complement = target - current

For:

target = 9
current = 7

the complement is:

9 - 7 = 2

If we’ve already seen 2, we’ve found our pair.

Example

nums = [2, 7, 11, 15]
target = 9

Start with an empty map.

2

Need:

9 - 2 = 7

7 isn’t present.

Store:

2 → index 0

Next:

7

Need:

9 - 7 = 2

2 is already in the map.

Therefore:

[0, 1]

Complexity

Time:  O(n)
Space: O(n)

That’s a major improvement over O(n²).

The interview lesson

Two Sum is less about the problem itself and more about recognizing the pattern:

When you repeatedly need to ask whether a value exists, think about a hash table.

A good interviewer may then modify the problem:

• What if there are multiple valid pairs?
• What if the array is already sorted?
• What if you cannot use extra memory?
• What if you need to return the values rather than indices?

That is where the interview becomes interesting.

3. Longest Substring Without Repeating Characters

Difficulty: Medium
Core concepts: Sliding Window, Hashing, Two Pointers

Now we move into one of the most useful patterns in coding interviews: the sliding window.

The problem

Given a string, find the length of the longest substring containing no repeated characters.

Example:

s = "abcabcbb"

The longest substring without repeating characters is:

"abc"

Therefore:

Answer = 3

The reported solution uses a sliding window with a hash set or map to track characters in the current window.

Brute force

One approach is to generate every possible substring and check whether it contains duplicates.

But the number of substrings can be:

O(n²)

And checking each substring can add another factor of n.

That can result in:

O(n³)

A better approach is to avoid repeatedly checking the same characters.

Sliding Window

Think of two pointers:

left
  ↓

[a b c]

right ↑

The window represents the current substring.

As right moves forward, we add characters.

If a duplicate appears, move left forward until the window becomes valid again.

For:

abcabcbb

we initially have:

[a]

[a b]

[a b c]

The next character is:

a

But a already exists in the window.

So we move the left pointer forward until the duplicate is removed.

The window becomes:

[b c a]

and we continue.

Complexity

Each character enters and leaves the sliding window at most once.

Therefore:

Time:  O(n)
Space: O(min(n, character_set))

The bigger lesson

This problem teaches a pattern that appears everywhere:

When you’re looking for a longest or shortest contiguous section satisfying some condition, consider a sliding window.

Once you recognize that pattern, many seemingly difficult problems become much easier.

4. Number of Islands

Difficulty: Medium
Core concepts: Graph Traversal, DFS, BFS, Connected Components

This problem takes a grid and turns it into a graph problem.

The problem

You are given a grid containing:

1 = land
0 = water

For example:

1 1 0 0 0
1 1 0 0 0
0 0 1 0 0
0 0 0 1 1

How many islands are there?

The answer is:

3

The commonly reported solution is to use DFS or BFS to count connected components of land cells.

The key observation

An island is simply a connected group of 1s.

So the problem becomes:

How many connected components exist in this grid?

That immediately suggests:

DFS

or:

BFS

DFS solution

Scan every cell.

Whenever you encounter:

grid[row][col] == 1

you have discovered a new island.

Increment the island counter and perform DFS to visit every connected piece of land.

For example:

1 1 0
1 0 0
0 0 1

Start at the first 1.

DFS visits:

1 1
1

All of those cells belong to one island.

Continue scanning.

The final 1 represents another island.

Therefore:

islands = 2

Avoiding repeated work

Every visited land cell should be marked as visited.

One simple technique is changing:

1 → 0

after visiting it.

That means we never process the same island twice.

Complexity

For a grid containing m × n cells:

Time:  O(m × n)
Space: O(m × n)

The space complexity depends on the DFS recursion stack or an explicit BFS queue.

Interview follow-ups

A Google-style follow-up could change the problem:

• What if diagonal connections count?
• What if the grid is extremely large?
• Can you solve it iteratively?
• What if the grid is streamed?
• Can you count the size of every island?
• What is the largest island?

The underlying skill being tested is not memorizing “Number of Islands.”

It’s recognizing:

Grid → Graph → Connected Components → DFS/BFS

5. Serialize and Deserialize a Binary Tree

Difficulty: Medium
Core concepts: Trees, Recursion, BFS/DFS, Data Representation

This one tests something slightly different.

Instead of simply traversing a tree, you have to preserve its structure so that it can later be reconstructed.

A reported version of the problem asks candidates to persist a binary tree and read it back while preserving its structure.

The problem

Given:

        1
       / \
      2   3
         / \
        4   5

convert it into a representation that can be stored or transmitted.

Then reconstruct the exact same tree from that representation.

This gives us two operations:

serialize(tree)
deserialize(data)

Why a simple traversal isn’t enough

Suppose we serialize only the values:

1,2,3,4,5

We lose information about where the null children are.

Consider these two trees:

    1
   /
  2

and:

    1
     \
      2

Both contain:

1,2

But they are structurally different.

So the serialization must preserve null pointers.

Preorder traversal

One common approach is preorder traversal:

Root → Left → Right

For the tree above:

1, 2, NULL, NULL, 3, 4, NULL, NULL, 5, NULL, NULL

The NULL markers are important.

They tell the deserializer exactly where a branch ends.

Deserialization

Read the serialized data from left to right.

For:

1, 2, NULL, NULL, 3, 4, NULL, NULL, 5, NULL, NULL

we reconstruct:

        1
       / \
      2   3
         / \
        4   5

The recursive structure makes this elegant.

Pseudo-code looks conceptually like:

deserialize():
    value = next token
    if value == NULL:
        return null
    node = new Node(value)
    node.left = deserialize()
    node.right = deserialize()
    return node

Complexity

For n nodes:

Time:  O(n)
Space: O(n)

The serialized representation itself also requires space proportional to the tree size.

What makes this a good interview question?

Because the interviewer can immediately extend it:

• Can you use BFS instead of DFS?
• How would you minimize serialized size?
• What happens with an empty tree?
• Can the data be streamed?
• How would you persist a balanced tree?
• What if the tree contains duplicate values?

The problem is testing whether you can design a representation that preserves information, not merely perform a traversal.

What These Five Questions Actually Test

At first glance, these look like five unrelated coding problems. They’re not. Together, they cover several fundamental patterns:

And these patterns show up repeatedly in technical interviews.

The source research also identifies arrays, strings, trees, graphs, dynamic programming, hashing, sorting, searching, and sliding-window techniques as major areas in Google technical interviews.

The Part Most Candidates Miss

Knowing the solution isn’t enough.

Imagine you solve Two Sum in 30 seconds.

The interviewer then asks:

“Can you do it without extra space?”

Or:

“What if the array is sorted?”

Or:

“What if I need all unique pairs?”

Suddenly, you’re solving a different problem.

The same happens with the other questions.

A strong interview candidate should be able to explain:

1. Why the solution works
2. Why the chosen data structure is appropriate
3. Time complexity
4. Space complexity
5. Edge cases
6. Alternative approaches
7. Trade-offs
8. How the solution changes when the requirements change

That is why practicing solutions mechanically is not enough.

You need to understand the pattern behind the solution.

From Coding Questions to Real Interview Problems

These five questions are only the coding side of the picture.

Google interviews can also cover system design, concurrency, databases, networking, operating systems, and behavioral or “Googliness” questions. The research used for this article places DS&A at very high frequency, while system design becomes particularly important for more senior roles.

For example, system-design preparation can involve questions such as:

• Design an autocomplete system
• Design a URL shortener
• Design a notification system
• Design a large-scale messaging system

A senior candidate may therefore need to move from:

"Can you solve this algorithm?"

to:

"Can you design this system for millions or billions of users?"

And then explain the trade-offs.

Don’t Just Prepare for the Question. Prepare for the Follow-Up.

That’s probably the biggest takeaway from these examples.

If you memorize:

Two Sum = HashMap

you know one solution.

If you understand:

Repeated lookup → Hashing
Sorted input → Binary Search
Contiguous range → Sliding Window
Connected cells → Graph Traversal
Structure preservation → Serialization

you’ve learned reusable problem-solving patterns.

That distinction matters when the interviewer changes the problem.

What’s Coming Next?

This is only the beginning.

I’m putting together a Google Technical Interview Preparation video series that will go much deeper than a list of questions.

The upcoming series will break down problems step by step, including:

• How to recognize the underlying pattern
• How to approach a problem before writing code
• Brute-force vs optimized solutions
• Time and space complexity
• Common interview traps
• Follow-up questions
• Data structures you should reach for
• System design fundamentals
• Mock interview-style problem solving
• How to communicate your solution during an interview

The goal isn’t to teach you 100 solutions to memorize.

It’s to teach you how to think through the next problem you’ve never seen before.

Want More Interview Prep Content?

Final Takeaway

You don’t need to memorize every Google interview question.

You need to become comfortable with the patterns behind them.

Binary search. Hashing. Sliding windows. Graph traversal. Trees. Dynamic programming.

Once those patterns become second nature, unfamiliar questions become much less intimidating.

And that’s exactly what the upcoming interview-prep series will focus on.

The questions are only the surface. The real skill is learning how to solve the problem underneath them.