The 90-Day DSA Roadmap. Stop Fading in Month Two.

Most people start interview prep with a list and a lot of energy. Week one, they're solving arrays. Week two, they're on trees. Week six, they're staring at a graph problem at midnight, having watched three YouTube explainers, opened a LeetCode tab, and closed it again. Their NeetCode streak is dead. Their Anki deck has 400 cards they've never reviewed. The momentum is gone and they're not sure exactly when it left.

The problem is not willpower. It's structure. A real 90-day DSA roadmap doesn't just tell you what to study. It tells you in what order, at what depth, and when to switch from learning mode to performance mode. Miss any of those pivots and you'll hit the month-two wall just like everyone else.

This plan is built for people starting close to scratch, or anyone targeting competitive companies who wants to be systematic about it. It assumes two to three hours daily on weekdays, more on weekends. Adjust the pace but not the sequence.

What "Solved" Actually Means

Fix this definition before anything else. You don't know it yet, but this one thing is why most plans collapse.

Solving a problem once does not mean you know it. The Ebbinghaus forgetting curve is brutal: without review, you lose roughly 70% of what you learned within 24 hours. Engineers who solved 200+ LeetCode problems and still froze in real interviews are living proof. They didn't cheat. They just solved each problem once, felt great, and moved on. The bar is: you can recognize the pattern on a blank screen, explain your approach before touching the keyboard, and implement cleanly without hints.

That takes repetition across days, not a single session. Every problem you solve needs to enter a review cycle. We'll come back to exactly how.

Month One: Build the Foundation (Weeks 1-4)

Stop and learn the data structures before you touch algorithmic patterns. This sounds obvious. Very few people actually do it. It's like knowing you should eat vegetables and then just... not.

The goal is fluency in eight core structures: arrays, strings, hash maps, hash sets, stacks, queues, linked lists, and binary trees. Not definitions. Actual implementation fluency, edge cases included.

Week 1-2: Arrays, Strings, Hash Maps

These three underlie about 40% of interview problems. Arrays first: indexing, basic sliding window, two-pointer manipulation in-place. Strings next: in most languages strings are immutable, so concatenating in a loop is O(n²) and your first instinct is wrong. Hash maps last: the O(1) lookup is the thing that turns a brute-force O(n²) into something your interviewer will actually nod at.

Target 25-30 problems total across these two weeks. Stick to Easy. They are not beneath you. The Easy problems in each category establish the foundational pattern, and skipping them to jump to Medium is the single most common reason people plateau in month two. The NeetCode 150 list, which has 28 Easy, 97 Medium, and 25 Hard problems, is a good anchor for problem selection.

Daily rhythm: 30-45 minutes learning a concept, 2-3 problems, 15 minutes reviewing what you just solved. That last 15 minutes matters more than most people realize. It's also the first thing people skip when they're tired.

Week 3: Stacks, Queues, Linked Lists

Stacks and queues are simpler in concept but frequently misunderstood in application. The monotonic stack pattern alone solves a surprising number of problems involving next-greater-element and temperature-window shapes. Queues unlock BFS, which you'll use constantly in month two.

Linked lists require pointer discipline. Dummy head nodes, reversals, Floyd's cycle detection, merge operations. Practice until the pointer updates are automatic. Interview pressure will make you forget exactly which pointer moves first if your hands haven't done it a dozen times. You will stare at your code and feel a deep personal betrayal.

Week 3 target: 15-20 problems.

Week 4: Binary Trees and Basic Traversals

Trees are where pattern recognition starts to click. Recursive pre/in/postorder traversal, BFS level-order traversal, lowest common ancestor, and depth/height calculations all appear in some form across nearly every technical interview loop.

The non-obvious thing here: interviewers appreciate when you can switch between recursive and iterative implementations. Practice both. Iterative preorder traversal and iterative inorder traversal are worth understanding mechanically before you move on. Recursive is readable. Iterative shows you understand the call stack.

Week 4 target: 15-20 problems.

