Google coding interview experience

Minute fourteen of your Google coding interview experience. You've just finished explaining your plan to the interviewer. She nods and says, "Looks good, go ahead and code it." You turn to the shared editor. The problem seemed manageable when you read it. Now the cursor blinks and your hands hover over the keyboard. You aren't sure where the grid traversal should start.

What surprises most people about Google's coding interview isn't the difficulty. It's that the format tests skills LeetCode practice never trains.

The 45 minute format, minute by minute

A Google coding interview is a 45-minute session with one medium-hard algorithmic problem. Your interviewer evaluates four areas: how you break down the problem, how cleanly you code, how you verify correctness, and how you communicate throughout.

The first 3-5 minutes are introductions. The interviewer describes the problem, sometimes with a visual example on a shared doc. You're expected to ask clarifying questions. Not "What does this mean?" questions (which signal you didn't read carefully), but constraint questions: "Can the input be empty?" "Are there negative values?" "Should I optimise for time or space?" These show you're already thinking about edge cases before writing a single line.

The next 5-10 minutes are decomposition: You talk through your plan out loud. No coding yet. You're describing the solution path: "This looks like a connected components problem on a grid. I'd traverse each unvisited land cell with DFS, mark visited cells, and count the number of traversals." The interviewer might push back or ask you to consider alternatives. That's normal. It doesn't mean you're wrong.

The next 15-20 minutes are coding: You write the solution in a shared editor (Google Docs or a similar platform, not a full IDE). There's no autocomplete, no syntax checking, and no "Run" button. You're writing code that needs to be readable by a human sitting across from you. Clean variable names and logical organization matter more here than in any LeetCode session you've done.

The final 5-10 minutes are verification and follow-ups: You trace through your code with a test case, ideally one you choose that covers an edge case. The interviewer may ask about time and space complexity, or pose a follow-up variant to see how you adapt.

Google's process varies more across teams and interviewers than most preparation guides admit. Some interviewers ask two easier problems instead of one harder one. Some give more guidance during decomposition. The rubric is consistent, but the feel of the conversation isn't identical every time.

The four areas your interview is scored on

Google interviewers score candidates on a rubric. The exact rubric isn't public, but the four areas are well documented from interviewer training materials and post-interview feedback.

Problem decomposition is how you break the problem into parts. Can you identify the pattern? Are you considering brute force before optimising? An engineer who says "this is a graph traversal problem because adjacent cells form edges" is doing decomposition well. One who starts writing a nested loop without explaining why isn't.

Code quality is readability and correctness of implementation. Google doesn't care about language choice (Python, Java, C++ are all common). They care whether your code is well-organized, whether your variable names communicate intent, and whether someone reading your solution could follow the logic without you explaining it.

Verification means you test your own work. You trace through a test case. You catch edge cases before the interviewer points them out. The strongest signal here is self-correction. Finding an off-by-one error during your trace, before being asked, is worth more than getting it right the first time silently.

Communication runs through the entire session. You're expected to think out loud, explain trade-offs, and respond to hints. Silence is a negative signal at Google, not a neutral one. An interviewer can't give you credit for reasoning they can't hear.

For a detailed breakdown of how these areas map to hiring decisions, see what Google actually evaluates in coding interviews.

Strong vs passing vs failing: One problem, three outcomes

Take the island count problem. You're given a 2D grid of 1s (land) and 0s (water). Count the number of islands, where an island is a group of adjacent land cells connected horizontally or vertically.

This is a connected components problem on a grid. Three engineers, three very different outcomes.

The strong candidate finishes in 15 minutes with a clear pass. She reads the problem, asks "Can islands touch diagonally?" (no), and within 2 minutes says "This is connected components on a grid. Each island is a component. I'll DFS from each unvisited land cell and count traversals." She codes the solution above cleanly. During verification, she traces a 3x3 grid with two islands, catches that she needs to handle the empty grid case, adds the check, and states the complexity: O(m * n) time, O(m * n) worst-case stack depth. Twelve minutes remain for the follow-up.

The passing candidate finishes in 30 minutes, borderline. He recognises it's a grid problem but takes 8 minutes trying BFS before switching to DFS. The code works but uses a separate visited set instead of modifying the grid in place, which doubles space usage. He tests with one example but doesn't check the empty grid case. When asked about complexity, he gets time right but hesitates on space.

The failing candidate doesn't finish. She starts coding immediately, writing a double loop that counts 1s without any traversal logic. After 15 minutes of debugging, she asks "Should I use DFS here?" but can't explain why. The code eventually handles simple cases but fails on grids where islands span multiple cells. She never attempts verification, and when asked about alternatives, she has nothing to offer.

The patterns Google tests most

Google's interview questions cluster around specific algorithmic patterns. The selection is deliberate. They're testing whether you can reason through algorithms, not whether you've memorized solutions.

From Codeintuition's problem data tagged across 90+ companies, Google's pattern preferences stand out in a few areas:

LeetCode's company tags for Google are actually fairly accurate for pattern types, even if the specific problems rotate. Sort Google-tagged problems by pattern rather than by difficulty and you get a reasonable map of what to expect. But knowing which patterns to study and being able to identify them in an unfamiliar problem are different skills entirely.

For a breakdown of how much DSA scope Google actually expects, see how much DSA you need for a Google interview.

Where your insterview falls apart

The rubric exposes specific gaps that don't show up during practice.

The decomposition gap is real. If you've been solving problems by jumping straight to code, you haven't trained the skill Google scores first. The fix is simple but uncomfortable: for every problem in your practice, spend 3 minutes describing your plan out loud before touching the keyboard. Record yourself if you can stand it. It feels weird at first. You get used to it.

Then there's the verification gap. Most engineers never trace through their own code after writing it. Why would you? On LeetCode, you click "Run" and the test suite handles it. In a Google interview, there's no Run button. You trace through a test case manually, which means mental dry running needs to be a practised skill, not just a concept you've heard of.

The pattern identification gap matters most. You can know every pattern on the 15 most common patterns list and still freeze if you can't identify which one a novel problem requires. Google's Predicate Search problems, for instance, look nothing like standard binary search on the surface. Without practising identification specifically (reading problem constraints and mapping them to patterns), the gap between your preparation and the actual interview only grows.

Codeintuition's Graph course teaches the connected components pattern with an identification lesson before any problem-solving begins. The lesson trains you to read grid constraints and recognise when a problem asks for connected region counting versus shortest path versus cycle detection. That's the difference between the strong candidate and the failing one in the example above.

Closing the gap before your interview

For the full preparation framework, including timelines and pattern ordering, see the FAANG coding interview preparation playbook.

Codeintuition's learning path covers 75+ patterns with identification training built into every module, starting from the connected components identification you saw above. The free tier gets you two complete courses (63 lessons, 85 problems, 15 patterns) with no time limit and no payment required.

Six months from now, you walk into a Google interview. The interviewer presents a grid problem. You don't panic. You recognise the constraint pattern within 90 seconds, name it, and describe your plan before touching the editor. Twenty-two minutes later, you finish the follow-up. The interviewer writes "strong hire." You won't find out for another week, but you already know.