Google Software Engineer Coding Interview

There is a decent chance that by the time you opened this guide, you had already solved a few Google-tagged LeetCode problems.

Possibly a lot of them.

For many engineers, deciding to interview at Google is immediately followed by opening a problem set and working backwards from the hardest questions they can find. The assumption is understandable.

What really goes on in the coding interview, however, looks something like this:

The tree that supported the original answer now changes continuously. The cache needs a different eviction policy. The graph gains a new constraint. The data no longer fits in memory.

The original problem was never thrown away. It was extended. Once you see that, some preparation habits start looking more useful than others.

This guide covers what Google is evaluating during coding rounds, how the follow-up often becomes the interview, the topics current interviewers are focusing on, worked examples from real mocks, the 2026 Gemini pilot, and how to prepare with the realities of the round in mind.

The easiest way to misunderstand a Google coding interview is to assume that most of the score comes from the code.

Google scores coding rounds across four areas: Algorithms, Coding, Communication, and Problem Solving. Only one of them is primarily concerned with the code sitting in the editor at the end of the interview.

That distinction becomes more obvious when you look at how interviewers write feedback. Two candidates can produce similar solutions and receive very different recommendations because the code is only one record of what happened during the interview. The interviewer also saw how the solution was chosen, how tradeoffs were evaluated, how assumptions were handled, how complexity was discussed, and what happened when the problem changed.

Algorithms is usually visible long before implementation begins. Interviewers are paying attention to whether you recognise the shape of the problem, whether the data structure matches the operations being performed, and whether the complexity target is understood before the first line of code appears. One pattern that came up repeatedly in our conversations with Google interviewers was complexity analysis appearing early in successful interviews. The candidate chooses an approach, explains why, states the expected complexity, and then starts implementing.

Coding is the most straightforward category and the one candidates naturally spend the most time preparing for. The code needs to be correct, readable, and organised. Google interviewers are reading it as it is written, often without running it, which makes structure and clarity more visible than many engineers expect. A solution that arrives with clean helper functions, sensible variable names, and well-defined responsibilities is easier to evaluate than one that reaches the same answer through a tangle of conditionals.

Communication starts generating signal before coding does. A hiring committee member was particularly direct about this during one mock review. Clarifying questions are not separate from the evaluation. They are part of it. The same applies to explaining assumptions, discussing tradeoffs, and making reasoning visible throughout the interview. The interviewer can only evaluate the parts of your thinking that make it into the conversation.

Problem Solving is often where coding rounds separate candidates who look similar on paper. The initial question establishes a baseline. The follow-up reveals how stable that baseline is. A solution that worked when the data fit comfortably in memory may need a different shape once that assumption disappears. A cache design that handled recency correctly may need to incorporate frequency. A tree traversal may need to survive updates. Interviewers learn a great deal from how candidates respond when the problem moves underneath them.

The four scores eventually become a broader hiring recommendation, but the categories are useful for another reason. They explain why coding interviews sometimes feel unpredictable from the candidate's side. The code is visible. Much of the evaluation happens around it.

Most candidates finish a practice problem with a binary answer: solved or not solved. Google's interview feedback is rarely that simple. The recommendation is built from dozens of smaller observations made throughout the conversation. Seeing the interview through that lens before it counts is often more useful than another evening spent solving problems alone.

Across the mock interviews behind this guide, a consistent pattern emerged. The first solution was rarely the final destination of the discussion. More often, it became the foundation for the next part of it.

A hiring committee member described the role of the opening question as establishing a baseline. A current Staff Engineer made a similar observation from a different angle. The initial problem demonstrates whether the fundamentals are there. The follow-up provides an opportunity to explore the depth behind them.

This is one reason preparation built around increasingly difficult problems often produces less return than candidates expect. The challenge in many Google coding interviews is not arriving at a solution for an unfamiliar problem. It is understanding a solution well enough to keep working with it once the original conditions no longer apply.

