This guide is designed for senior full-stack developers (15+ years experience) who build systems well but rarely implement algorithms. Your goal: solve 2-3 medium/hard LeetCode problems correctly in 45 minutes, twice, under interview conditions.

The 3-4 Week Schedule

The following schedule assumes 2-3 hours/weekday, 4-5 hours/weekend. Adjust based on your pace, but stick to the weekly themes.

Week 1: Foundations & Data Structures (7 days)

Theme: Understand how data structures work at a nuts-and-bolts level. Big O is vocabulary, not trivia.

Monday-Wednesday (2.5 hours/day)

  • Day 1: Big O Analysis (3 hours)

    • Study 01-big-o.adoc: Read notation, practice analyzing real code snippets

    • Why: You must explain time/space complexity out loud. Interviewers listen for this.

    • Exercise: Write 3 functions, predict Big O before calculating. Compare.

  • Day 2: Arrays & Strings (2.5 hours)

    • Study 02-arrays-strings.adoc

    • Solve 3 problems: Two Sum, Best Time to Buy/Sell Stock, Reverse String

    • Focus: Why does a hash table help? What about arrays makes iteration O(n)?

  • Day 3: Hash Tables/Maps/Sets (2.5 hours)

    • Study 03-hash-tables.adoc

    • Understand collision, load factor, why Map/Set exist in JS

    • Solve 2 problems: Valid Anagram, Group Anagrams

    • Hands-on: When is Map better than object? (spoiler: keytypes)

Thursday-Friday (2.5 hours/day)

  • Day 4: Linked Lists (2.5 hours)

    • Study 04-linked-lists.adoc

    • Solve 2 problems: Reverse Linked List, Merge Sorted Lists

    • Key insight: Why O(1) insertion doesn’t help if you need O(n) search first?

  • Day 5: Stacks & Queues (2.5 hours)

    • Study 05-stacks-queues.adoc

    • Solve 3 problems: Valid Parentheses, Min Stack, Number of Recent Calls

    • Implement both using arrays (understand push/pop vs shift/unshift cost)

Saturday-Sunday (5 hours each = 10 hours total)

  • Day 6-7: Practice & Consolidate (10 hours total)

    • Solve 6-8 problems from Week 1 categories

    • Mix: 2 problems you haven’t seen, 2 variations of ones you solved

    • Time yourself: 20 min per problem, then study solution

    • No rushing—depth > breadth this week

By end of Week 1: You can explain why arrays are O(1) access, hash tables O(1) lookup, and when to reach for each.

Week 2: Trees, Graphs & Sorting (7 days)

Theme: Navigate hierarchical and networked data. Learn the two fundamental graph traversals.

Monday-Wednesday (2.5 hours/day)

  • Day 1: Binary Trees & Traversals (2.5 hours)

    • Study 06-binary-trees.adoc

    • Understand in-order, pre-order, post-order (not memorize—understand)

    • Implement all three iteratively and recursively

    • Solve 2 problems: Invert Binary Tree, Maximum Depth of Binary Tree

  • Day 2: Binary Search Trees (2.5 hours)

    • Study 07-bst.adoc

    • Solve 3 problems: Validate BST, Lowest Common Ancestor, Insert/Search

    • Key: Why is BST search O(log n) in the average case?

  • Day 3: Graphs & BFS (2.5 hours)

    • Study 08-graphs.adoc (BFS section)

    • Understand: adjacency list vs adjacency matrix

    • Solve 3 problems: Number of Islands, Binary Tree Level Order Traversal, Walls and Gates

    • BFS = queue. Practice building adjacency lists first.

Thursday-Friday (2.5 hours/day)

  • Day 4: Graphs & DFS (2.5 hours)

    • Study 08-graphs.adoc (DFS section)

    • DFS = recursion or stack. Solve 3 problems using both approaches.

    • Problems: Clone Graph, Course Schedule (cycle detection), Pacific Atlantic Water Flow

    • Compare DFS vs BFS for same problem—understand trade-offs

  • Day 5: Sorting (2.5 hours)

    • Study 09-sorting.adoc

    • Focus: Merge Sort (O(n log n), stable), Quick Sort (O(n log n) avg, in-place)

    • Implement both. Understand why O(n) counting sort doesn’t help here.

    • You probably won’t need to sort, but understand when each is useful

