Google SWE Interview: Onsite Coding Rounds Guide

Estimated read time: 8-10 minutes

Summary: Google SWE onsite coding rounds are the core technical signal in the final loop. The research describes two to three roughly 45-minute coding interviews, usually with engineers, where the same fundamentals from the phone screen are tested under more repeated pressure. This guide explains what changes in the onsite loop, what questions to expect, and how to avoid letting one weak follow-up affect the packet.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• The final loop commonly includes two to three coding rounds, each around 45 minutes.
• Interviewers are usually Google engineers.
• The format may be virtual or onsite, with shared docs or whiteboard-style tools.
• Secondary feedback says one to two phone screens can precede onsite, and rare process variants may skip a phone screen.
• Google evaluates coding, role-related knowledge, general problem solving, leadership, and Googleyness across the loop.
• AI remains prohibited unless Google explicitly tells you otherwise.

Quick FAQ

Are onsite coding rounds harder than the phone screen?
The mechanics are similar, but the final loop repeats the signal and may go deeper with follow-ups.

How many coding rounds should I expect?
The source research reports two to three coding rounds in the final loop.

Who interviews me?
Engineers, senior engineers, and sometimes managers may participate in the final loop.

Do senior candidates still get coding?
Yes. The source research says coding is expected across levels, though system design and leadership signals matter more at senior levels.

---

1) How onsite coding differs from the phone screen

The onsite coding rounds use similar muscles to the technical screen: data structures, algorithms, communication, edge cases, and complexity. The difference is repetition. You may need to show the same disciplined process across several interviews with different engineers.

The source research describes virtual or onsite coding, shared documents, whiteboard-style tools, and roughly 45-minute sessions. Coding rounds are independent signals that later feed into packet review. That means consistency matters.

Do this instead of trying to be brilliant: be reliably clear. Clarify, solve, verify, and explain tradeoffs every time. Secondary feedback also says rare coding rounds may become more about deriving and explaining the optimal solution than writing every line of code, but you should still prepare to code cleanly under time pressure.

---

2) Questions you may face in Google SWE onsite coding

The research source lists coding questions that can appear in technical screens or final-loop coding. In the final loop, expect the interviewer to push past the base task with edge cases, constraint changes, or a request to explain why your approach is correct.

• Implement a Trie with insert, search, and startsWith. Once the base version works, support duplicate inserts and explain whether delete would change your node structure.
• Merge two sorted arrays in place. First assume the destination array has enough trailing capacity. Then solve the version where it does not.
• Return all unique triplets that sum to zero. Explain your duplicate-handling strategy before coding, then test it on an input with repeated values.
• Implement Snapshot Array. Now reason about memory if set is called many times before each snap, and optimize for sparse updates.
• Write the robot room cleaner algorithm when the robot only exposes move, turn, and clean. Blocked cells are discovered only by attempting to move.
• Mirror a binary tree in place. After coding, dry-run it on a skewed tree, a single-node tree, and an empty tree.
• Find the lowest common ancestor in a binary tree. Then adapt the solution for a binary search tree and compare the complexity.
• Detect a cycle in a directed graph. If a cycle exists, return one valid cycle instead of only returning true.
• Find the maximum path sum in a binary tree. Walk through how your helper handles paths that can be extended upward versus paths that terminate at the current node.
• Generate all sequences of 1s and 2s that sum to n. Then count the sequences without generating every one.

---

3) Signals that compound across multiple rounds

In one coding round, a small communication issue might look like nerves. Across several rounds, it becomes a pattern. That is why Google onsite coding rewards repeatable habits.

Positive signals include structured problem solving, clean code, complexity analysis, manual verification, and collaboration with the interviewer. The source research also highlights general cognitive ability and role-related knowledge in the final loop, so the interviewer may care about how you reason through unfamiliar follow-ups, not only whether you have seen the pattern before.

Cognitive flexibility is part of that signal. If a constraint changes, do not keep forcing the old solution. Pause, restate the new constraint, then adjust the data structure or algorithm out loud.

For senior candidates, coding remains relevant, but the bar may include more tradeoff discussion and deeper follow-up probes.

---

4) Failure modes that hurt final-loop feedback

Rushing after a previous round felt bad. Each round is a fresh signal. Do not carry panic forward.

Solving silently. The source emphasizes communication and reasoning. Silence makes the interviewer infer too much.

Leaving correctness implicit. Walk through examples and edge cases before the interviewer has to ask.

Overfitting to memorized solutions. Google-style follow-ups can expose memorization quickly.

Assuming a familiar-looking question is easy. Secondary feedback warns that a simple statement may hide edge cases or a harder follow-up. Clarify before committing.

Ignoring the AI policy. The source research says AI use is prohibited unless explicitly allowed.

---

5) How to prepare for repeated coding signal

Prepare as if you need to deliver a strong, consistent process three times in a row. That means pacing matters as much as problem coverage.

• Practice 45-minute sessions with no execution and a spoken walkthrough.
• Rotate through graphs, trees, arrays, recursion, backtracking, and data structures.
• Add dynamic programming to your rotation, then practice explaining the recurrence in plain text.
• After each solution, explain complexity and one follow-up optimization.
• Run manual test cases out loud, including the edge case most likely to break the code.
• Dry-run for intent, not only output. Check that the code you wrote matches the algorithm you described.
• Practice resetting between rounds so one rough interview does not affect the next one.

The final loop is not looking for one lucky solve. It is looking for a pattern of technical judgment under interview constraints.

---