That distinction sits surprisingly close to everyday engineering work. Production systems rarely remain frozen long enough for a solution to be judged solely on the environment it was designed for. Requirements evolve, constraints shift, usage changes, and designs are asked to operate under conditions that were not part of the original conversation. The coding interview compresses that process into forty five minutes.

Viewed through that lens, the follow-up is not an extension of the interview. It is often the part that reveals the most. A candidate who arrives at a correct solution and a candidate who understands the solution deeply can look identical for the first half of a discussion. The difference tends to become visible once the discussion moves beyond the original problem statement.

That is also why many experienced interviewers place so much value on follow-ups.

Google's coding interviews are shorter than many candidates expect. The scheduled slot is 45 minutes, which leaves closer to 40 minutes of working time once introductions are out of the way.

That time pressure shapes the round more than many preparation guides acknowledge.

The observation is useful because it reframes what success looks like. Solving the first problem with five minutes to spare and solving it with twenty minutes to spare are not equivalent outcomes. The extra time is often where candidates get the opportunity to demonstrate how they think beyond the initial solution.

This is one reason many experienced candidates practice against the clock. A medium problem that consistently takes forty minutes in preparation is unlikely to leave much room for the rest of the interview. The goal is not speed for its own sake. The goal is preserving enough of the interview for the discussion that follows.

The same principle applies when deciding how much time to spend on intermediate steps. If a brute-force solution appears immediately and a more efficient approach is already obvious, there is usually little value in spending several minutes implementing code you know you are about to replace. Naming the brute-force approach, explaining why it is suboptimal, and moving directly to the better solution often creates more signal and preserves more time for the parts of the round that come later.

The strongest coding interviews rarely feel rushed, but they are usually paced deliberately. Time is one of the resources being managed throughout the discussion, just like memory, complexity, or system constraints.

1. Given a begin word, an end word, and a dictionary, find the shortest transformation sequence between the two words.
2. Given a sorted list of words from an unknown language, determine the order of characters in the alphabet.
3. Given a list of course prerequisites, determine whether all courses can be completed.
4. Design a data structure that supports finding the median of a stream of numbers.
5. Design a data structure that supports inserting, deleting, and retrieving the least recently used item in constant time.
6. Design an autocomplete system that returns the most relevant suggestions as a user types.
7. Given k sorted linked lists, merge them into a single sorted list as efficiently as possible.
8. Serialize and deserialize a binary tree.
9. Design a system that returns random items according to weighted probabilities.
10. Design a rate limiter that can enforce request limits across users or services.

Question lists are useful for pattern recognition. They are less useful for understanding how Google interviewers evaluate a discussion once a solution exists.

The four questions below came from real Google mock interviews. The code matters, but the more interesting signal comes from what happened after the first solution appeared. Together, they illustrate several patterns that showed up repeatedly in the interviews behind this guide: follow-ups built on an existing solution, graph questions that reward a relatively small amount of preparation, dynamic programming as a state-management exercise rather than a memorisation exercise, and design questions where implementation discipline matters as much as the design itself.

Kth Smallest Element in a BST (the follow-up is the test)

The base question is straightforward. An in-order traversal of a binary search tree visits nodes in sorted order, so the kth smallest element is simply the kth node visited during the traversal.

The implementation is not especially difficult. What matters is recognising the properties of the structure early and translating them into a solution cleanly. Time complexity is O(h + k), where h is the height of the tree, and space complexity is O(h) for the traversal stack.

The more interesting discussion from the mock arrived afterwards. The tree was no longer static. Insertions and deletions were happening continuously, and kth-smallest queries remained frequent.

The original solution still worked. It simply stopped being a particularly good answer.

Re-running an in-order traversal for every query turns a property that could be answered locally into one that repeatedly touches large parts of the tree. The more scalable approach is to augment each node with the size of its subtree. Once that information exists, the kth-smallest element can be located by walking the tree and comparing k against the size of the left subtree at each step.

The distinction is worth paying attention to because it captures the role follow-ups often play in Google interviews. The traversal was not the difficult part. The interesting question was whether the candidate recognised that the assumptions behind the traversal no longer matched the problem being discussed.

