The 8-week plan
📖 Walk me through it — plain English
This isn't a coding problem — it's a training schedule. It takes everything in the guide and spreads it across 8 weeks at about 10–14 hours a week, so you're not staring at a giant pile of topics wondering where to start. Each week has a theme (a small group of related patterns), a problem count, and a "SoloMock" — that just means a practice run where you solve a problem out loud and on a timer, pretending it's the real interview, even though no one else is in the room.
A few bits of jargon up front. STAR story = a rehearsed answer to a behavioral question ("tell me about a time…"), structured as Situation, Task, Action, Result. DFS/BFS = two ways to walk through a tree or graph (depth-first = go deep down one path first; breadth-first = explore level by level). DP = dynamic programming, solving a big problem by reusing answers to smaller overlapping sub-problems. DSU = disjoint-set union, a structure for tracking which items are grouped together. Trie = a tree built from the letters of words, for fast prefix lookups. You don't need to know these yet — the plan introduces each in its own week.
Think of it like training for a 5K when you've been off the couch a while. You don't run the whole race on day one. Week 1 is easy jogs to wake up the legs (Big-O refresher, the simplest patterns). The middle weeks add distance and harder intervals (trees, graphs, DP). Then — and this is the part people skip — you run a few practice races under real conditions before the actual event (Week 8's timed mocks). The race-day nerves are a skill you train too, not something you wing.
How to actually use it:
- Follow the order, not the clock. The weeks build on each other (two pointers before sliding window, recursion before DP). If life eats a week, slow down — don't skip ahead.
- Start human mocks early. Notice Week 4 says "yes, now" — practicing with a real person (Pramp, a friend) feels uncomfortable, which is exactly why you do it before it counts.
- Behavioral runs in parallel. A STAR story or two every couple of weeks means you're not cramming seven life stories the night before.
- Depth over breadth. Re-solving a problem you got wrong, out loud, beats grinding ten new ones you'll forget — that's the "VERBAL upgrade" in Week 8.
Why it's shaped this way: spacing the topics out (instead of cramming) is how memory actually sticks, and ending on simulation instead of new material means you peak on interview day, not the week before. The hour counts ramp up in the hard middle (14 hrs) and ease off at the end (10 hrs) so you arrive rested, not fried.
~10–14 hrs/week. Depth over breadth.
How to read every week (the same four parts)
Each card below is terse on purpose — it has to fit on a line. But every week is really the same four things, and once you see the shape you can run any week without re-reading the instructions. Decode each card like this:
- Theme — the small family of patterns you're learning. A "pattern" here means a reusable problem-solving shape (e.g. "two pointers" = walk two indices toward each other), not a single trick. Learn the pattern once and it unlocks dozens of problems.
- Problem count — how many practice problems to actually solve, with your hands, in code that runs. "5+5" means five of one sub-topic and five of another. These are not problems to read; reading a solution feels like learning and isn't. You have to type it, run it, and watch it fail first.
- SoloMock — one problem you treat as a real interview: set a 35-minute timer, talk out loud the entire time (narrate your thinking as if an interviewer is listening), write code without an IDE's autocomplete or running it, then check it. The named problems (e.g. "Two Sum") are just suggestions at the right difficulty; any unseen problem of that type works.
- Behavioral / extras — the non-coding work woven in: writing STAR stories, reading the system-design framework, booking a human mock. This runs alongside the coding so nothing gets crammed at the end.
The single rule that makes this plan work: a week is "done" when you can re-solve its hardest problem from a blank file, out loud, inside the time limit — not when you've seen all the topics. Coverage is not competence. If you can't yet do that, repeat the week's weakest problem rather than racing to the next theme.
Pick your starting line: beginner vs. rusty
The plan is one path, but two kinds of people walk it. Adjust the dials, not the order.
You've seen Big-O, trees, and DP before but haven't touched them since school or your last job hunt. Don't skip weeks — skim them. Spend ten minutes per topic checking you can still write it cold; if you can, do two problems instead of five and move on. If you stall, you've found a real gap, so treat that week as a beginner would. Your biggest risk is overconfidence on DP and graphs (Weeks 5–6), which fade fastest. Keep every human mock — rust hides best when you're talking out loud.
The third dial: how senior is the role?
The plan above is balanced for an entry-to-mid coding screen. But the market has shifted, and you should bias the hours to the level you're actually targeting. In current big-tech loops, system design has pushed down from senior-only to standard at mid-level, the design round carries equal or greater weight than coding for senior candidates, and pure algorithm puzzles have lost weight (often replaced by read/debug/extend-the-code rounds). Preparing only for the junior coding screen leaves you under-prepared for the rounds that now decide the offer.
The coding screen still dominates, so keep the plan as written. Treat the System design phase as awareness, not mastery: read the framework and the two worked case studies (URL shortener, rate limiter) so the vocabulary isn't foreign, but spend the bulk of your hours on Weeks 1–6.
Rebalance toward design. Compress the easier coding weeks (do two problems where it says five if you can already write them cold) and reclaim those hours for the full System design arc — including defending tradeoffs under pushback, the operational layer, and the four case studies (cache, autocomplete, proximity, payments). Run at least one design SoloMock per week from Week 4 on, out loud and on a timer, just like a coding mock. Behavioral weight is up too — keep all seven STAR stories sharp.
Rule of thumb: if the role title has "senior", "staff", or a leveling number above entry, design + behavioral together outweigh coding in the final decision. Spend your hours accordingly — coverage of LeetCode is not the bottleneck at that level; structured, defensible design reasoning is.
Big-O drill, stdlib refresher. 5+5 problems. First SoloMock on Two Sum + Valid Anagram.
5 + 4 problems. SoloMock: Longest Substring + Valid Parentheses. Write 2 STAR stories.
4 each. Drill "smallest k such that f(k)". SoloMock: Container/Product Except Self. 2 more STARs.
4 each. SoloMock: Reverse LL. First HUMAN mock (Pramp/friend) — yes, now.
DFS/BFS/topo/cycle. 8 problems. SoloMock: Islands + Course Schedule. Read system design framework.
Stairs → robber → coin → wordbreak → LCS → edit distance. Recursion first every time. One human mock.
Trapping Rain Water 3 ways. Monotonic stack. DSU. Trie. 2 design questions end-to-end. One human mock.
3 timed mocks. No new content. Re-solve weak problems for the VERBAL upgrade. STAR dress rehearsal.
Week-by-week: what to do, and how to know you're done
The cards above are the menu; this is the recipe. For each week, here's the concept in one breath, the concrete task, and the finish line. "Done" always means you can reproduce it cold, not that you've seen it.
Concepts. Big-O is shorthand for how an algorithm's work grows as the input grows — O(n) means double the input, double the work; O(n²) means double the input, quadruple the work. A hash map (dict in Python, HashMap in Java) stores key→value pairs and looks them up in roughly O(1), which is why it turns many "search" problems from slow to fast. Two pointers means scanning a list with two indices instead of nested loops — often turning O(n²) into O(n). stdlib refresher = re-learn your language's built-in tools (lists, dicts, sets, sorting, the collections module) so you stop fighting syntax.
Do. Spend the first session drilling Big-O: for ten code snippets, say the complexity out loud and check yourself. Then solve 5 hash-map and 5 two-pointer problems. Finish with the SoloMock.
Done when. You can glance at a loop and name its Big-O without thinking, and you can write Two Sum from a blank file in under 15 minutes while narrating why a hash map beats the brute-force scan.
Concepts. A sliding window is a two-pointer pattern for problems about contiguous chunks of an array or string ("longest substring with…", "max sum of k items"): you grow a window from the right and shrink it from the left, keeping a running summary instead of recomputing. A stack is a last-in-first-out pile; it shines for matching pairs (brackets) and "most recent unfinished thing" problems.
Do. Solve 5 sliding-window and 4 stack problems, then the SoloMock. In parallel, write your first 2 STAR stories — pick real moments (a bug you chased, a deadline you saved) and draft them in the Situation/Task/Action/Result shape, one paragraph each.
Done when. You can explain when to grow vs. shrink a window without peeking, solve Valid Parentheses cold, and tell each STAR story out loud in under two minutes.
Concepts. Binary search halves a sorted search space each step — O(log n). The deeper skill is "binary search on the answer": the "smallest k such that f(k) is True" drill teaches you to search over possible answers, not just array indices. A prefix sum precomputes running totals so any range sum is one subtraction. Intervals problems (overlapping meetings, merging ranges) almost always start by sorting on start time, then sweeping left to right.
Do. 4 problems each. Hammer the "smallest k such that f(k)" template until it's muscle memory. SoloMock on Container With Most Water or Product of Array Except Self. Draft 2 more STAR stories (now you'll have 4).
Done when. You can write a binary search with correct boundaries on the first try (off-by-one bugs are the classic trap), and you reflexively sort intervals before doing anything else.
Concepts. A linked list is a chain of nodes each pointing to the next; the skill is pointer juggling (reverse, detect a cycle, find the middle). A heap (priority queue) always hands you the smallest or largest item fast — perfect for "top k" and "merge sorted streams". Backtracking builds candidate solutions step by step and undoes a step when it hits a dead end — the engine behind permutations, subsets, and Sudoku-style search.
Do. 4 problems each. SoloMock on Reverse Linked List. The big one: book and run your first human mock — on Pramp (free peer mock-interview site) or with a friend. Do it even though you feel unready; "unready" is the point. Schedule it now so you can't dodge it.
Done when. You can reverse a linked list without drawing it on paper, you know which of these three patterns a new problem wants, and you've survived one mock with a stranger and written down what felt awkward.
Concepts. Trees and graphs are the heart of mid-level interviews. DFS (depth-first) goes deep down one path then backtracks; BFS (breadth-first) explores level by level and finds shortest paths in unweighted graphs. topo = topological sort, ordering tasks so prerequisites come first (course scheduling, build order). cycle detection = spotting loops in dependencies. Most tree problems are just DFS in disguise.
Do. 8 problems spanning DFS, BFS, topo sort, and cycle detection. SoloMock on Number of Islands plus Course Schedule. Start reading the system-design framework (a repeatable way to structure "design a URL shortener"-style questions) — you'll apply it in Week 7.
Done when. You can write DFS and BFS from memory, choose between them correctly (shortest path → BFS), and explain why Course Schedule is really cycle detection.
Concepts. DP solves a big problem by combining answers to smaller overlapping sub-problems and storing each answer so it's computed once. The named ladder — Climbing Stairs → House Robber → Coin Change → Word Break → Longest Common Subsequence → Edit Distance — goes from easy to hard on purpose; each adds one new wrinkle. The week's golden rule, "recursion first every time": write the slow, plain recursive solution first, then add memoization (caching), then convert to a table. Jumping straight to a table is how people get lost.
Do. Walk the ladder in order, recursion-first for each. One human mock this week.
Done when. Given a new problem you can state its recurrence (how a big answer is built from smaller ones) in a sentence, and you can take Coin Change from recursion to memoized to tabular yourself.
Concepts. This week mixes a few high-leverage advanced patterns with your first full design questions. Trapping Rain Water three ways = solve one problem with brute force, then two pointers, then a monotonic stack (a stack kept sorted so you can pop "everything smaller/larger" in one pass) — seeing one problem three ways teaches the patterns better than three problems. DSU (disjoint-set union / union-find) tracks which items are connected, for grouping and connectivity. Trie is a letter-by-letter tree for fast prefix search (autocomplete). A system-design question asks you to architect a service end-to-end (APIs, data store, scaling) — there's no single right answer; they're judging your structure and trade-offs.
Do. Solve Trapping Rain Water all three ways, plus a monotonic-stack, a DSU, and a Trie problem. Take 2 design questions end-to-end using the framework you read in Week 5. One human mock.
Done when. You can name which advanced pattern a tricky problem wants, and you can talk through a system design for 30 minutes without freezing — covering requirements, a rough API, the data model, and one scaling bottleneck.
Concepts. No new material — this week trains performance, not knowledge. Run 3 full timed mocks under real conditions. The "VERBAL upgrade" means re-solving problems you previously got wrong, this time narrating cleanly start to finish: the win isn't a new solution, it's saying it well, since interviewers grade communication as much as correctness. The STAR dress rehearsal = telling all your behavioral stories out loud, on the clock, as if to a real panel.
Do. Three timed mocks (human if you can get them). Re-solve your weakest 5–8 problems out loud. Run every STAR story aloud once. Then taper — lighter days right before interviews so you arrive fresh.
Done when. A timed mock feels routine rather than terrifying, you can narrate a solution smoothly from blank file to working code, and every STAR story lands in under two minutes without notes.
Pitfalls that quietly sink this plan
Most people who fail interviews didn't lack time — they spent it in ways that felt productive but weren't. Watch for these:
- Cramming. Eight light weeks beat two frantic ones; spaced practice is how memory sticks, and an all-nighter the day before makes you slower, not sharper. If you fall behind, stretch the calendar — don't compress the work.
- Skipping the mocks. The SoloMocks and human mocks are the whole point — they train the one thing reading can't: performing under a clock while talking. They're uncomfortable, which is exactly why people skip them and why you must not.
- Reading solutions instead of writing them. Watching someone solve a problem feels like learning and isn't. If you looked something up, close it and re-solve from blank the next day, or it didn't count.
- Grinding new problems over fixing weak ones. Volume feels like progress, but re-solving a problem you got wrong (out loud) teaches more than ten fresh ones you'll forget. Depth over breadth — that's the whole motto.
- Coding in silence. If you never narrate while you practice, you'll go mute in the real thing. Talk through every SoloMock, even alone in your room.
- Leaving behavioral for the end. Stories drafted at midnight before the onsite sound exactly that rushed. The plan spreads them across Weeks 2–3 and rehearses them in Week 8 for a reason.
If you have fewer than 8 weeks: don't try to do all of it faster. Keep the order and triage by impact — Weeks 1, 5, and 6 (foundations, trees/graphs, DP) cover the most-asked patterns, so protect those and trim Week 7's advanced extras first. Keep at least two human mocks and the Week 8 simulation no matter how short you are; arriving practiced at performing beats arriving with one more pattern half-learned.
Takeaway: this is a training schedule, not a checklist. Follow the order (each week builds on the last), make every week "done" mean "I can re-solve the hardest problem cold, out loud, on the clock," start human mocks at Week 4, run behavioral stories in parallel, and end on simulation so you peak on interview day. The traps are all the same trap — doing things that feel like progress (reading, cramming, grinding new problems) instead of the uncomfortable thing that actually works (timed, spoken, from-scratch practice).
Go deeper (optional): for free human mocks, Pramp (now part of Exponent) pairs you with another candidate; Cracking the Coding Interview by Gayle Laakmann McDowell is the classic companion book; and Anki or any spaced-repetition flashcard app is a good way to keep Big-O and pattern triggers fresh across the eight weeks.