The DSA roadmap for 2026: what to learn, in what order, and how long it takes
Most data structures and algorithms roadmaps are a list of topics with no order, no time estimates and no opinion about what to skip - which is exactly why people bounce off them in week two. This guide is ordered by dependency, priced in hours, and blunt about the parts you can safely ignore. Set your real weekly hours and it will tell you when you finish.
The roadmap in 60 seconds
Learn DSA in this order: Big-O and cost (8h), arrays and two pointers (16h), recursion and backtracking (16h), sorting (12h), searching and hashing (16h), linked lists, stacks and queues (16h), trees and heaps (24h), graphs (24h), and finally greedy and dynamic programming (32h). That is 164 hours in total: about 17 weeks at 10 hours a week, or 9 weeks at 20. Each phase depends on the ones before it, and the most common failure is attempting dynamic programming before recursion feels natural.
How long does it take to learn DSA?
The honest number is 164 hours of focused work to cover everything below to a level you can defend in an interview. That is not the same as the number of hours you will spend, because the common failure mode is passive time: watching a lecture, reading a solution, nodding along. Those hours do not count here. The estimates assume you are the one typing.
Set your genuine weekly availability - not your aspirational one - and take the finish date seriously. Someone doing five real hours a week for eight months will comprehensively beat someone who plans twenty and quits in week three.
the realistic student pace - 164hours of focused work, not hours with a video playing in another tab. Every estimate assumes you write the code yourself rather than reading someone else's.
Why the order matters more than the list
Every topic here depends on the ones above it, and the dependencies are not decorative. Dynamic programming is recursion plus caching, so attempting DP before recursion is comfortable produces memorised templates rather than understanding - you will solve the exact problems you drilled and freeze on anything phrased differently. Graph traversal is a stack or a queue depending on which you reach for, so it lands far more easily once stacks and queues are second nature. And all of it is an argument about cost, which is why counting steps comes first rather than last.
The most common way people fail at DSA is not laziness or lack of talent. It is starting at a topic whose prerequisites they never built, concluding they are bad at this, and quitting. The order is the fix, and it is free.
The nine phases at a glance
| # | Phase | Hours | Weeks at 10h | Difficulty | What it unlocks |
|---|---|---|---|---|---|
| 1 | Cost, and how to count it | 8h | 0.8 | Gentle | The vocabulary every later phase uses |
| 2 | Arrays and the two-pointer patterns | 16h | 1.6 | Gentle | Roughly a third of easy and medium interview questions |
| 3 | Recursion and the call stack | 16h | 1.6 | Moderate | Trees, graphs, backtracking and all of dynamic programming |
| 4 | Sorting | 12h | 1.2 | Moderate | Binary search, heaps, and any question with 'sorted' in it |
| 5 | Searching and hashing | 16h | 1.6 | Moderate | Most optimisation steps in medium-level problems |
| 6 | Linked lists, stacks and queues | 16h | 1.6 | Moderate | Tree and graph traversal, and a class of pointer questions |
| 7 | Trees and heaps | 24h | 2.4 | Hard | Priority queues, ordered maps, and Dijkstra later |
| 8 | Graphs | 24h | 2.4 | Hard | The majority of hard-tier interview questions |
| 9 | Greedy and dynamic programming | 32h | 3.2 | Hard | The last tier of interview difficulty |
Phases 7 to 9 are 80 of the 164 hours between them - almost half the roadmap. That is exactly where people underestimate, plan three weeks for what needs eight, and lose momentum. Plan for it now.
Every phase in detail
Each phase below answers the same five questions: what it covers, why it sits here, the three things to build, the mistake almost everyone makes, and how you know you are finished. Build the three things. The reading is not the work.
Phase 1Cost, and how to count it
8h · GentleBig-O notation, best vs worst case, counting steps instead of timing them
Every later decision in this roadmap is a cost comparison. Skip this and the rest becomes memorisation with no way to judge one approach against another.
- A linear search that counts and prints its own comparisons
- The same search run against the best, worst and missing cases
- A loop-inside-a-loop, so you feel n squared rather than read it
Memorising the complexity of common algorithms without ever counting steps yourself. You end up reciting O(n log n) without being able to derive it.
You can look at an unfamiliar loop and say its complexity out loud, and explain why the worst case is the one that matters.
Phase 2Arrays and the two-pointer patterns
16h · GentleIndexing, in-place modification, two pointers, sliding window, prefix sums
The highest ratio of interview questions to concepts anywhere in this list. Two pointers and sliding window alone cover a startling share of screening rounds.
- Reverse an array in place, without a second array
- Two-sum on a sorted array, using two pointers rather than a map
- Longest substring without repeats, as a sliding window
Jumping to a hash map for everything. Reach for pointers first when the input is sorted - it costs no extra memory and teaches the technique.
You recognise a sliding-window problem from the phrase 'contiguous subarray' before reading the rest of the question.
Phase 3Recursion and the call stack
16h · ModerateBase cases, the call stack, backtracking, permutations and subsets
Trees, graphs and dynamic programming are all recursion wearing different clothes. This is the single highest-leverage phase in the roadmap.
- Factorial and Fibonacci, watching frames stack and unwind
- Every subset of a set, using choose / recurse / un-choose
- N-Queens, so you feel what pruning buys you
Trying to trace the whole recursion in your head. Trust the recursive call to return the right answer and get the base case right; that is the skill.
You can write a recursive solution without tracing it, because you trust the smaller call.
Phase 4Sorting
12h · ModerateInsertion, merge and quicksort, stability, and what your language actually does
You will almost never write a sort. You will constantly choose one, and be asked to justify the choice and its cost.
- Insertion sort, then measure it on nearly-sorted input
- Merge sort, paying attention to the merge step
- Quicksort, then feed it sorted input and watch it collapse
Learning the code and skipping the trade-offs. Stability and memory are what interviewers actually probe, not whether you can reproduce merge sort.
You can say which sort you would use, why, and what it costs in memory as well as time.
Phase 5Searching and hashing
16h · ModerateBinary search boundaries, searching the answer space, hash maps, sets
Hashing converts more O(n squared) solutions into O(n) than any other single tool. Binary search is the most commonly failed whiteboard question there is.
- Binary search with an explicit invariant, plus a lower-bound variant
- A hash map from scratch: buckets, collisions, load factor
- Two-sum, group-anagrams and first-unique using a map
Treating O(1) as a guarantee. It is a property of the hash function; a bad one collapses the map into a linked list.
You can write binary search correctly from blank, and you spot 'have I seen this before?' as a map problem instantly.
Phase 6Linked lists, stacks and queues
16h · ModeratePointer surgery, cycle detection, LIFO and FIFO, monotonic deques
Cheap to learn relative to their payoff, and stacks versus queues decide the behaviour of every traversal you write later.
- A singly linked list, reversed in place with three pointers
- Floyd's cycle detection, using no extra memory
- Balanced brackets with a stack; sliding-window max with a deque
Overwriting a next pointer before saving it, and losing the rest of the list. Save, then rewire.
You can reverse a list on paper without losing it, and you know which container turns a traversal depth-first or breadth-first.
Phase 7Trees and heaps
24h · HardTraversals, binary search trees, balance, heaps, top-K and streaming
Where recursion stops being an exercise and becomes the only sane way to write the code. Also where most people start to struggle, so budget accordingly.
- All four traversals, and notice in-order comes out sorted on a BST
- Insert into a BST, then insert sorted data and watch it degenerate
- A binary heap in an array, then top-K over a stream
Assuming a BST stays balanced. Sequential inserts turn it into a linked list, which is precisely why TreeMap exists.
You solve tree problems by asking 'what do I need from my children?' rather than tracing the whole tree.
Phase 8Graphs
24h · HardAdjacency lists, BFS, DFS, shortest paths, topological order
Most problems labelled 'hard' are graph problems that were not described as graphs. Grids, dependencies, friend networks and state machines are all graphs.
- Adjacency list from an edge list, then BFS and DFS over it
- Number of islands on a grid - the graph nobody calls a graph
- Dijkstra with a priority queue; topological sort for dependencies
Forgetting the visited set. Without it your traversal loops forever on any cycle, and every real graph has cycles.
You can model a word problem as nodes and edges, then pick BFS or DFS with a reason.
Phase 9Greedy and dynamic programming
32h · HardExchange arguments, memoisation, tabulation, the classic DP shapes
Last on purpose. DP is recursion plus caching, and attempting it before recursion is comfortable produces memorised templates instead of understanding.
- Fibonacci three ways: naive, memoised, tabulated
- Coin change and knapsack, top-down before bottom-up
- Longest common subsequence, filling the grid by hand first
Starting with tabulation. Always write the recursion first, then add a cache, then convert to a table if you need to.
You can spot overlapping subproblems, write the recurrence, and only then decide top-down or bottom-up.
These nine phases, as an actual course
Flame teaches this roadmap in order, and every algorithm runs on screen in Java - one step at a time, so you watch the variables move instead of imagining them. Chapter 1 is free and needs no account.
Pick a path for your goal
The full roadmap is the right answer for most people, but not for everyone. Four situations come up often enough to deserve their own plan.
Campus placement in 6 months
Run phases 1 to 8 at 10 hours a week and treat phase 9 as a stretch goal. Placement tests lean heavily on arrays, strings, hashing and trees; graphs appear, DP rarely does. Prioritise finishing phases 2 and 5 to real depth over touching every topic once.
Product-company interviews (FAANG-tier)
You need all nine, and phase 9 is not optional. Budget 20 hours a week for 9 weeks, then spend a further 4 weeks on mixed problems under timed conditions. Graphs and DP are where these interviews are decided.
Switching careers into development
Go slower and wider. 5 hours a week over 8 months, with phases 1 to 6 given extra time, builds far sturdier foundations than a sprint. You are constructing programming intuition, not just interview answers.
You have an interview in three weeks
Do not attempt the roadmap. Take phases 1, 2 and 5 only - cost, arrays and hashing - and drill them hard. Those three cover the largest share of screening rounds, and depth in three areas beats a thin pass over nine.
Sample schedules: 8 weeks and 17 weeks
Two concrete plans. The 17-week version is the sustainable one at ten hours a week; the 8-week version assumes twenty and is genuinely demanding. Both front-load the cheap phases so momentum builds early.
| 17-week plan (10h/wk) | 8-week sprint (20h/wk) |
|---|---|
| Weeks 1–3: phases 1 and 2 | Week 1: phases 1 and 2 |
| Weeks 4–5: phase 3, recursion | Week 2: phase 3, recursion |
| Weeks 6–7: phases 4 and 5 | Week 3: phases 4 and 5 |
| Weeks 8–9: phase 6 | Week 4: phase 6 |
| Weeks 10–12: phase 7, trees | Weeks 5–6: phases 7 and 8 |
| Weeks 13–15: phase 8, graphs | Weeks 7–8: phase 9, DP |
| Weeks 16–17+: phase 9, DP | Then: mixed problems, timed |
Whichever you pick, keep one session a week for revisiting old phases. Without it, phase 2 will have faded by the time you reach phase 8, and graph problems lean on array technique constantly.
What to skip, and what to do instead
A roadmap is as much about exclusions as inclusions. These are the topics that consume disproportionate time for the return, and the habits that pay for themselves within a fortnight.
- Red-black and AVL rotations by hand - know why balance matters, then use TreeMap
- String algorithms like KMP and Rabin-Karp until everything else is solid
- Segment trees and Fenwick trees unless you compete in contests
- Writing your own sort for production code - you are choosing one, not building one
- Grinding 500 problems before you can explain why an index makes a lookup fast
- Learning five languages at once; pick one and go deep
- Write every data structure once from scratch, then never again
- Predict the output before running it - being wrong is where the learning is
- Redo a solved problem one week later, from a blank file
- Explain your solution out loud as if teaching it; gaps surface immediately
- Track the cost of your solution, not merely whether the tests pass
- Keep a list of every bug you hit twice - that list is your real syllabus
How to practise so it actually sticks
The difference between people who finish a roadmap and people who restart one every six months is almost never the material. It is the loop they use while working through it. Three habits do most of the work.
Predict before you run. Before executing anything, commit to what it will print and how many steps it will take. Being wrong is the entire point: a violated expectation is the moment a mental model actually updates, and it is why watching code execute beats reading it.
Redo from blank. A solved problem teaches you very little on the day you solve it. Delete it, wait a week, and write it again from an empty file. If you cannot, you did not learn it - you recognised it, which is a different and far weaker thing.
Explain it out loud. Narrating a solution as if to another person exposes gaps instantly, because vague understanding cannot survive being spoken in complete sentences. This is also precisely what an interview asks you to do, so the practice is the performance.
Does DSA still matter in the AI era?
More than it did, and for a sharper reason. AI produces a working solution in seconds; what it cannot reliably tell you is whether that solution survives a hundred thousand rows, or which of three approaches suits the data you actually have. Reviewing generated code is now a daily task for most developers, and reviewing it means reasoning about cost - which is precisely what this roadmap teaches.
Interviews have shifted the same way. Fewer questions ask you to reproduce an algorithm from memory; more ask why you chose one, what it costs, and what breaks first under load. Those are answerable only if you understand the machinery underneath, and they are noticeably harder to fake than a memorised template ever was.
Frequently asked questions
How long does it take to learn DSA?
About 164 hours of focused work to cover the nine core phases. At 10 hours a week that is roughly 17 weeks; at 20 hours a week, about 9 weeks. The variable is not intelligence, it is consistent hours and whether you write the code yourself rather than reading someone else's.
What order should I learn data structures and algorithms in?
Cost and Big-O first, then arrays and two pointers, recursion, sorting, searching and hashing, linked lists and stacks/queues, trees and heaps, graphs, and finally greedy and dynamic programming. Each phase depends on the ones before it. Attempting DP before recursion is comfortable is the single most common mistake.
Can I learn DSA in 3 months?
Yes, at roughly 14 hours a week. That is a genuine commitment - about two hours every day - and it assumes you are writing code rather than watching it. If you only have 5 hours a week, plan for 8 months and accept it, rather than sprinting and burning out in week three.
Which language should I use for DSA?
Whichever one you already write most comfortably. Java, C++ and Python are all fine and all widely accepted in interviews. The language matters far less than knowing its standard library well - what its sort guarantees, how its hash map behaves, and what its list actually costs.
How many problems should I solve to learn DSA?
Far fewer than most people assume, done properly. Solving 150 problems while tracking the cost of each solution, and redoing them from blank a week later, beats grinding 500 you cannot explain. Depth per problem matters more than the count on your profile.
Should I learn DSA in 2026 when AI can write code?
Yes, and for a sharper reason than before. AI produces a working solution in seconds, but it cannot tell you whether that solution survives scale or which of three approaches suits your data. Reviewing generated code means reasoning about cost, which is exactly what DSA teaches.
Is it better to learn DSA by reading or by watching it run?
By running it. Reading an algorithm gives you a description; watching the variables change gives you a mental model you can reuse on an unfamiliar problem. The fastest loop is to predict what the code will do, run it, and pay close attention wherever you were wrong.
Do I need DSA for web development jobs?
For the interview, usually yes. For the daily work, less than interviews imply - but the cost reasoning genuinely matters the moment your table grows past a few thousand rows, your endpoint starts timing out, or you have to choose between a map and a list in a hot path.
Stop reading about algorithms. Watch one run.
Every argument in this guide is a counting argument, and counting arguments are far easier to believe when you can see the steps. Flame animates real execution line by line - every comparison, every swap, every frame on the call stack.