30 Google LeetCode Interview Questions for 2026

See the 30 Google LeetCode interview questions candidates report most often, plus topic breakdowns, level-based prep, and a smarter study plan.

Google LeetCode Interview Questions: 30 Most Asked (2026)

Google's coding rounds pull heavily from LeetCode and similar public platforms. There is no secret question bank requiring insider access. The question worth your prep time is which problems actually show up, how often, and in what order to tackle them. This post covers 30 high-frequency problems organized by topic, a breakdown of what each interview stage tests, and a study approach that works whether you're a fresher targeting L3 or an experienced engineer going for L5+.

How Google uses LeetCode questions

Google maintains an internal question bank, but much of what candidates see overlaps with problems on LeetCode, HackerRank, Codeforces, and LintCode. The problems are public. The edge comes from how well you recognize patterns and communicate your thinking under pressure.

Coding questions appear in two main stages: the technical phone screen (one round, 45 minutes) and the onsite (usually two or three coding rounds out of four or five total). The full process, from recruiter outreach to offer, typically takes six to eight weeks. After the onsite, a Hiring Committee reviews your packet independently of the interviewers, so consistency across rounds matters more than one standout performance.

Question type breakdown: what Google actually tests

Google's coding questions are not evenly distributed. Based on aggregate candidate reports from 2024-2025 LeetCode discussion threads, the approximate frequency breakdown looks like this:

• Arrays / Strings — ~35% of coding questions
• Trees / Graphs — ~25%
• Dynamic Programming — ~15%
• Linked Lists — ~12%
• Search / Sort — ~8%
• Hash Tables / Heaps — ~5%

These numbers come from candidate-reported data, not an official Google publication, but the pattern is consistent enough across multiple sources to be useful for prioritization. Front-load arrays/strings and trees/graphs. Together they account for roughly 60% of what you'll see. Dynamic programming is the next priority. Everything else matters, but not as much as those three.

Google LeetCode interview questions by category

The 30 questions below are drawn from 2024-2025 candidate reports aggregated on LeetCode Discuss. Each entry names the problem, its typical difficulty, and a short note on why Google favors it.

Arrays and strings (8 questions)

• Two Sum (Easy) — The classic warm-up. Tests hash map intuition and whether you can move past brute force quickly.
• Longest Substring Without Repeating Characters (Medium) — Sliding window fundamentals. Google uses it to gauge how cleanly you handle pointer management.
• Trapping Rain Water (Hard) — Tests your ability to think about prefix/suffix relationships. A favorite for phone screens because it has multiple valid approaches.
• Minimum Window Substring (Hard) — Sliding window plus frequency counting. Requires careful edge-case handling, which is exactly what interviewers watch for.
• Product of Array Except Self (Medium) — Tests whether you can avoid division and think in terms of prefix products. Clean code matters here.
• Merge Intervals (Medium) — Sorting plus greedy logic. Shows up often because it maps to real infrastructure problems.
• Container With Most Water (Medium) — Two-pointer pattern. Simple to state, easy to get wrong if you don't reason about why the pointer moves.
• Valid Anagram (Easy) — Quick frequency-count problem. Often used as a warm-up before a harder follow-up in the same round.

Trees and graphs (7 questions)

• Binary Tree Level Order Traversal (Medium) — BFS fundamentals. Google expects you to write this without hesitation.
• Number of Islands (Medium) — BFS/DFS on a grid. One of the most frequently reported Google problems across all levels.
• Word Ladder (Hard) — BFS on an implicit graph. Tests whether you can model a non-obvious graph structure.
• Course Schedule (Medium) — Topological sort. Directly relevant to dependency resolution, which Google engineers deal with constantly.
• Lowest Common Ancestor of a BST (Medium) — Tests BST property understanding. Often a phone screen question.
• Clone Graph (Medium) — Deep copy with cycle handling. Tests your comfort with hash maps and graph traversal together.
• Serialize and Deserialize Binary Tree (Hard) — Design-flavored coding problem. Google likes it because it tests both algorithm thinking and API design instincts.

Dynamic programming (5 questions)

• Coin Change (Medium) — The canonical DP problem. If you can explain the state transition clearly, you're in good shape.
• Longest Increasing Subsequence (Medium) — Tests whether you know the O(n log n) approach or only the O(n²) one. Google interviewers notice.
• Edit Distance (Medium) — Two-dimensional DP. Appears in Google interviews because it connects to real search and NLP problems.
• Word Break (Medium) — DP plus string manipulation. A good test of whether you can define subproblems cleanly.
• Decode Ways (Medium) — Simpler DP, but the edge cases are where candidates stumble. Google uses it to see how carefully you handle boundaries.