Saturday-Sunday (10 hours total)

  • Day 6-7: Practice Trees, Graphs, Sorting (10 hours)

    • Solve 8-10 problems mixing all Week 2 topics

    • Do at least 2 graph problems you haven’t seen before

    • Time yourself: 25 min per problem

    • Study solutions, then re-solve from scratch next day

By end of Week 2: You can draw a graph from scratch, implement BFS/DFS, explain when to use each, and trace through tree traversals.

Week 3: Advanced Patterns (7 days)

Theme: Algorithmic techniques. These are levers that make hard problems solvable.

Monday-Wednesday (2.5 hours/day)

  • Day 1: Sliding Window & Two Pointers (2.5 hours)

    • Study 10-sliding-window-two-pointers.adoc

    • These are not separate—both are pattern recognition

    • Solve 4 problems: Longest Substring Without Repeating, Container With Most Water, 3Sum, Minimum Window Substring

    • Pattern: "Can I expand a window?" or "Can I use two pointers?"

  • Day 2: Dynamic Programming, Part 1 (2.5 hours)

    • Study 11-dp-part1.adoc (Memoization & Recursion)

    • DP is terrifying if you don’t get it. Start with memoization (it’s caching recursion results)

    • Solve 3 problems: Fibonacci, Climbing Stairs, Coin Change

    • Each problem: write naive recursive → trace and see repeated calls → add memo → verify it works

  • Day 3: Dynamic Programming, Part 2 (2.5 hours)

    • Study 11-dp-part2.adoc (Tabulation & 2D DP)

    • Build a table instead of memoizing recursion (bottom-up)

    • Solve 3 problems: House Robber, Longest Increasing Subsequence, Unique Paths

    • Key: Understand DP state and transitions (not formulas—relationships)

Thursday-Friday (2.5 hours/day)

  • Day 4: Backtracking (2.5 hours)

    • Study 12-backtracking.adoc

    • Backtracking = explore all possibilities, prune when not viable

    • Solve 3 problems: Permutations, Combinations, N-Queens (or Sudoku Solver)

    • Pattern recognition: "Generate all…​" or "Find all possible…​" → backtracking

  • Day 5: Mixed Patterns & Gaps (2.5 hours)

    • Identify your weakest Week 1-3 topic

    • Solve 4 problems in that area

    • If balanced, solve 2 medium DP and 2 medium graph problems

Saturday-Sunday (10 hours)

  • Day 6-7: Timed Problem Practice (10 hours)

    • Solve 8-10 problems, mix from all patterns

    • Set a timer: 30 min per problem

    • Write code in a Google Doc (practice the medium where you’ll actually interview)

    • After solving: trace through with test cases manually (no IDE to run it)

    • Study solutions, sleep on it, re-solve next day

By end of Week 3: You recognize sliding window, two pointers, DP, and backtracking problems. You know which lever to pull.

Week 4: Mock Interviews & Polish (7 days)

Theme: Pressure, communication, speed. Simulate the real thing.

Monday-Wednesday (3 hours/day)

  • Day 1: Full Mock Interview (3 hours)

    • Set timer: 45 minutes

    • Use a Google Doc (no IDE)

    • Pick a medium LeetCode problem you’ve never seen

    • Go: read problem, clarify, plan, code, test, optimize—all in 45 min

    • After: review your solution, identify what slowed you down

    • Log: What did you do well? What was rushed?

  • Day 2: Review Week 1-3, Focus on Weak Spots (3 hours)

    • Go back to problems you got wrong or went slow on

    • Time yourself again on 3-4 of them

    • This time, focus on clean code and clear explanation (say it out loud!)

  • Day 3: Full Mock Interview #2 (3 hours)

    • Different problem, same format: 45 min, Google Doc, real conditions

    • Timer: 2-3 min clarify, 5-7 min plan, 20-25 min code, 5-8 min test

