Google L4 SWE Interview: DSA and LeetCode Questions

What the coding rounds in a Google L4 SWE interview look like, which LeetCode patterns to drill, a worked example, and a prep plan.

The coding questions in a Google SWE interview are LeetCode-style data structures and algorithms problems. interviewing.io says Google interviewers are more likely than most to disguise a question so it looks like a different problem, and that candidates write code in a Google Doc or an internal editor. Google does not publish how its bar differs between levels, so treat the level as a reason to practise explaining your reasoning and handling follow-ups, not as a known difference in question type. You are expected to reach a working, well-analysed solution, handle the follow-up, and explain your reasoning as you go. Google does not publish the questions it asks either, so treat every "Google LeetCode list", including the patterns below, as a practice map rather than a leak.

What L4 means at Google

Levels.fyi lists Google software engineer levels from L3 (entry) up to L9. The first rungs:

Level — Title
L3 — Software Engineer II (entry level)
L4 — Software Engineer III
L5 — Senior Software Engineer

The job listings show where data structures sit. On 22 October 2026, we read the first 20 "Software Engineer III" listings on Google Careers. All 20 asked for about 2 years of programming or software development experience as a minimum (some accept 1 year with an advanced degree), and 15 mentioned data structures or algorithms among the preferred qualifications. So the listings suggest data structures and algorithms are expected background for this level.

One thing to know before you start: the hiring committee, not your interviewers, sets the final level. According to interviewing.io's Google guide, Google downlevels candidates when "they don't get enough of a signal for a hire but too much good signal for a rejection". interviewing.io reports that Google sometimes offers a lower level instead of rejecting, and says it has seen experienced candidates accept L3 offers in some extreme cases.

How the coding rounds run

Google's own hiring page describes the general process, which typically takes about 6 to 8 weeks:

Assessments. You may be asked to take the Google Hiring Assessment and, for some roles, a coding exercise before interviews.
Recruiter conversations. One or two short calls by phone or video.
Interviews. A panel of interviews "either over video or in person". Google's interview tips page says it has reintroduced in-person interviews for some roles, often after initial virtual rounds.
Decision. Google says it reviews "everything together from your application and interviews". interviewing.io describes a hiring committee of four to five engineers and managers who did not interview you, followed by team matching, where both you and the team have to opt in.

For the coding rounds specifically, interviewing.io reports that the onsite usually has 4 to 6 rounds, mostly coding plus system design, and that "the more experience you have, the higher proportion of system design and domain-specific questions you can expect". It also says Google has used Google Docs for writing code in phone screens and has started using an internal editor with syntax highlighting in some regions. Either way, interviewing.io says your interviewer will expect syntactically correct code, so practise in a plain document.

Two rules from Google's own pages shape how you should practise. Interviews use structured rubrics, with the same rubric for every candidate for a role, and Google says it wants to see your thought process, not only the right answer. And Google states that AI tools, including Google Search, are not permitted during interviews. Everything below is preparation you do beforehand.

The DSA patterns to drill for L4

The questions themselves are not public. What exists are candidate reports and mock-interview sets. interviewing.io's Google guide lists 16 sample coding questions from its mock interviews (it notes they may not match real interviews exactly): 12 are labelled medium, 3 hard and 1 easy. That ratio is a sensible target for practice.

Here is how we would group your practice. Problems marked * appear in interviewing.io's Google list; the others are well-known LeetCode problems that train the same pattern.

Pattern — What the interviewer is checking — Practise with
BFS and DFS on grids and implicit graphs — Can you see a graph where the problem never says "graph"? — Number of Islands, Walls and Gates*, Word Ladder
Topological sort — Dependency ordering and cycle detection — Course Schedule, Alien Dictionary*
Binary search on the answer — Turning "minimise the maximum" into a yes/no check — Koko Eating Bananas, Split Array Largest Sum*
Heaps and intervals — Picking the right structure for "top k" and overlap questions — K Closest Points to Origin*, Kth Smallest Element*, Meeting Rooms*, Merge Intervals
Dynamic programming on sequences — Defining a state and a transition out loud — Maximum Subarray*, Longest Common Subsequence*, Regular Expression Matching*
Designing a data structure — Combining two structures to hit a complexity target — LRU Cache, Build a Max Heap From an Array*
Trees and hierarchies — Recursion with clean base cases — Binary Tree Upside Down*, Employee Hierarchy*, Print Folder Structure*

If you have six weeks, two or three problems per row, done properly, is worth more than a hundred problems skimmed. "Done properly" means you could solve it again in a blank doc a week later and explain why each line is there.

Worked example: a disguised binary search

Here is the kind of rewording that catches people. The prompt:

You have a book with chapters of 7, 2, 5, 10 and 8 pages. You must read it in order over 2 days, finishing whole chapters each day. What is the smallest possible number of pages on your heaviest day?

