90 Day FAANG Preparation: The Week by Week Roadmap

You open the recruiter's email. The on site is scheduled. You count the weeks on your calendar and land on a number: twelve. Twelve weeks to go from wherever you are right now to passing a FAANG coding interview. The real question behind every 90 day FAANG preparation plan isn't whether the timeline is enough. It's whether you'll spend those twelve weeks in the right order.

Why most 90 day plans fail

A 90 day FAANG preparation schedule sounds reasonable. Three months, focused study, a clear deadline. But following one doesn't guarantee results.

The failure mode is almost always the same: they study topics in the wrong order. A typical plan might start with "easy problems for two weeks, then mediums, then hards." Or it might group by popularity: arrays and strings first because they're common, then trees, then DP at the end because it's hard. Both approaches miss the same thing. DSA topics have dependencies.

You can't reason about binary tree traversal without understanding recursion. You can't build recursive intuition without understanding how the call stack works. And you can't use a hash table for pattern problems until you've internalized the data structure's lookup mechanics. These gaps surface mid plan. They hit binary trees in Week 5 and realize their recursion understanding is shaky. They attempt a DP problem in Week 9 and can't formulate the recurrence because they never properly learned the recursive substructure. Each missing prerequisite sends them backwards, and a 12-week plan quietly becomes a 6-week plan with 6 weeks of rework.

Whether rigid learning paths help or hurt motivation probably depends on the person. But the dependency problem is upstream of that debate. Whatever schedule you follow, the ordering has to respect prerequisites.

So: sequence your preparation by dependency order, not by difficulty or topic popularity. Every concept you study should build directly on what you studied the week before.

The week by week FAANG preparation roadmap

This roadmap follows a strict dependency order: Arrays, Linked Lists, Hash Tables, Stacks, Queues, Trees, Heaps, Recursion, Graphs, Backtracking, Sorting, Searching, Dynamic Programming. Each week's material assumes the previous weeks are solid.

The order matters concretely. Take Coin Change, a standard DP interview problem. To solve it, you need to formulate a recurrence relation (requires recursion), identify overlapping subproblems (requires understanding multiple recursive calls), and optimize with memoization (requires understanding how cached results map to subproblem states). For a deeper look at how dependency ordered learning applies specifically to recursion and dynamic programming, the Recursion course and Dynamic Programming course on Codeintuition walk through that dependency order in detail. An engineer who jumps to DP in Week 3 will memorize the solution. An engineer who reaches DP in Week 11, after building recursive intuition through eight weeks of prerequisite work, will derive the solution. That's what the interview actually tests.

When your preparation should add pressure

It's easy to practice in comfort conditions for 11 weeks and then panic in your first mock interview. The gap between "I solved this at my desk with no timer" and "I solved this in 20 minutes with no hints" is wider than most people expect. The right time to introduce timed practice is after foundations are solid but before advanced topics begin. That's around Week 6.

By week 6

You've covered arrays, linked lists, hash tables, stacks, queues, and started binary trees. That's enough pattern coverage to attempt problems under realistic constraints. You won't know every pattern yet, but you know enough to practice the skill of solving under pressure separately from the skill of learning new patterns.

Weeks 6-8

Start attempting previously completed problems under timed conditions. Set a timer matching interview constraints, 20 minutes for mediums and 30 minutes for hards. No hints, no looking back at your notes. The goal isn't to pass every attempt. You're training the feeling of working without a safety net while the material is still fresh.

Weeks 9-12

Add full assessment practice. Attempt multi problem sets under a 50-minute timer, the way actual interview rounds work. By this point you've covered enough of the learning path to simulate realistic interview coverage.

The spacing matters here. Research on the spacing effect shows that practice distributed across weeks produces stronger retention than the same volume crammed into the final days. Starting pressure practice at Week 6 gives you six full weeks of spaced, timed practice before the interview, compared to the single mock interview most people cram the weekend before their on site.

What to do when you fall behind

Plans break. You'll have a week where work gets intense, or you'll hit a topic that takes longer than expected. The question isn't whether your schedule will slip. It's how you respond when it does.

