Google Coding Interview Prep Plan: A 4-Week Schedule
A Google interview invite tends to trigger the same reaction: open a giant problem list, start at number one, and hope it adds up to readiness. Usually it doesn't. A list measures how many problems you have touched, not whether you can solve an unfamiliar one while explaining your thinking to a stranger.
This Google coding interview prep plan covers four weeks for someone who can already write working code in one language. It focuses on the skills candidates commonly report being tested: solving a problem you haven't seen, writing clean code without an IDE, and reasoning about complexity out loud. It does not claim to know Google's internal rubric. Formats change and differ by team and level, so check the details with your recruiter. They are usually happy to explain the round types, the coding environment, and how much time you get.
Before week 1: ask the recruiter four questions
Do this before you plan anything:
- How many coding rounds are there, and how long is each one?
- What environment do candidates code in (shared doc, online editor, whiteboard)? Can I run code?
- Is there a behavioral or role-related round, and what does it cover?
- Are any rounds specific to my level or team, such as system design for senior roles?
Candidates commonly report coding in an editor without autocomplete or execution, and rounds of roughly 45 minutes. Treat that as something to confirm, not something to assume. Whatever the recruiter says becomes your practice environment for the next four weeks.
The 4-week plan at a glance
| Week | Focus | Daily target (about 90 min) |
|---|---|---|
| 1 | Core patterns, plain-editor coding | 2 problems, narrated |
| 2 | Trees, graphs, recursion | 2 problems + 1 re-solve |
| 3 | Harder variants, follow-up questions | 1–2 problems + follow-ups |
| 4 | Full timed mocks, review, rest | 1 mock or 2 timed problems |
If you have more than four weeks, stretch weeks 1–2. Don't add more patterns. Breadth matters less than doing the basics reliably while someone watches.
Week 1: patterns in a plain editor
Turn off autocomplete. Better still, practice in a plain text editor or a shared doc. The goal is to get used to writing code you can't run.
Patterns to cover:
- Hash maps for counting, lookup, and de-duplication
- Two pointers on sorted arrays and strings
- Sliding window for substrings and subarrays
- Sorting plus a linear pass (intervals, meeting rooms)
- Binary search on a sorted array, then binary search on the answer
- Stack for bracket matching and "next greater element"
For every problem, follow the same five steps:
- Restate the problem in one sentence.
- Ask two clarifying questions (input size, empty input, duplicates, negative numbers).
- State the brute force and its complexity.
- Improve it if you can, and say why it's faster.
- Dry-run one normal case and one edge case by hand.
Step 5 is the one people skip, and without a "Run" button it's how you catch your own bugs.
Week 2: trees, graphs, and recursion
Many candidates say tree and graph problems come up often in coding rounds. Even if they don't in yours, these problems build the recursion and traversal habits that most medium problems rely on.
- Binary tree traversals: pre-, in-, and post-order, plus level order with a queue
- Recursive helpers that return more than one value (height plus balanced, for example)
- BFS on a grid, then on an adjacency list
- DFS with a visited set, and cycle detection
- Topological sort for dependency problems
Re-solve one problem from week 1 every day without looking at your old solution. If it takes as long as it did the first time, you memorized the answer instead of the pattern.
Week 3: harder variants and follow-ups
Candidates often report that the first version of a problem is followed by a twist: "What if the input doesn't fit in memory?", "What if this is called millions of times?", "Can you do it in place?" Practice for that directly.
After you solve a problem, write down three follow-ups and answer each in two or three sentences:
| Follow-up type | Example question | What to talk about |
|---|---|---|
| Scale | Input is too large for one machine | Chunking, streaming, external sort |
| Repeated calls | Function is called many times | Pre-computation, caching, indexes |
| Constraints | Must be O(1) extra space | In-place tricks, two pointers |
| Data change | Input arrives as a stream | Heaps, running aggregates |
You don't need perfect answers. Interviewers generally want to see you reason about tradeoffs instead of going quiet.
Week 4: run it like the real thing
Book two or three full mock sessions: a friend, a peer platform, or a solo timed session where you record yourself. Use the format your recruiter described. If that's a 45-minute round with intros and questions at the end, budget roughly:
| Minutes | Activity |
|---|---|
| 0–5 | Intros, read the problem, clarify |
| 5–10 | Brute force, better approach, agree on a plan |
| 10–30 | Code it, narrating the key decisions |
| 30–38 | Dry run, edge cases, fix bugs |
| 38–45 | Follow-up discussion or your questions |
In the last two days, stop learning new material. Re-solve favorites, read through your error log, and sleep.
Talking about complexity without stalling
Plan to state complexity for every solution without being asked. Keep it short:
"This is O(n log n) time because of the sort, and O(n) extra space for the output. The scan after sorting is linear."
If you're not sure, reason out loud instead of guessing: "The outer loop is n, and the inner loop moves the pointer forward without resetting, so the total is linear."
Don't skip the behavioral round
Candidates commonly describe a behavioral or role-related conversation as part of the loop. Prepare four or five stories (a conflict, a failure, a project you drove, an ambiguous situation, helping a teammate) and practice telling each one in about two minutes. Your recruiter can tell you what that round focuses on.
Common prep mistakes
- Grinding problems silently and never narrating
- Practicing only with autocomplete and a Run button
- Skipping clarifying questions because "it's obvious"
- Memorizing solutions to well-known problems instead of learning the patterns behind them
- Treating forum posts about "the exact questions" as reliable
- Cramming new topics the night before
Soft practice note
Most of this plan comes down to practicing out loud under realistic conditions: a timer, a plain editor, and nobody to give you hints. If you want a structured way to run those sessions and stay calm while you do, Luna Interview is built for rehearsal and prep. It's for practice before the interview, not a way around the rules during one.
Day-before checklist
- [ ] Round format and environment confirmed with the recruiter
- [ ] Five-step routine (restate, clarify, brute force, improve, dry run) on autopilot
- [ ] Complexity sentence rehearsed
- [ ] Four or five behavioral stories, two minutes each
- [ ] Error log read once
- [ ] Laptop charged, audio tested, quiet room booked
- [ ] Early night
Four weeks won't make you a different engineer. They can make you a calm, clear one who shows how you think, and that's the part you control.
Rehearse with an AI interview copilot, then work through commonly reported Google interview questions.