I have run the same three-month coding interview prep plan twice on myself, recommended it to a dozen friends, and seen four of them use it end-to-end. The pattern is consistent enough that I am willing to write it up. The headline numbers from those runs: roughly 12-14 hours a week of prep, around 180 problems solved across the three months, and a noticeable bump in the kind of offers people landed at the end. Two of the four who finished the plan went from "interviewing aimlessly for six months" to "three offers in five weeks".

This is not a magic plan. It does not promise FAANG offers if you grind it. It is the schedule I have actually used, the thinking behind the structure, and the three traps that kill most prep schedules I see online.

Fair warning before we start: this article is opinionated. It assumes you can write working code, you have shipped real software for a few years, and your gap is interview-shaped (data structures, patterns, system design conversations) not coding-shaped. If you are still learning to code, this plan is the wrong tool.

The shape of the plan

Three months, three phases. Each phase has a single goal. Mixing the goals across phases is the most common reason a prep schedule fails.

Month 1   Coverage              Hit every major pattern at least once
Month 2   Fluency               Solve medium problems in 25 minutes consistently
Month 3   Loops                 Run mock loops; iron out behavioral and SD

The trap that kills most prep schedules I have seen is that people try to do all three at once for the whole three months. They grind problems while also doing system design while also writing behavioral stories. Every week they make a tiny amount of progress on each axis and never feel ready, because none of the axes ever cross the "competent" line. Sequencing the phases means you do cross the line, even if the area you are not working on this month feels neglected.

Month 1: Coverage (weeks 1-4)

The goal of month 1 is to encounter every major pattern at least once and walk away knowing what shape each one has. Not to solve them quickly. Not to memorize templates. To recognize that "this is a sliding window problem" within 30 seconds of reading the prompt.

The pattern list I work through, in roughly this order, one per ~half-week:

• Arrays and hash maps (the easy half-week, gets the hands moving)
• Two pointers, sliding window
• Strings (palindromes, anagrams, basic parsing)
• Linked lists (cycle detection, reversal, merging)
• Stacks, queues, monotonic stacks
• Binary search (and the variant where the search space is the answer)
• Trees (DFS, BFS, level order, common ancestor)
• Graphs (DFS, BFS, topological sort, basic union-find)
• Heaps and priority queues
• Backtracking (subsets, permutations, combinations)
• Dynamic programming (1D, 2D, knapsack, LIS)
• Tries, intervals, bit manipulation (a grab-bag week to round out)

For each pattern, I solve 5-8 problems on Easy and Medium. I read the editorial after every single problem, even the ones I solved on the first try, to see if there is a cleaner approach. I keep a running notes file with one entry per pattern: the template, the canonical problem, two variations, and the gotcha that bit me.

During month 1, the rule I follow is do not time yourself. Speed is a month 2 problem. If a problem takes 90 minutes, that is fine. The goal is exposure, and timing yourself out of half-finished problems means you do not learn from them.

A week of month 1 looks like this:

Monday      90 min  Read pattern intro + solve 1 easy problem
Tuesday     90 min  Solve 2 easy/medium problems
Wednesday   90 min  Solve 2 medium problems
Thursday    60 min  Read editorials for the week's problems
Friday      90 min  Solve 1 hard problem (skim editorial after 30 min if stuck)
Saturday   120 min  Catch-up / variations / review notes
Sunday               Off (real off, not 'open the laptop accidentally')

Month 2: Fluency (weeks 5-8)

The goal of month 2 is to solve a fresh medium problem in 25 minutes, to working code, with two small bug fixes after the first run. That is roughly the bar for a competent first pass at a phone screen, and it is the bar I aim my friends at.

The key shift from month 1 is that I now do time myself. Not as a stressor; as a feedback loop. I set a 25-minute timer, solve the problem, and write down the time even if I went over. Over four weeks the median time goes down, and that downward slope is the only metric I trust during this phase.

Month 2's problem mix changes too. I do random mediums from a curated list (NeetCode 150 is what I use; others work fine), not pattern-grouped sets. Random selection forces me to do the pattern recognition under timer pressure. If I get a sliding-window problem and I am still in "is this a tree problem?" mode at minute three, I know I have not internalized the pattern from month 1.

The trap I want to flag: do not skip to month 2 if you have not finished month 1. The temptation is enormous, because timed problems feel like "real prep" and untimed exposure feels lazy. Skipping the coverage phase means month 2 goes badly because you have not developed the recognition muscle, and you spend the whole phase frustrated. I have done this. It does not work.