Thursday-Friday (3 hours/day)

  • Day 4: Problem Variations (3 hours)

    • Pick 3 problems from Week 3 and solve small variations

    • Example: If you solved "2Sum", solve "3Sum", then "4Sum"

    • Goal: See how one problem can adapt; build confidence in pattern transfer

  • Day 5: Communication Dry Run (3 hours)

    • Solve 2 problems with a friend (or voice recorder)

    • Narrate everything: "I’ll use a hash map here because…​", "Let me trace through with [1, 2, 3]…​"

    • Practice the phrases in section 12-interview-tips.adoc

    • Get feedback on: Did you explain your thinking? Was code hard to follow? Anything unclear?

Saturday-Sunday (10 hours)

  • Day 6-7: Stress Test (10 hours)

    • 2 more full 45-min mock interviews (6 hours)

    • Pick problems you’ve never seen

    • Vary difficulty: 1 medium-ish, 1 actually medium

    • Between mocks: review your previous weak spots (1 hour), re-solve in Google Doc (3 hours)

    • Log successes and lingering gaps

By end of Week 4: You’ve done 4+ full mock interviews. You know your pace. You know what to focus on in your actual interview prep days.

Neuroscience-Based Learning Strategy

Learning algorithms requires building new neural pathways. Here’s why your intuitions are likely wrong, and what actually works.

Why Passive Learning Fails

The YouTube Trap

Watching coding tutorials feels productive. Your brain lights up with recognition ("Oh yeah, I know maps!"), and your dopamine spikes. But this is false confidence. Here’s why:

  1. Encoding specificity: Your brain encodes the context of the tutorial (the teacher’s voice, the problem layout). When you face a different problem in an interview, your brain doesn’t find the same neural pattern. The knowledge doesn’t transfer.

  2. No struggle = weak encoding: Neuroscience research (Bjork’s "desirable difficulty") shows that learning requires struggle. When you watch someone solve a problem, your brain is passive. The neural pathways formed are weak and fragile.

  3. Recognition ≠ Recall: Watching lets you recognize a solution. Solving from scratch requires recall—retrieving knowledge from memory under time pressure. These are different neural processes.

If you spend 3 hours watching tutorials and 0 hours solving, your neural pathways for watching are strong, but your pathways for solving novel problems under pressure are weak. This is why you’ll feel prepared and then freeze in the interview.

What Actually Works: The Science

1. Active Recall (The Testing Effect)

The strongest way to build memory is testing yourself. This isn’t quizzing yourself at the end—it’s the core of learning.

  • Solve problem without looking at solution (20-30 min)

  • Get stuck? That’s where learning happens. Brain searching for knowledge is stronger than brain passively receiving it

  • After struggle, look at solution. Brain is now primed for that information

  • Next day: solve the same problem from scratch (without looking at yesterday’s work)

  • Spacing between attempts (24 hours) matters; sleep consolidates memories

Your hippocampus (memory hub) consolidates information during sleep. If you learn something and sleep on it, the memory transfers to long-term cortical storage. This is why solving problems, sleeping, then re-solving next day is more effective than grinding 6 hours straight.

2. Interleaving (Mixing, Not Blocking)

A trap: solving all hash table problems in a row, then all tree problems.

Better: on a problem set, randomize the order. 1 hash problem, 1 tree, 1 DP, 1 string, 1 hash, etc. Why?

  • Blocking: Your brain gets into "hash table mode" and solves via context, not pattern recognition

  • Interleaving: Forces your brain to identify which technique applies, then apply it

  • In an interview, you see 1 random problem. Interleaving trains that scenario

3. Chunking (Building Abstractions)