The worst reaction is skipping a topic to stay on schedule. If you're struggling with recursion in Week 7 and you jump to graphs in Week 9 to "stay on track," you haven't saved time. You've created a debt that compounds through every remaining week. Graphs require recursion for DFS. Backtracking requires recursion for enumeration. DP requires recursion for subproblem formulation. Skipping one prerequisite doesn't cost you one week. It costs you four.

The better approach is to extend your timeline by the exact amount you need on the current topic, then compress review time later. If recursion takes an extra week, your plan becomes 13 weeks. That's fine. Spend that extra week getting recursion solid, and you'll move through backtracking and DP faster than someone who rushed past it. The net time often ends up the same.

Recognizing productive struggle vs. spinning

Not every slow week means you're behind. Some topics genuinely require more processing time. The difference between productive struggle and spinning looks like this:

If you're spinning, change your approach rather than repeating it. Try solving a simpler variant of the problem. Try explaining the concept out loud to yourself. Try writing the solution from memory without any reference, even if it's wrong. The act of generating an attempt, even a broken one, often reveals the specific piece you're missing more clearly than another round of passive review.

Adjusting around life events

If you lose an entire week to something unavoidable, don't try to cram two weeks into one. Instead, identify which course in the lost week had the most downstream dependencies. Cover that one first at normal pace, then fold the remaining material into the next week's study by adding 30-45 minutes per day. You're spreading the catch up across seven days rather than crushing it into two marathon sessions that won't stick.

How to know you're on track

Vague progress signals ("I feel like I'm getting better") aren't reliable under stress. You need concrete checkpoints at each month boundary. If three or more items at any checkpoint don't describe you, don't move to the next month. Spend an additional week on those weak areas. A 13-week plan that's solid beats a 12-week plan with holes.

By week 4

By week 8

By week 12

Your final week before the interview

Week 12 isn't for learning new material. If you're still covering fresh topics in the last week, something went wrong earlier. The final seven days serve one purpose: consolidation under realistic conditions.

Days 1-3: Targeted weak spot practice

Look back at your timed practice results from Weeks 9-11. Which topics had the lowest pass rate? Which patterns did you consistently fail to identify within the first five minutes? Spend three days doing focused repetition on those specific areas. Don't re-study the entire topic. Isolate the pattern you're missing and attempt 2-3 problems that test exactly that pattern.

Days 4-5: Full simulation rounds

Run two complete mock interview simulations. Each one should mirror actual interview conditions: 45-50 minutes, two problems, no IDE autocompletion, and you explain your thinking out loud as you write. If you don't have a practice partner, record yourself. The recording forces the same "someone is watching" pressure that slows most people down in real interviews.

Pay attention to your time allocation. A common failure pattern in actual interviews is spending 30 minutes on the first problem and having only 15 minutes for the second. Practice the discipline of checking your progress at the 20-minute mark and making a deliberate decision about whether to keep debugging or move on.

Days 6-7: Rest and review

Stop solving new problems. Review your notes on the 3-4 patterns you found hardest. Get enough sleep. The difference between a well-rested engineer who's covered 90% of the material and an exhausted engineer who's crammed 100% is measurable in interview performance. Fatigue degrades pattern recognition speed before it degrades anything else, and speed is exactly what interviews test.

The order is the advantage

This roadmap gives you the order. The rest is depth over breadth. For the complete strategy behind each topic, including how to prove correctness, when to use each pattern, and how to build the identification skill that separates pattern matchers from algorithm thinkers, see our FAANG coding interview preparation playbook. The Arrays and Singly Linked List courses on Codeintuition map directly to Weeks 1-2 of this roadmap, and they're permanently free. They cover two pointers, sliding window, fast/slow pointers, and interval merging, the foundation patterns that every subsequent week in this roadmap builds on. No trial, no expiration.

Think about Coin Change from the Week 11 DP module. To derive that recurrence, you needed recursion (Week 7), which needed stack mechanics (Week 4), which needed array fundamentals (Week 1). An engineer who jumped to DP in Week 3 would memorize the solution. An engineer who reached it in Week 11, after building each prerequisite layer, would construct it from the invariant. That's the difference dependency order produces. Not more knowledge, but knowledge that holds together under pressure because every piece supports the one above it.