End-of-month-one checkpoint: you should be able to solve any Easy in these areas within 20 minutes. If you're regularly at 30-40 minutes, slow down and consolidate before proceeding. Speed at Easy problems isn't vanity. It's the baseline that makes Medium problems tractable.

Month Two: Patterns and the Plateau (Weeks 5-9)

Month two is where prep plans die.

Two wolves meme: one does leetcode, one builds, both are unemployed

Both strategies. Same outcome. You need a third wolf: the one who has a plan.

The topics get harder. The problems feel new even when they're not. Progress becomes invisible. You're spending 45 minutes on mediums you think you should be solving in 20. The vague dread that you might just be bad at this starts creeping in around week 6. This is the plateau, and it's caused by the gap between knowing a data structure and having internalized a pattern well enough that your brain maps the problem surface to the solution approach automatically.

More grinding won't fix this. The method does.

Interleave topics instead of massing them. Cognitive science research on spacing and interleaving shows that mixing problem types in the same session helps learners discriminate between similar patterns, which is exactly the skill an interview tests. Instead of 30 graph problems back to back, mix a graph problem, a DP problem, and a sliding window problem in one session. Your brain will hate it. That's the signal that something useful is happening.

Week 5-6: Binary Search, Heaps, Intervals

Binary search is deceptively simple and almost always implemented wrong the first time. The off-by-one error is basically a rite of passage. The invariant is everything. Practice the template until you can write it without thinking, then apply it to harder shapes: rotated arrays, search on answer space, finding the first position where a predicate flips. Refer to the binary search invariant guide if the off-by-one errors keep coming back.

Heaps underlie top-K problems, merge operations, and Dijkstra. Learn the min-heap and max-heap distinction in your language and know when to invert values for a max-heap in Python. Intervals: the sort-by-start, greedy-merge pattern shows up more often than its problem count suggests. Do not skip it.

Week 5-6 target: 20-25 problems.

Week 7-8: Graphs

Graphs are where most things live in disguise. A grid is a graph. A dependency chain is a graph. Scheduling problems are graphs. An algorithm problem that looks like it has nothing to do with graphs is probably a graph.

BFS, DFS, topological sort, and union-find are the four core moves. Topological sort is worth understanding in both Kahn's algorithm form and DFS form because each reveals something different about the problem. Dijkstra's algorithm belongs here too for anyone targeting Google, Meta, or similar. The lazy-deletion pattern in Dijkstra with a priority queue is a classic implementation trap.

Week 7-8 target: 20-25 problems.

Week 9: Dynamic Programming

DP is the topic people dread most and study worst. It's the liver of interview prep: everyone knows it's important, nobody wants to deal with it, and you can't really skip it.

The fix is to treat DP as a specific transformation, not a zoo of unrelated tricks. Start with the recurrence: can I express the solution to this problem as a function of smaller subproblems? If yes, memoize top-down first. Then convert to tabulation. Then look at whether you can compress the space. The dynamic programming framework covers this arc in detail.

DP problems cluster into recognizable shapes: 1D problems like house robber and climbing stairs, 2D grid and string problems like longest common subsequence, interval DP, and 0/1 knapsack variants. Solve one clean representative of each shape. You do not need to solve every DP problem ever written. You need to recognize what DP problems look like and know which shape you're in.

Week 9 target: 15-20 problems.

Run spaced repetition on month-one material throughout month two

Most prep plans ignore this completely. While you're learning month-two topics, your month-one problems are decaying. Without review, you'll walk into an interview unable to reverse a linked list under pressure because you haven't touched it in five weeks. This is embarrassing. This is also very common.

Set up a review queue. A problem you solved confidently: review in 7 days. A problem you struggled with: 3 days. A problem you blanked on: solve it again within 2 days. You do not need a special app. A spreadsheet works fine. What matters is that reviews happen at all.

Month Three: Simulation Mode (Weeks 10-13)

Month three is where you stop studying and start performing.