Early on, "hash table" might feel like a monolith. With practice:

  • Week 1: You understand Map/Set, basic lookup

  • Week 2: You recognize "I need fast lookup—use a map"

  • Week 3: You chunk "fast lookup" into a sub-goal; don’t think about maps, just "I need O(1) lookup here"

  • Week 4: "Hash map" is one atomic concept; your brain retrieves the entire abstraction instantly

This is chunking. Deep expertise is high-level chunking: you see a problem and immediately chunk it into sub-problems and techniques.

4. Variability (Transfer Learning)

Solving the same problem type repeatedly doesn’t transfer well. Solving variants does.

  • Solve Climbing Stairs

  • Solve Unique Paths (different context, same DP pattern)

  • Solve Coin Change (different context, same pattern)

Variability forces your brain to extract the underlying pattern, not just memorize "here’s how we solve Climbing Stairs."

The Practice Protocol That Works

Follow this for every problem you solve:

Phase 1: Struggle (20-30 min, timer)

  1. Read the problem 2-3 times until you understand it

  2. Do NOT look at hints or solutions

  3. Write out your approach (high-level, not code)

  4. Code your solution in a Google Doc (if you’re training for the interview format)

  5. Attempt to trace through with test cases

  6. If stuck after 25 min, then look at a hint (not the full solution)

  7. If still stuck after 30 min, look at the solution

The struggle is the point. Your brain is searching its knowledge for what applies. This search is the neural building process.

Phase 2: Study (10-15 min)

  1. Read the solution code carefully

  2. Trace through with 2-3 examples

  3. Understand why this approach is correct

  4. Understand the time/space trade-offs

  5. Do NOT try to memorize the code—understand the logic

Phase 3: Rest (8+ hours, ideally sleep)

  1. Do something else

  2. Sleep is crucial; memories consolidate during sleep

Phase 4: Reconstruct (20-30 min, next day)

  1. Close all references

  2. Solve the same problem again from scratch

  3. Does it feel easier? It should

  4. If you get stuck in different spots, note it—that’s a real weak point

Phase 5: Variation (20-30 min, later)

  1. Solve a variant of the problem (different context, same pattern)

  2. Example: If you solved "2Sum", solve "3Sum"

  3. This forces pattern transfer

Deliberate Practice Checklist

Before each study session:

  • Timer is set (don’t exceed time limits)

  • No IDE/compiler (you’re training for a Google Doc)

  • No looking at solutions during Phase 1 (unless truly stuck past 25 min)

  • Tracing through with examples (mental execution, not running code)

  • Explaining out loud (why this approach, what’s the insight)

  • Recording weak points (what made you slow, what made you stuck)

  • Planning a return: When will you re-solve this? When will you try a variant?

Tracking Progress

Keep a simple log:

Date | Problem | Time | Result | Notes
2026-03-20 | Two Sum | 18 min | Correct | Hash map approach clear
2026-03-20 | Best Time to Buy Stock | 32 min | Correct but slow | Missed single-pass optimization
2026-03-21 | Two Sum (re-solve) | 12 min | Correct | Faster; understood deeper
2026-03-21 | 3Sum | 28 min | Correct | Pattern transfer worked

This log shows:

  1. Speed improvements (Two Sum: 18 min → 12 min)

  2. Pattern transfer (learned Two Sum, applied to 3Sum faster)

  3. Weak areas (Best Time to Buy Stock optimization)

Use this to decide what to drill next.

Sleep & Consolidation

Schedule your week deliberately:

  • Study new material Monday-Thursday

  • Solve and re-solve Thursday-Saturday

  • Mock interviews Sunday

  • Why? By Sunday, you’ve slept 3-4 times on the material, consolidating it

Don’t expect to remember DP on Monday and solve it perfectly Wednesday. The timeline is:

  1. Monday: Learn DP concept, solve first problem (slow)

  2. Tuesday: Solve different DP problem (still slow, but faster)

  3. Wednesday night: Sleep (consolidation)

  4. Thursday: Re-solve Monday and Tuesday problems (much faster, deeper understanding)

  5. Friday: Harder DP problems feel more accessible