Nothing here says "binary search". This is Split Array Largest Sum in a costume.

A weak answer starts coding a greedy split ("put chapters into day one until it is about half the total"), finds a counterexample during testing, and runs out of time patching it.

A strong answer goes like this:

Clarify. Can a chapter be split? (No.) Can a day be empty? Are page counts positive? How large can the input get?
Name the brute force. Try every way to place the cuts and take the best. Say its cost out loud and move on.
Spot the monotonic check. If you can finish within a daily cap of X pages, you can also finish with any cap above X. A yes/no question whose answer flips once is a binary search over the answer. The cap is at least the longest chapter (10) and at most the whole book (32).
Write the check, then the search.

def min_largest_sum(pages, days):
    def days_needed(cap):
        used, current = 1, 0
        for p in pages:
            if current + p > cap:
                used += 1
                current = 0
            current += p
        return used

    lo, hi = max(pages), sum(pages)
    while lo < hi:
        mid = (lo + hi) // 2
        if days_needed(mid) <= days:
            hi = mid
        else:
            lo = mid + 1
    return lo

Test by hand. For the example, the answer is 18: day one reads 7 + 2 + 5 = 14, day two reads 10 + 8 = 18. Walk one call of days_needed with a cap of 17 and show it needs 3 days, which is why 17 fails.
State the complexity. O(n log S), where n is the number of chapters and S is the total page count, with O(1) extra space.

Then expect a follow-up. Likely ones: return the actual split, not just the number; what changes if chapters can be read in any order (it becomes a much harder partitioning problem, and saying so is a good answer); or how the solution behaves when there are more days than chapters.

The function above returns the same answers as a brute-force solver on random small inputs. That habit, checking your own code with a slow but obviously correct version, is also the best way to find the bugs in your practice solutions.

What to get right in an L4 coding round

Because Google evaluates your thought process, how you run the round matters as much as the answer. Things worth practising until they are automatic:

Clarify before coding. Google's interview tips say its questions often "leave room for clarification" and that your first answer may need refining. Ask about input size and edge cases in the first few minutes.
Give the brute force fast, then improve it. Stating a slow but correct approach early shows the interviewer you can always deliver something.
Talk through tradeoffs. If a heap and a sorted list both work, say why you picked one.
Test without a compiler. Trace a small input line by line, then an edge case (empty input, one element, duplicates).
Leave time for the follow-up. Google's interview tips say to expect follow-up questions.

A six-week prep plan

Weeks 1 and 2: patterns. Work through the table above, one row every two days. Write every solution in a plain document first, then paste it into LeetCode to check it.
Weeks 3 and 4: timed sets. Two unseen mediums per session, timed to the round length your recruiter gives you, talking out loud. Record yourself once a week and listen for long silences.
Week 5: mock interviews. Have a friend read you a disguised problem you have not seen. Practise asking clarifying questions and handling a follow-up.
Week 6: system design and behavioral. Ask your recruiter whether your loop includes system design. For behavioral rounds, Google's tips suggest STAR-structured examples and questions like "Tell me about a time when…", plus how you handle ambiguity and work with teams. Our guide to answering "Why Google?" covers the motivation question.

Since AI tools are not allowed in the interview itself, any AI help belongs in this practice phase. One way to use it: solve a problem on your own first, then capture it with Verve AI's Coding Copilot and use its Complexity and Edge Case actions to check your analysis against a second opinion. For a broader list of Google practice questions, see our Google question bank and our Google LeetCode questions list.

Sources

Google hiring process (6 to 8 weeks, assessments including coding exercises, recruiter calls, video or in-person panel, structured rubrics, AI tools not permitted): https://www.google.com/about/careers/applications/how-we-hire/
Google interview tips (thought process over the answer, room for clarification, STAR, "Tell me about a time when…", ambiguity and teamwork, in-person interviews reintroduced for some roles, follow-up questions, Google Search and AI not permitted): https://www.google.com/about/careers/applications/interview-tips/
Google prep resources (coding prep covers algorithms and data structures): https://www.google.com/about/careers/applications/buildyourfuture/resources/
Onsite rounds, disguised questions, Google Docs and internal editor, syntactically correct code expected, hiring committee, team matching, downleveling quote and L3 offers in extreme cases, process-oriented evaluation, 16 sample questions and their difficulty labels: https://interviewing.io/guides/hiring-process/google
Level names (L3 Software Engineer II entry level, L4 Software Engineer III, L5 Senior Software Engineer): https://www.levels.fyi/companies/google/salaries/software-engineer
Software Engineer III listings and their qualifications (first 20 results, read 22 October 2026): https://www.google.com/about/careers/applications/jobs/results/?q=%22Software%20Engineer%20III%22
Worked-example solution: matches a brute-force solver on random small inputs; no external source.