Number of Islands, then Merge by One Flip (graphs remain one of the highest-return topics)

One of the more consistent observations across the mock interviews was how frequently graph problems appeared relative to their implementation complexity.

The classic Number of Islands problem is a good example. A flood fill identifies each connected component and produces a count of distinct islands. The implementation is compact, the traversal logic is familiar, and the complexity analysis is usually straightforward.

The follow-up changes the objective without changing the underlying structure. Instead of counting islands, the task becomes identifying a water cell whose conversion to land would merge multiple islands into one.

That small change creates a different information requirement.

A count is no longer enough. The regions themselves need to remain identifiable after the traversal finishes. The natural adaptation is to label each island with a unique identifier during the flood fill and preserve those labels in the grid. Once that information exists, every water cell can be evaluated by inspecting its neighboring region identifiers.

The solution remains graph-based. The reasoning changes because the information needed from the traversal changes.

That pattern appears frequently in Google interviews. The second question often asks for different information from the same structure rather than an entirely different structure.

Longest Increasing Subarray, Replace One Element (what dynamic programming looks like now)

Dynamic programming has a reputation that is arguably larger than its current footprint in Google interviews.

The engineers behind the mock interviews consistently described it as less central than it once was. What remains useful is not memorising templates but recognising when the state required to describe a problem has expanded.

The base problem here is a simple increasing run. A single value is enough state. At any position, the only thing that matters is the length of the current run.

The follow-up changes that assumption.

Allowing a single replacement means the problem can no longer be described by one number. The solution now depends not only on the length of the current run but also on whether the replacement has already been used.

That observation is the heart of the problem. Once it is made, the implementation becomes largely mechanical. Two states are maintained at each position: one representing a run that has used no replacement and another representing a run that has already consumed its replacement.

This is a useful example because it reflects how dynamic programming tends to appear in modern interviews. The challenge is usually not recalling a template. It is recognising that the state space has changed and identifying the additional information required to model it accurately.

LRU Cache (implementation discipline matters)

LRU cache remains one of the most commonly reported Google coding questions because it combines design, implementation, and correctness in a relatively small amount of code.

The high-level design is well known. A hash map provides O(1) lookup. A doubly linked list maintains usage order. Most candidates who have prepared seriously for Google can explain that architecture.

The interview often becomes interesting after that point.

The distinction is rarely whether a candidate knows the design. It is whether they can implement the design cleanly.

The mock interviews repeatedly surfaced the same failure mode: pointer manipulation scattered throughout the implementation. The architecture remains correct, but the code accumulates edge cases and subtle bugs as node insertion and removal logic becomes duplicated across multiple methods.

The cleaner approach is to centralise pointer manipulation into a small number of helper methods and express every cache operation in terms of those helpers. Once that structure exists, the implementation becomes easier to reason about, easier to verify, and easier to extend.

That final point becomes important when the follow-up arrives.

A standard extension replaces recency-based eviction with frequency-based eviction. The implementation becomes more sophisticated, but the underlying discipline remains the same. Candidates who built the original cache around clear abstractions usually adapt comfortably. Candidates who embedded the logic directly into individual operations often find themselves rebuilding large parts of the solution.

The follow-up rewards decisions that were made long before the follow-up appeared.

One of the more useful parts of speaking with current Google interviewers is that it occasionally forces you to update assumptions that have been floating around interview preparation for years.

Dynamic programming was the clearest example.

Two interviewers, speaking independently, described essentially the same shift. One saw it as something that had been happening gradually over several years. The other placed it more recently. The exact timeline mattered less than the conclusion. Dynamic programming still appears, but it no longer occupies the position it once did in many candidates' preparation plans.

That is worth paying attention to because a great deal of software engineering interview advice still treats dynamic programming as the center of the universe. Neither interviewer suggested ignoring it. Both were careful to point out that some interviewers still ask dynamic programming questions and that candidates should be capable of handling them. The recommendation was more practical than that. Understand recursion, understand memoization, understand how to recognise when a problem requires additional state, and move on. Spending weeks memorising increasingly specialised patterns appears to produce less return than it once did.