This is why the 4-week schedule spreads topics out, with weekends for practice and consolidation.

How to Use This Guide

File Structure

google-interview/
├── 00-study-plan.adoc              (← You are here)
├── 01-big-o.adoc
├── 02-arrays-strings.adoc
├── 03-hash-tables.adoc
├── 04-linked-lists.adoc
├── 05-stacks-queues.adoc
├── 06-binary-trees.adoc
├── 07-bst.adoc
├── 08-graphs.adoc
├── 09-sorting.adoc
├── 10-sliding-window-two-pointers.adoc
├── 11-dp-part1.adoc
├── 11-dp-part2.adoc
├── 12-backtracking.adoc
├── 13-interview-tips.adoc
└── src/
    ├── 01-big-o.js
    ├── 02-arrays-strings.js
    ├── 03-hash-tables.js
    ... (one .js file per concept)

The Concept Files (01-*.adoc)

Each file covers one major topic. Structure:

  1. Conceptual Overview: Understand the idea before code

  2. Time/Space Complexity: Why you’d use this

  3. Implementation: Real, runnable code in the accompanying src/ file

  4. Problem Walkthrough: 1-2 detailed examples with commentary

  5. Practice Problems: 5-8 problems, listed by difficulty

The Code Files (src/*.js)

Each src/ file has:

  • Helper functions and data structure implementations

  • Example solutions to 2-3 problems from the concept file

  • Test cases (simple assertions; runnable in Node.js)

  • Comments explaining the approach

As you study each concept file, open the corresponding src/ file and run it:

node src/03-hash-tables.js

This gives you working code to trace through. Don’t just read code—execute it mentally, predict output, verify. This is deliberate practice.

Study Flow (Per Concept)

  1. Read the concept file (.adoc)

  2. Run and read the code file (src/)

  3. Solve 2-3 practice problems without looking at solutions (20-30 min each)

  4. Check your solution against the approach described

  5. Trace through your solution with examples

  6. Solve 1-2 more problems from the list

  7. Return to this concept next week (interleaving)

Language: JavaScript

You’ve chosen JavaScript for your interviews. This means:

  • Use Map and Set (not plain objects for anything complex)

  • Know array methods: push, pop, shift, unshift, slice, splice, sort, filter, map, reduce

  • Know that strings are immutable (can’t modify a character; create new string)

  • Know closures (important for some DP patterns)

  • Practice in a Google Doc (no IDE syntax highlighting, no autocomplete)

See 13-interview-tips.adoc for JavaScript-specific interview tips.

Pacing and Flexibility

The 4-week plan assumes consistent effort. If you have 5 weeks, add 1 extra week for drilling weak areas. If you have 2 weeks, cut the schedule in half (focus on Week 1 + Week 3 only; skip deep dives).

The schedule is structure, not scripture. If you finish Week 1 slow, don’t panic—spend an extra 2 days. The goal is depth, not speed. You’re building neural pathways, not checking boxes.

Scheduling Reality

Block your calendar:

  • Weekdays: 2-3 hours after work (or before, if mornings work for you). One focused block is better than three scattered 30-min sessions.

  • Weekends: 4-5 hours per day. Split into two sessions (e.g., Saturday morning 2.5 hours + Saturday evening 2.5 hours) to avoid burnout.

Set a timer for each study session. When the timer ends, stop. Return next day. This builds the habit and allows consolidation.

Next Steps

  1. Print (or bookmark) this file

  2. Open 01-big-o.adoc and start Week 1

  3. Solve the practice problems without looking at solutions

  4. After struggling, study the solutions

  5. Log your progress

  6. Sleep on it and re-solve next day

Your goal is not perfection—it’s building the neural pathways to recognize problems, select techniques, and code under pressure. The struggle is the point. You’ve got this.

You’re a senior architect who builds complex systems. You understand abstraction, modularity, and trade-offs. Algorithms are the same—just at a smaller scale. You already have the problem-solving mindset. This guide is about translating that into the specific domain of algorithmic problem-solving.