The mode shift is what people miss. All of months one and two, you were learning. You allowed yourself to look things up, take your time, review solutions after. Month three simulates the actual interview environment, and that requires a genuinely different mental state. Think of it like a dress rehearsal vs opening night: same material, entirely different stakes.

Week 10: Mixed-set practice under a timer

Stop doing problems by category. Pick a random Medium from your weak areas, set a 25-minute timer, and solve it with no hints. Treat the timer as real. If you don't reach a working solution in 25 minutes, write down exactly where you got stuck, then look at the approach, and mark it for review in three days.

Mixed practice builds the pattern-recognition reflex that single-category drilling doesn't. When an interviewer hands you a problem, they do not label it "Graph - BFS." You have to recognize it cold.

Week 11-12: Mock interviews, 3-4 per week

This is not optional for top-tier companies. Data from interviewing.io, which has analyzed hundreds of thousands of technical interviews, shows that even strong candidates fail individual interviews roughly 22% of the time due to performance volatility. That's not a small number. More reps at mock interviews reduce that variance. You get used to the pressure. You build the communication muscle.

Trainee: "I have 2000+ rating on Leetcode" / Sr. Dev: "I don't care."

The solve count is not the interview. The interview is the interview.

There's a concrete signal in the performance data: successful candidates started writing code at roughly the 27% mark of the interview, compared to 23.9% for candidates who didn't pass. That gap is not about being slower. It's candidates who talked through their approach, caught an edge case before it hit the code, and showed the interviewer what their reasoning looked like. Three extra percentage points of planning time.

The interviewing.io data also found that poor technical ability and poor communication ability are tightly correlated. You almost never see someone who reasons well technically but communicates badly. Which means practicing your verbal walkthrough isn't a soft skill add-on. It's practicing the same cognitive process as solving the problem.

Practice starting every problem the same way: restate the problem, clarify constraints, walk through one example, then describe your intended approach before touching code.

Week 13: Company-specific prep

If you're targeting specific companies, this is when you pull company-tagged problems from LeetCode Premium filtered to the last six months. Large companies with robust tag data (Meta, Amazon, Google, Microsoft) are reliable. Low-frequency tags at smaller companies might represent one interview experience and nothing more.

Also: know the format. Meta weights algorithm rounds heavily. Google probes problem-solving depth. Amazon weaves Leadership Principles into behavioral questions at every stage. Walk in knowing what the loop looks like.

Behavioral prep: don't save it for week 12

Add behavioral prep in month two, not month three. In week 7 or 8, spend one evening writing out 8-10 STAR stories from your actual work. Draft them long. Capture every detail. Then revisit and tighten them in week 10. Engineers who leave this to the last week sound unrehearsed compared to those who've said the same stories out loud 10 times. It's very obvious. Interviewers have heard thousands of these.

Progress Milestones

Use these as checkpoints, not hard deadlines.

End of week 2: Solving any Easy in your current topics within 20 minutes
End of week 4: Can explain recursive and iterative tree traversal without notes
End of week 8: Recognize the correct approach for most Medium graph and tree problems within 2-3 minutes
End of week 10: Completing 3 out of 4 Medium problems correctly under timed, no-hint conditions
End of week 12: Carrying the full interview conversation: approach, code, edge cases, complexity analysis

Your 90-Day DSA Roadmap: The Recap

Month one is foundations. Eight data structures, around 60 Easy problems, daily review cycles. Do not skip Easy problems.
Month two is patterns. Binary search, heaps, graphs, DP. Interleave topics instead of massing them. Run spaced repetition on month-one material throughout.
Month three is simulation. Mixed-set timed practice from week 10, 3-4 mock interviews per week from week 11, company-specific filtering in week 13, behavioral stories drafted by week 10.
Communication and technical ability are correlated in the data. Practicing talking through problems is practicing thinking through them.
Strong candidates still fail roughly 22% of individual interviews. Volume and consistency reduce variance. No single session determines anything.
Start mock interviews at 60% through your plan, not at the end.

If you're in month three and want realistic mock interview reps with immediate feedback, try SpaceComplexity.