A week of month 2:

Monday        90 min  Three timed mediums, 25 min each, then editorial review
Tuesday       60 min  Re-solve yesterday's failures, untimed, get to clean code
Wednesday     90 min  Three timed mediums
Thursday      60 min  Re-solve yesterday's failures
Friday        60 min  One timed hard, 45 min cap, editorial review
Saturday     120 min  Mock interview (LeetCode peer or interviewing.io)
Sunday                Off

The re-solve days are the secret sauce. Most people grind problems and never go back. Re-solving the ones I failed yesterday, untimed, with full attention to clean code, is where the actual learning happens.

Month 3: Loops (weeks 9-12)

The goal of month 3 is to run interview loops, not solve more problems. By the end of month 2 the coding muscle is in shape. Month 3 is about composing it with the other parts of an interview: the behavioral story, the system design conversation, the take-home, the introductions.

The schedule looks different. The mock interviews dominate.

Monday        60 min  One timed medium, just to keep the muscle warm
Tuesday       90 min  Behavioral practice (work through stories from the bank)
Wednesday    120 min  Mock interview (algorithm, with a friend or paid platform)
Thursday      60 min  Mock interview retro: where did I get stuck, why
Friday       120 min  Mock interview (system design)
Saturday     120 min  Mock interview (coding, full loop simulation)
Sunday                Off

Three mocks a week is intense. After the first week or two it stops being scary, and the remaining four weeks of month 3 is where I have seen the biggest jump in actual offer conversion. The reason is that mocks reveal the failure modes that solo prep cannot: nervousness eating fluency, a bad question-clarification habit, an over-engineered first solution, a failure to talk through reasoning while typing.

For system design specifically, I tend to recommend a different article-length writeup than this one (I have one called the system design framework I use in every loop). Month 3 is when that material gets practiced live, not learned from scratch.

The three traps that kill most prep schedules

I have watched at least a dozen prep attempts. The ones that fizzled out usually died on one of these three.

Trap 1: solving a thousand problems without reviewing any of them. The metric of problems solved is misleading. If I solve 30 problems this week and I cannot pull up the pattern from any of them when asked at the end of the week, I have not learned 30 things, I have entertained myself for 30 sessions. The fix is the running notes file from month 1 and the re-solve days from month 2. Both are explicitly about consolidation rather than novelty.

Trap 2: starting with hards. Hards are seductive. They look like serious work. They are also a terrible way to learn patterns, because the hard variation usually combines two patterns and you cannot recognize either if you have not seen them in isolation first. I do not recommend any hards in month 1. Month 2 has one hard a week, treated as a stretch problem. Month 3 has hards mostly inside mocks, where they teach the meta-skill of communicating under uncertainty.

Trap 3: never running mocks. This is the one I see kill more offer rates than any other. Solo grinding gives you fluency on a piece of paper. Mocks tell you that you stop talking when you are typing, that you launched into a solution before clarifying the input, that you did not test edge cases. Until those failure modes show up in front of someone, you do not know they exist. Three mocks in month 3 is the floor, not the goal. The friends of mine who landed multiple offers all did 8-15 mocks in month 3, almost half of them with strangers (paid or peer-matched), because the friend-mock has a politeness ceiling that real interviews do not.

What I do differently the second time around

If I am running this for the second time (i.e. I prepped two years ago, I know the patterns, but I am rusty), I compress month 1 into two weeks and lengthen month 3 to five. The core structure does not change, only the proportions.

If I have never solved a competitive problem before in my life, I add a pre-month 0 of two-three weeks doing only easies, just to get comfortable with the input/output ritual of the platform and writing code under any kind of constraint at all. The plan above assumes you have already written 10-20 problems' worth of code in your life. If that is not true, build that scaffold first.

Pacing matters more than total hours

The single biggest insight from running this plan twice myself: 12 hours a week for 12 weeks beats 30 hours a week for 6 weeks, by a wide margin. The difference is not total hours, it is sleep cycles between practice sessions. Pattern recognition consolidates in your head overnight. Cramming a weekend with 16 hours of LeetCode and then doing nothing for a week produces almost no measurable retention; spacing the same 16 hours over two weeks produces a lot. The plan above is designed around that, not against it. If you cannot do 12-14 hours a week reliably, do 8 and stretch the calendar to four months. That is genuinely fine and probably more sustainable than trying to compress the calendar and burning out in week 5.

That is the plan. Three phases, three goals, one schedule per phase, and two real warnings (mocks matter, sleep matters). The rest is showing up.