FAANG Prep: A 90 Day Week by Week Roadmap
When timed practice should enter your 90 day FAANG plan, and why most plans wait until the final weekend.
You're four weeks into a 12 week FAANG prep plan. Arrays feel comfortable, hash tables click, the trees module starts on Monday. Your plan is on track. The on site is eight weeks out. There's only one decision in the whole plan that decides whether the last six weeks pay off, and most plans get it wrong: when to introduce the timer.
Key Takeaways
The single load-bearing decision in a 90 day FAANG plan isn't topic order. It's when timed practice enters.
Most plans introduce the timer in the final week, which is six weeks too late to fix anything it surfaces.
Week 6 is the right entry point. By then you've covered enough patterns to practise solving-under-pressure as a separate skill.
The gap between solving at your desk and solving at 20 minutes with no hints is wider than most engineers expect.
Treating timed practice and pattern learning as one workflow is what produces the panic-pivot the night before an interview.
Worth flagging: I built Codeintuition, a structured learning platform for coding interviews. This post is about the timing of pressure practice in your prep, not about the platform.
Where the typical plan breaks
The typical 90 day plan looks like this. Twelve weeks of topic-by-topic study, increasing in difficulty, with one mock interview crammed into the weekend before the on site. The plan reads like a complete preparation. It is not. The plan covers learning, but does not cover retrieving under stress, and those are different skills.
Here's what happens in practice. You spend eleven weeks learning patterns at your own pace, with hints, with the solution tab one click away, with no clock. You feel ready. You sit down for your one mock the weekend before, and the pattern you knew cold on Tuesday refuses to come together in twenty minutes on Saturday. You recognise it eventually, but you've already burned half the time. You finish the mock. You leave it shaken.
Then the interview happens five days later, and the same mechanism repeats: a problem your slower-paced practice prepared you to solve eventually, but not at interview speed. The plan didn't fail at any individual topic. It failed at the timing of one specific decision.
The Week 6 introduction (the decision that actually matters)
The right time to introduce timed practice is after your pattern coverage is wide enough to attempt timed problems honestly, but before the harder topics start to dominate your study time. By Week 6, you'll have covered arrays, linked lists, hash tables, stacks, queues, and started binary trees. That's six weeks of pattern coverage, which means a Week-6 timed session can pull from a real pool of problems you've seen.
Three reasons Week 6 specifically:
Pattern coverage is wide enough. Earlier than Week 6, the timed problems you can attempt are limited to two or three pattern families, which makes the practice feel more like rehearsal than retrieval.
The material is still fresh. When you solve a Week 2 problem under a timer in Week 6, you're testing whether the patterns transferred from learning to retrieval. Wait until Week 11 and the early-weeks material has decayed, which conflates two failure modes.
You still have six weeks left. A Week-6 introduction gives you six full weeks of timed practice before the on site. Six weeks is enough to surface specific gaps and rebuild them. One weekend is not.
The Wikipedia article on the spacing effect summarises why distributed retrieval beats massed retrieval: a problem solved under timed conditions in Week 6, then again in Week 9, then again in Week 11, retains better than the same three attempts compressed into the final weekend. Compressing them makes the practice feel intense. Spacing them is what really transfers.
What to do in Weeks 6 through 12
This is the rough cadence I have ended up recommending. Adjust the numbers to your own schedule, but keep the shape:
| Window | Goal | Concrete protocol |
|---|---|---|
| Weeks 6 to 8 | Train solving-under-pressure on familiar patterns | Two timed sessions per week. 20 min for mediums, 30 min for hards. Re-attempt previously solved problems with no hints, no notes. |
| Weeks 9 to 10 | Add unfamiliar problems to the same constraint | Three timed sessions per week. Mix two re-attempts and one new problem in the topic of that week. Same timer rules. |
| Weeks 11 to 12 | Simulate interview rounds | Two full simulations per week. 50 min, two problems, talking out loud while solving. |
The Week 6 to 8 sessions are not about pass rate. They're about how the experience of working without a safety net feels while the material is still fresh. The first three or four sessions are uncomfortable in a specific way that's hard to manufacture later: you know the pattern, but the muscle of producing it on demand is missing. That feeling is the gap, and the gap is what timed practice closes.
A worked example: variable sliding window in Week 6
Take a problem like longest substring with at most K distinct characters. You've covered it in your Week 1 to 2 arrays material, possibly extended in Week 3 to 4 hash tables. By Week 6, the steps to solve it are clear when you read the prompt slowly, no clock running:
def length_of_longest_substring_k_distinct(s, k):
counts = {}
left = 0
best = 0
for right in range(len(s)):
counts[s[right]] = counts.get(s[right], 0) + 1
while len(counts) > k:
counts[s[left]] -= 1
if counts[s[left]] == 0:
del counts[s[left]]
left += 1
best = max(best, right - left + 1)
return best
That's the no-clock version. Now add a 20 minute timer and the second-order question becomes interesting: how long does it take you to recognise you're looking at a variable sliding window before you start writing? In the no-clock version, recognition is fuzzy. You read, you experiment, you arrive at sliding window. In the timed version, the recognition is the bottleneck. If recognition takes seven minutes, you have thirteen for the implementation, which is tight. If recognition takes two minutes, you have eighteen, which is comfortable.
Six weeks of timed practice is what shrinks recognition from seven minutes to two. One weekend of cramming doesn't.
A second example: when productive struggle turns into spinning
The same Week 6 timed session reveals a different kind of failure. You attempt a problem, the timer runs out, you don't have a solution. There are two distinct cases here that most engineers don't separate:
# Case 1: productive struggle
# You can name what's missing.
# "I see this is a sliding window. I can't tell whether the window
# should be fixed or variable. The constraint mentions K distinct
# characters, which feels variable, but I'm not sure why."
# -> Specific, actionable. Go find the [recognising sliding window]
# lesson, work the variant, attempt the problem again next week.
# Case 2: spinning
# You can't name what's missing.
# "I read the problem three times. I know we covered something
# like this. Nothing comes to mind."
# -> Vague, not actionable. The work isn't more practice on this
# problem; the work is generating an attempt from a blank
# screen, even a wrong one, to surface the specific missing
# piece.
The reason this matters is that productive struggle and spinning have opposite prescriptions. Productive struggle wants targeted retrieval practice. Spinning wants generation. Mixing them is what makes a Week 6 timed session feel demoralising rather than diagnostic. The Wikipedia article on the generation effect explains why generating an attempt, even a broken one, surfaces the missing concept more reliably than rereading the walkthrough.
What changes in Weeks 9 to 12
By Week 9, your timed practice should shift from re-attempts of known problems to a mix that includes new problems on the topic of the current week. The shift matters because re-attempts measure retrieval speed. New problems measure recognition speed. Both are interview skills, and the timer is what surfaces which one is the bottleneck. You won't know which one to train if you only practise one of them.
By Week 11, you should be running 50 minute multi problem simulations. The 50 minute window is interview-shaped. If you've been doing 20 minute single problem sessions for five weeks, the first 50 minute session will feel disorienting. That disorientation is the point. The skill of allocating attention across two problems, of recognising the first one isn't going to fall in 25 minutes and pivoting to the second, of returning to the first with fresh eyes, is a separate retrieval skill. You're training it for the first time, in Week 11, with one week left. That's the right place for it. Earlier, the multi-problem coordination would compete with the single-problem retrieval skill for training time. Later, you'd be doing it for the first time in your actual interview.
What to do if Week 6 catches you behind
Most engineers don't hit Week 6 on schedule. Work blows up, a topic takes longer than expected, the plan slips by ten days. If your Week 6 looks more like Week 4-and-a-half, you have two real options:
The first is to compress later weeks to absorb the slip. Cut one of the optional review days in Week 12, take the recovered day at Week 6, run your first timed session on schedule. This works if the slip is genuinely small (one week or less).
The second is to extend the plan to thirteen weeks rather than skip the timed introduction. The single decision in this entire roadmap that doesn't compress well is the introduction of timed practice. Skipping it to "stay on schedule" produces the panic-pivot the night before an interview. Extending the plan by one week to keep the timed practice in is what keeps the rest of the plan working. If your interview can't move, prioritise the timed introduction and trim review weeks elsewhere.
The signal you're looking for by Week 11
By Week 11, you're looking for a specific feeling more than a pass rate. The feeling is: a medium-difficulty problem you haven't seen comes up, you read the constraints, and within two or three minutes you can identify the pattern family. You don't have the full solution. You have the pattern, and you know roughly how the pattern adapts to this problem. The remaining 17 to 18 minutes of a 20 minute timer are for the implementation, the edge cases, and the verification. That ratio (2 to 3 minutes recognition, 17 to 18 minutes implementation) is what interview-ready looks like.
If you're still spending 8 to 10 minutes on recognition by Week 11, you have a recognition gap, not an implementation gap. The fix is more retrieval practice on the patterns you're slow on, not more new problems. If you're spending 2 minutes on recognition and running out of time during implementation, the fix is the opposite: more new problems on the same patterns, not more retrieval drills.
The timer is what tells you which one you need. Without the timer, you can't tell.
If you want the full version of this roadmap with exact problem lists, pattern breakdowns, and weekly schedules I’ve written it here
What's the week your prep finally crossed the line from solving-eventually to solving on the clock?
