Top 15 Google Coding Interview Problems: Patterns and What Each Teaches

Google's interview pool isn't just harder than most. It's shaped differently. The problems it favors test whether you can model a problem before you solve it, not just recognize a familiar shape and execute. That shift matters for how you prep, and most candidates miss it completely until they're sitting in a Google Doc wondering why their perfectly memorized BFS isn't landing.

This guide covers 15 Google coding interview problems reported most often across Google interviews, drawn from LeetCode Discuss compilations, candidate reports, and company-tag data from 2024 and 2025. Each entry explains what the problem actually tests, not just its pattern label.

Why Google's Pool Is Different

Most companies test whether you know your patterns. Google tests whether you can derive structure from a problem that doesn't announce its structure. The most common Google-specific failure is candidates who can solve a problem once the graph or DP framing is obvious, but can't construct that framing themselves.

Implicit graph problems appear constantly. DP comes up more at Google than at any other FAANG company, per interviewing.io data. One correct solution scores a 3. Google's rubric for a 4 on the Algorithms dimension explicitly requires "several solutions along with their drawbacks." That's not bonus credit. That's the target.

Oh, and Google interviews run in Google Docs. No syntax highlighting, no autocomplete. Write code your interviewer can read like prose, or at least like legible prose.

Google Coding Interview Problems That Keep Appearing

#	Problem	Difficulty	Pattern
1	Number of Islands (LC 200)	Medium	Grid BFS/DFS
2	Word Ladder (LC 127)	Hard	BFS on implicit graph
3	Trapping Rain Water (LC 42)	Hard	Two pointers / monotonic stack
4	Minimum Window Substring (LC 76)	Hard	Sliding window
5	Serialize and Deserialize Binary Tree (LC 297)	Hard	BFS + API design
6	Merge Intervals (LC 56)	Medium	Sort + merge
7	Sliding Window Maximum (LC 239)	Hard	Monotonic deque
8	Merge K Sorted Lists (LC 23)	Hard	Min-heap
9	Meeting Rooms II (LC 253)	Medium	Events + heap
10	Network Delay Time (LC 743)	Medium	Dijkstra
11	Alien Dictionary (LC 269)	Hard	Topological sort from implicit DAG
12	Find Median from Data Stream (LC 295)	Hard	Two heaps
13	Count of Smaller Numbers After Self (LC 315)	Hard	Merge sort / Fenwick tree
14	Binary Tree Maximum Path Sum (LC 124)	Hard	Tree DFS + global tracking
15	Word Break (LC 139)	Medium	BFS or DP

1. Number of Islands (LC 200)

The interview doesn't start here by accident. Google uses this as a baseline that's approachable for L3 and extensible for L5: 3D grids, distinct island shapes, streaming addLand calls. The streaming follow-up tests whether you recognize Union-Find as the right tool for incremental connectivity updates, which is a second problem hidden inside the first. Solve the easy one, then wait for the interviewer to pull back the curtain.

2. Word Ladder (LC 127)

A word graph is never drawn for you. You must realize that each word is a node, edges connect words differing by one character, and then run BFS on that structure. Most candidates spend their first five minutes staring at a list of strings trying to apply dynamic programming to it.

The construction step, not the BFS itself, is what Google is scoring. Bidirectional BFS is the natural follow-up and cuts the search space from O(b^d) to O(b^(d/2)). Know why, not just that it does.

Dog at computer saying "I have no idea what I'm doing"

Candidates in the first three minutes of Word Ladder, trying to find the DP angle.

3. Trapping Rain Water (LC 42)

Three approaches exist: prefix/suffix max arrays in O(n) space, two pointers in O(1) space, and a monotonic stack. Google's rubric for a 4 requires you to offer more than one.

When leftMax < rightMax, the left pointer is the bottleneck regardless of what's on the right. The two-pointer approach doesn't need the exact right max. That insight separates candidates who understand why the algorithm works from those who remember that it does. There's a real difference, and your interviewer will find out which one you are.

4. Minimum Window Substring (LC 76)

Sliding window with a frequency map. The tricky part is deciding when to contract the left pointer: only when the window is valid, meaning all required characters have sufficient counts. Shrinking too eagerly or not eagerly enough is the most common bug, and it produces output that looks almost right, which is the worst kind of wrong.

Google also asks LC 567 (Permutation in String) as a phone screen check for the same underlying technique. Know both.

5. Serialize and Deserialize Binary Tree (LC 297)

This is a design problem disguised as a traversal problem. The questions Google wants you to answer proactively: BFS or DFS? What delimiter? How do you represent null? What if the tree has duplicate values?

The scoring here leans on Code Quality and Problem-Solving, not just Algorithms. Picking a format and justifying it matters as much as implementing it correctly. "I'll just use preorder" is a start. "I'll use preorder because it naturally encodes structure and null markers allow unambiguous deserialization" is what scores a 4.

6. Merge Intervals (LC 56)

Sort by start time, then check whether each interval overlaps the previous merged one. If the current interval is fully contained by the previous one, you must use max(last.end, cur.end), not cur.end. This bug is subtle enough that candidates miss it, obvious enough that interviewers notice immediately.

Insert Interval (LC 57) is the companion problem and tests whether you can handle sorted insertion without a full re-sort.

7. Sliding Window Maximum (LC 239)