The conversation changed noticeably when graphs came up.

There was very little uncertainty here. Graph questions appeared repeatedly in the mock interviews, repeatedly in candidate reports, and repeatedly in conversations with interviewers. More importantly, they appeared in a form that is reassuringly bounded. Breadth-first search, depth-first search, a shortest-path algorithm, topological sort, and a basic understanding of union-find cover a large percentage of what candidates are likely to encounter. Compared to the amount of preparation many engineers devote to dynamic programming, graph preparation offers a surprisingly favorable return.

The topics interviewers named most often were similarly familiar. Binary search trees, graphs, and hash maps came up repeatedly. Heaps, sliding window techniques, and two-pointer problems were also mentioned several times. There is something mildly comforting about that list. None of it is particularly fashionable. None of it reflects a new wave of interview questions. The fundamentals remain remarkably durable.

One interviewer offered an observation that tied much of it together. Their default instinct is to solve almost everything recursively before considering anything else. Trees naturally lend themselves to recursion. Backtracking is recursive by nature. Many dynamic programming solutions begin life as recursive solutions before memoization enters the picture. Even graph traversals often become easier to reason about once the recursive structure is clear.

What came from these conversations was not a radically different picture of Google interviews. If anything, it was a simpler one. The fundamentals continue to matter, the topic list remains surprisingly stable, and much of the preparation advice candidates inherit from older guides still works. The adjustment is one of emphasis. Several interviewers seem less interested in whether a candidate has memorised a large catalogue of techniques and more interested in whether they understand the underlying structures well enough to adapt them when the problem changes.

Most candidates spend months preparing for people they have never spoken to. If there are questions you still have after reading this guide, whether about leveling, story selection, what interviewers pay attention to, how hiring committees work, or how other engineers approached the round when they got in, you can spend an hour with a Google engineer in your target role and simply ask them. Sometimes the highest-leverage preparation is getting answers from someone who sits on the other side of the table.

A follow-up that came up in one of the mock interviews is worth calling out because it sits slightly outside the preparation most candidates do for coding rounds.

After the solution was complete, the discussion shifted to scale. What happens if the input no longer fits in memory?

A current Google Staff Engineer confirmed that this type of extension is common among interviewers with infrastructure and site reliability backgrounds. The important thing to understand is that the conversation is still a coding interview. The interviewer is not suddenly asking for a distributed system design.

The answer is usually much simpler than candidates assume. If the matrix no longer fits in memory, process it in chunks. If the dataset is too large for a single machine, partition it. If the computation depends on loading everything at once, discuss how it could be streamed or processed incrementally.

The discussion typically stays at that level. Nobody is looking for a full architecture diagram in the final ten minutes of a coding round.

What the interviewer is really checking is whether the solution was tied to an assumption that has just disappeared. Engineers run into this constantly in production systems. An approach works well at one scale, then a growth in data volume forces a different way of thinking about the same problem. The coding interview simply compresses that transition into a follow-up question.

If you are interviewing for a junior or mid-level software engineering role during the second half of 2026, ask your recruiter whether this round applies to you.

In May 2026, reporting from Business Insider and Entrepreneur, later confirmed by a Google spokesperson, described a pilot interview format being tested on select US teams. One traditional coding round is replaced with an open-ended code comprehension exercise. Candidates are given an existing codebase to read, debug, and improve, with Gemini available as an assistant throughout the process.

The evaluation shifts with it.

Instead of starting from an empty editor and a problem statement, candidates start with code that already exists. They are expected to understand it, identify defects, evaluate possible fixes, and decide when Gemini is helping and when it is confidently wrong. Prompting becomes part of the exercise (so does skepticism).

The pilot arrived shortly after Google disclosed that a large share of newly written code inside the company is now generated with AI assistance and reviewed by engineers. The format reflects that reality surprisingly closely. Much of modern software engineering involves understanding code that somebody else, human or machine, has already written and deciding whether it deserves to be trusted.