Linked lists (4 questions)

• Reverse Linked List (Easy) — Fundamental. If this takes you more than two minutes, the rest of the round will be difficult.
• Merge K Sorted Lists (Hard) — Heap-based merging. Tests data structure selection and complexity analysis.
• LRU Cache (Medium) — Combines a hash map with a doubly linked list. One of the most commonly named Google coding questions across multiple candidate reports.
• Linked List Cycle (Easy) — Floyd's algorithm. Quick to implement, but Google interviewers often follow up with "why does this work?"

Search, sort, and heaps (4 questions)

• Find Median from Data Stream (Hard) — Two-heap approach. Tests your ability to maintain running statistics efficiently.
• Top K Frequent Elements (Medium) — Heap or bucket sort. Google likes it because there are multiple valid approaches with different tradeoffs.
• Search in Rotated Sorted Array (Medium) — Modified binary search. Tests whether you can adapt a known pattern to a twist.
• Kth Largest Element in an Array (Medium) — Quickselect or heap. A common follow-up after a sorting discussion.

Range queries and segment trees (2 questions)

• Range Sum Query - Mutable (Medium) — Segment tree is the expected approach. This has appeared in Google phone screens per candidate reports; one engineer noted that a segment tree solution was specifically what the interviewer was looking for.
• Count of Range Sum (Hard) — Merge sort or segment tree. Tests advanced data structure knowledge, typically seen at L4+ onsite rounds.

Google LeetCode interview questions for freshers vs. experienced engineers

The question pool overlaps across levels, but the difficulty bar and evaluation criteria shift.

Freshers (L3 / early career)

Start with Easy problems across all main categories. A practical heuristic from candidates who've been through it: if you can solve roughly 75% of Easy problems within an hour, move to Medium. Don't skip categories. Google's question distribution is broad enough that a gap in trees or linked lists will cost you.

Focus on arrays/strings first, then trees. Behavioral prep matters even at L3. Googleyness, meaning comfort with ambiguity, intellectual humility, and collaboration, is evaluated at every level. Prepare two or three STAR-format stories before your onsite.

Experienced engineers (L4 L5+)

Expect Medium-to-Hard problems, system design rounds, and deeper behavioral evaluation. Coding rounds may include harder graph and DP problems, and questions requiring segment trees or other advanced data structures are not unusual. Recruiters typically give one to two months to prepare, which sounds generous until you factor in a full-time job and the breadth of material.

One line of context on stakes: L5+ total compensation at Google can exceed $350K. The bar is proportional.

How to practice Google LeetCode interview questions effectively

Grinding problems randomly is the least efficient way to prepare. A pattern-first approach works better: before you start coding, identify the problem type. Is this a sliding window? A BFS on an implicit graph? A prefix-sum setup? Recognizing the pattern is half the solve.

Study by category, not by random queue. Easy to Medium within each topic. Time-box your practice to simulate real conditions: no hints, 35-45 minutes per problem, and explain your approach out loud as you go. Plan for six to eight weeks minimum of consistent practice.

One thing that's hard to replicate on your own: feedback on how you explain your thinking. You can verify that your code passes test cases, but you can't easily judge whether your verbal walkthrough would land with an interviewer. Verve AI's mock interview feature lets you rehearse Google-style coding questions with real-time guidance and a structured performance report afterward, so you catch communication gaps before the actual screen, not during it. The Interview Copilot does the same thing during live interviews: it listens to the conversation, suggests approaches, and stays invisible to the interviewer.

Beyond coding: what else Google evaluates

Coding is the core, but it's not the whole picture.

System design (L4+) is a separate round. Example question: Design Google Search. You're evaluated on how you scope the problem, choose components, handle scale, and discuss tradeoffs, not on producing a perfect architecture.

Googleyness and leadership is its own evaluation bucket alongside coding and system design. Interviewers look for comfort with ambiguity, willingness to collaborate, and intellectual humility. The STAR method (Situation, Task, Action, Result) is the standard format for behavioral answers. Prepare concrete stories, not abstract principles.

The recruiter process itself can be a bottleneck. Multiple candidates have noted that HR navigation, including scheduling, team matching, and committee timelines, can be as frustrating as the technical rounds. Stay responsive and organized.

Wrapping up

The 30 problems above cover the topic categories that account for the vast majority of Google's coding questions. The distribution is clear: arrays/strings and trees/graphs first, DP next, everything else after. Google's questions are drawn from public platforms. The advantage goes to candidates who build pattern fluency and practice communicating their reasoning, not to those who memorize the most problems.

If you want to test your explanations under realistic conditions before the real thing, Verve AI's mock interviews give you structured feedback on both your code and your communication. Worth a session before your phone screen.