The monotonic deque keeps indices in decreasing order of value. When the window slides, pop the front if it's out of range. When adding a new element, pop the back while it's smaller. If you can state the invariant in one sentence, you're ready. If you can only recite the steps, you're not.

Google expects you to prove the deque stays correct, not just demonstrate that the code passes a few test cases.

8. Merge K Sorted Lists (LC 23)

Push each list head into a min-heap. Pop the minimum, append it to your result, push that list's next node. Time is O(N log k), space is O(k). Google's follow-up is divide-and-conquer and asks you to compare the constants.

A common extension: what if the k lists were files on distributed machines? That bridge from algorithm to infrastructure appears across many Google problems. Every DS&A question is one follow-up away from a systems question. Stay ready.

9. Meeting Rooms II (LC 253)

Count the maximum number of overlapping intervals. Sort by start time, maintain a min-heap of end times. If the earliest-ending meeting finishes before the new one starts, reuse that room. Otherwise add a new one. The heap size at the end is the answer.

This is a LeetCode Premium problem, but it appears often enough in candidate reports that treating it as required is the right call. Pay the seven dollars.

10. Network Delay Time (LC 743)

Dijkstra on a weighted directed graph. Google uses this to check that you know when BFS breaks (weighted edges) and can implement Dijkstra with the lazy deletion pattern: mark nodes visited when popped, not when pushed.

Know both Dijkstra and Bellman-Ford and be ready to explain the trade-off: Dijkstra is O((V+E) log V) but breaks on negative weights, Bellman-Ford is O(VE) and handles them. Saying "Dijkstra" without knowing when it fails is worse than not knowing Dijkstra at all.

11. Alien Dictionary (LC 269)

Adjacent words in a sorted alien lexicon imply character ordering constraints. You extract them by comparing adjacent word pairs and stopping at the first difference. Then you run Kahn's BFS on the resulting DAG.

The graph construction step has two common bugs: looping past the first differing character, and missing the invalid case where a prefix word appears after its extension. The invalid case returns an empty string, and most candidates forget it. Every candidate who forgets it kicks themselves afterward. Don't be that candidate.

12. Find Median from Data Stream (LC 295)

Two heaps: a max-heap of the lower half, a min-heap of the upper half. Maintain balance, or let the lower half hold one extra. The rebalancing logic after each insertion is where most implementations break.

Google often extends this to a sliding window median, which requires both heaps and an efficient delete operation. The natural follow-up is considerably harder than the base problem. Know that it's coming.

13. Count of Smaller Numbers After Self (LC 315)

For each element, count how many elements to its right are smaller. The O(n log n) paths are merge sort (track inversions during the merge step) or a Fenwick tree (process right to left, query prefix sums).

Google is one of the few FAANG companies that tests Fenwick trees in standard SWE interviews. Learn the BIT template: it's roughly 10 lines and it unlocks a category of range-query-with-updates problems that nothing else solves as cleanly.

14. Binary Tree Maximum Path Sum (LC 124)

DFS where each recursive call returns the maximum single-path gain from that node going downward. But you track the global maximum using the sum of both child paths through the current node.

The path through a node can't simultaneously contribute both its left and right subtrees to a parent caller. That constraint is why the return value differs from the value you use for the global max update. Draw it out. The code makes no sense until you draw it out.

15. Word Break (LC 139)

Can a string be segmented into dictionary words? BFS from index 0, or DP where dp[i] is true if s[0..i-1] can be segmented. Google often follows up with Word Break II (LC 140), which asks you to enumerate all valid segmentations.

The pivot from "can we?" to "list them all" tests whether you understand that solving the decision problem doesn't hand you the enumeration. It doesn't. The enumeration is a different, harder problem that happens to share a name.

What the List Is Actually Measuring

Most of these 15 problems share one property: the hardest step is figuring out what kind of problem it is, not implementing the solution once you've figured that out.

Word Ladder isn't a hard graph problem. It's a medium BFS problem with a hard modeling step. Alien Dictionary isn't a hard topological sort. It's a medium topological sort with a hard graph construction step. Google's difficulty ratings aren't lying, but they're measuring something different from what most candidates practice.

Cracking the Country Interview book parody - "10 Programming Questions to Get Through Airport Customs"

When you prep for the algorithm but not for figuring out which algorithm.

Prep for this by solving problems without category labels. When you open a problem, write your best guess at the data structure and pattern before looking at hints or tags. The friction of that labeling step is exactly what Google is scoring. For more on how Google evaluates your approach end to end, see the full Google onsite interview guide and the Google phone screen breakdown.

For voice-based practice that simulates the actual pressure of explaining your approach out loud, SpaceComplexity runs adaptive mock interviews where prompts are unlabeled and feedback scores your pattern identification alongside your implementation. The voice constraint forces you to narrate the modeling step, which is exactly the skill this list is testing.

Google Interview Preparation Checklist

DP appears at Google more than at any other top company. Expect it at least once per onsite loop.
Fenwick trees appear in standard SWE roles at Google. Learn the BIT template: roughly 10 lines, unlocks a category of range-query problems nothing else solves as cleanly.
Google Docs means no IDE. Code for readability, not compilability.
Follow-up questions push toward scale: streaming input, distributed data, larger constraints. Every problem here has one. Know it.
When you open a problem, write your best guess at the pattern before checking hints or tags. That friction is exactly what Google is scoring.