The underlying skills are familiar. Reading code carefully, reasoning about correctness, tracing bugs through unfamiliar systems, and reviewing proposed changes are all things software engineers do every day. The format changes. The work itself feels considerably less new.

The traditional coding round remains the standard experience for most candidates today, which is why the rest of this guide focuses on it. If this pilot applies to your process, however, spending some preparation time inside unfamiliar codebases will likely produce more return than solving a few additional algorithm problems.

Most coding interview preparation advice is broadly correct and does not need repeating here. The mock interviews behind this guide pointed to a handful of adjustments that are more specific to Google.

The mock interviews behind this guide suggest that the more useful adjustments happen around the edges of that preparation.

The clearest example is what candidates consider the end of a problem. Most preparation platforms implicitly teach you that a problem is complete once the solution passes. Many Google interviews use that moment as the starting point for the next discussion. The solution exists, the complexity is understood, and the interviewer begins exploring what happens when one of the assumptions behind it changes. That pattern appeared often enough throughout the mocks that it should influence how you practice. A problem that took twenty minutes to solve is usually worth another twenty minutes of exploration. Remove a constraint, introduce a new one, make updates frequent, or change the scale of the input and ask how much of the original solution survives.

The pacing observations from current interviewers point in the same direction. One hiring committee member suggested thinking about the round as roughly twenty minutes for the opening problem and twenty minutes for everything that follows. That framing changes the value of several common preparation habits. Spending ten minutes implementing a brute-force solution that you already know you will replace becomes much harder to justify when those ten minutes are competing with the part of the interview where follow-ups, extensions, and tradeoff discussions tend to happen.

The topic selection advice was narrower than many candidates would probably expect. Graphs came up repeatedly across interviewer conversations, candidate reports, and the mock interviews themselves. What makes them particularly attractive from a preparation perspective is that the surface area remains relatively bounded. Breadth-first search, depth-first search, topological sort, union-find, and a shortest-path algorithm cover a remarkable amount of ground. There are few places in interview preparation where a modest amount of study consistently appears across so many independent sources.

Dynamic programming produced almost the opposite conclusion. Two current Google interviewers independently described it as less central than it was several years ago, while being equally careful not to dismiss it entirely. The preparation implication is subtle. Dynamic programming still appears, but the version worth preparing for is less about memorising a catalogue of patterns and more about recognising when a problem can no longer be described by the state you are currently tracking. The worked example earlier in this guide is representative. The difficult step is often identifying the additional state. Once that happens, recursion and memoization usually provide a path forward.

Another observation that surfaced repeatedly was how early stronger candidates begin discussing complexity. Many engineers treat complexity analysis as something that happens after a solution has been implemented. Several interviewers described seeing the opposite. The approach is chosen, the expected complexity is discussed, the tradeoffs are established, and only then does the implementation begin. By the time the first line of code appears, the interviewer already understands what the candidate is trying to achieve and why.

The same principle applies to clarification. Candidates sometimes think of clarifying questions as a communication exercise when they are much closer to the way engineers approach real systems. Requirements have boundaries, assumptions deserve verification, and edge cases often determine whether a solution is correct. The strongest interviews rarely begin with immediate implementation. They begin with a short effort to understand the problem precisely enough that the implementation has somewhere solid to stand.

Prepfully Google Software Engineer Interview Guides:

• Google Software Engineer Interview Guide
• Google Software Engineer Technical Phone Screen Interview Guide
• Google Software Engineer System Design Interview Guide
• Google Googleyness and Leadership Interview Guide
• Google Software Engineer Interview Question Bank
• Google Software Engineer Mock Interview Coaches
• Mock Interviews: Google Job Interview Success

Related interview guides:

• Meta Software Engineer Interview Guide
• Amazon Software Engineer Interview Guide
• Netflix Software Engineer Interview Guide
• Spotify Software Engineer Interview Guide

Google resources:

• Google Careers
• How We Hire at Google
• Google's approach to structured interviewing
• Google's practice coding questions