The Interview Format (Your Google Interview)

Based on your recruiter email, your coding interviews are:

  • 2 sessions × 45 minutes each

  • Format: Live coding on a Google Doc or shared editor (no IDE, no autocomplete!)

  • You’ll be asked 1-2 algorithm problems per session

  • Evaluated on: correctness, efficiency, code quality, communication

The 4-Week Study Plan

Week 1: Foundation (Chapters 00-04)

Day 1-2

Ch 00: Python Toolkit — run every code file, internalize Big-O of each operation

Day 3

Ch 01: Big-O — practice analyzing complexity of 5 functions from memory

Day 4-5

Ch 02: Arrays/Strings — Two Sum (nail the hash map solution), Sliding Window

Day 6

Ch 03: Hash Tables — implement from scratch, know collision handling

Day 7

Ch 04: Sorting — implement Merge Sort from scratch, understand QuickSort

Week 2: Core Patterns (Chapters 05-09)

Day 8

Ch 05: Recursion — Permutations, Subsets (know the backtracking template cold)

Day 9-10

Ch 06: Binary Search — all variants, practice on Rotated Array

Day 11

Ch 07: Linked Lists — Reverse (both ways), cycle detection

Day 12-13

Ch 08: Trees ⭐ — traversals (iterative!), BST validation, LCA

Day 14

Ch 09: Graphs ⭐⭐ — BFS/DFS, Number of Islands, Shortest Bridge

Week 3: Advanced Techniques (Chapters 10-13)

Day 15-16

Ch 10: DP — Coin Change, Climbing Stairs, LCS pattern

Day 17

Ch 11: Heaps — Top K pattern, understand heapq

Day 18

Ch 12: Stacks/Queues — Valid Parentheses, Min Stack, monotonic stack

Day 19

Ch 13: Union-Find — know the template, apply to Redundant Connection

Day 20-21

Practice day: Solve 3-4 problems from LeetCode without looking at solutions

Week 4: Simulation and Review

Day 22-23

Timed practice: Solve problems on a Google Doc (not IDE!) in 25 minutes each

Day 24-25

Review weak areas — re-solve problems you struggled with

Day 26

Mock interview: Have a friend watch you solve a problem and provide feedback

Day 27

Light review — pattern recognition, no new problems

Day 28

Rest — get a good night’s sleep before the interview

The 5-Minute Framework (For Each Problem)

Minute 0-1: Understand

  • Read the problem carefully. Restate it in your own words to the interviewer.

  • Ask clarifying questions:

    • "What are the input constraints? (size, value range)"

    • "Are there duplicates? Is the input sorted?"

    • "Should I handle empty/null input?"

  • Write 2-3 examples, including edge cases.

Minute 1-3: Plan

  • State the brute force approach out loud: "The brute force would be O(n²) using two loops…​"

  • Then propose the optimal: "But we can use a hash map to achieve O(n)…​"

  • Talk through WHY the optimization works.

  • Get interviewer buy-in before coding: "Does this approach sound good?"

Minute 3-8: Code

  • Write clean, readable code. Use descriptive variable names.

  • Talk as you code: "I’m iterating through the array and storing each complement in the hash map…​"

  • Don’t get stuck on syntax — the interviewer cares about logic, not semicolons.

Minute 8-10: Verify

  • Trace through your code with the first example. Step by step.

  • Check edge cases mentally.

  • State the time and space complexity.

What to Say (Script Templates)

When You’re Stuck

"Let me think about this for a moment. I’m considering whether a [hash map / two-pointer / BFS] approach might work here…​"

When You See the Problem

"This looks like a [graph connectivity / sliding window / DP] problem because [the input is a grid / we need a subarray / we have overlapping subproblems]."

When Discussing Tradeoffs

"The brute force is O(n²) time with O(1) space. We can optimize to O(n) time by using O(n) space for a hash map. This is the classic time-space tradeoff."

When You Make a Mistake

"Ah, I see the issue — I’m not handling the case where [edge case]. Let me fix that." (Don’t panic. Mistakes are expected. Recovering gracefully shows maturity.)

Common Mistakes to Avoid

  1. Jumping to code too fast — Always discuss approach first

  2. Silent coding — Keep talking! Silence = the interviewer can’t evaluate your thinking

  3. Not asking clarifying questions — This shows you make assumptions instead of clarifying requirements

  4. Ignoring edge cases — Empty input, single element, negative numbers, duplicates

  5. Not testing your code — Always trace through at least one example

  6. Over-optimizing — Get a working solution first, then optimize

  7. Forgetting Big-O — Always state time and space complexity

Pattern Recognition Cheat Sheet

If you see…​ Think…​

Sorted array

Binary search, two pointers

"Top K" or "Kth"

Heap (min-heap of size k)

Subarray/substring with property

Sliding window

Pair/triplet that sums to X

Hash map or two pointers (sorted)

2D grid traversal

BFS or DFS (grid IS the graph!)

"Minimum steps" or shortest path

BFS

"All possible" combinations

Backtracking

Overlapping subproblems

Dynamic Programming

Tree structure

DFS (recursive), BFS (level-order)

"Connected components"

Union-Find or BFS/DFS

Matching brackets

Stack

Next greater/smaller

Monotonic stack

Dependencies / ordering

Topological sort (DAG)

The Night Before

  1. Don’t study new topics. Review your strongest patterns.

  2. Prepare your environment (water, quiet room, charger).

  3. Sleep well — cognitive performance drops significantly with poor sleep.

  4. Remember: even if this doesn’t go perfectly, you can try again later. The knowledge you’ve built is permanent.

You’ve got this. You’ve worked through data representations, algorithm patterns, and optimization techniques. You know WHAT to think when you see a problem, and you know HOW to communicate your thinking. That’s what Google is looking for.