DSA Roadmap 2026: Zero to Hired in 6 Months (Complete Guide)

I solved three hundred LeetCode problems... and I still failed the interview.

Sound familiar? Most people who start DSA quit within three weeks. Not because they're not smart enough. Because nobody told them what to study, in what order, and how to practice.

So today, you're getting the complete roadmap. Every topic. The right order. How many weeks each one takes. The free resources. The daily routine. And how real interviews are actually judged.

And stay till the end, because there's one practice method in here that changes how you solve problems. Most people never learn it.

Welcome to Compiled Canvas. This is Episode One of our DSA series, and every episode after this builds on this roadmap.

Here's the plan for today. What DSA is, and why companies test it. The myths that stop you from starting. Which language to pick. The full roadmap, phase by phase. How to practice so you don't forget. Three-month and six-month plans. Free resources. How interviews really work. And the mistakes to avoid.

Let's go.

First, what is DSA? Data Structures and Algorithms. A data structure is a way of storing data so you can use it efficiently. An algorithm is a step-by-step method to solve a problem with that data.

Picture a library. If the books are thrown in a pile, finding one takes forever. If they're sorted on shelves by subject, you find any book in seconds. The shelves are the data structure. The way you search them is the algorithm.

Code works the same way. Searching a million items one by one can take a million steps. With binary search on sorted data, it takes about twenty. That difference is what DSA teaches you.

So why do companies test it, when you'll never reverse a linked list at work? Four reasons. One: it tests problem-solving, not memory. They want to see how you think when you face something new. Two: it's a fair filter at scale. Thousands of people apply, and DSA doesn't depend on which framework you used. Three: it shows you write efficient code. At scale, a slow algorithm costs real money and real users. Four: it shows how you communicate. You explain, take hints, and fix bugs live. That's a real workday.

Who asks DSA? Almost every product company. Google, Amazon, Microsoft, Flipkart, Swiggy, Zomato, PhonePe, Uber, Atlassian, and most well-funded startups. Even service companies like TCS, Infosys and Wipro have coding rounds, especially for their higher-paying roles.

So whether you're a fresher or switching jobs, DSA is the one skill that opens the most doors.

Before the roadmap, let's kill five myths. Quick question: how many of these have you believed?

Myth one: "I'm bad at maths, so I can't do DSA." You need school-level maths. Basic counting, simple logarithms, and remainders. If you can work out a discount at a shop, you can learn DSA.

Myth two: "I need to solve a thousand problems." No. Around two hundred and fifty to three hundred and fifty well-chosen problems, understood deeply, beat a thousand random ones.

Myth three: "I need a computer science degree." Strong engineers come from mechanical, electrical, even non-engineering backgrounds. Interviewers care whether you can solve the problem, not what your degree says.

Myth four: "Competitive programming is required." It's a great skill, but interviews test standard patterns and clear thinking, not contest tricks under a timer.

Myth five: "If I can't solve it in ten minutes, I'm not smart enough." Everyone gets stuck. Pattern recognition is built, not born. The tenth time you see a sliding window problem, you'll spot it in thirty seconds.

Now, three rules for the whole journey. Consistency beats intensity. Two hours every day beats fourteen hours on Sunday. Understand, don't memorize. If you can't explain why a solution works, you don't know it yet. And being stuck is learning. The struggle is where your brain builds the pattern.

Next, the question everyone asks: which language? Java has a strong Collections library, and it's everywhere in Indian companies. It's a little verbose, and it's great for backend roles. C plus plus is the fastest, with a rich standard library, and it's popular in competitive programming. Watch out for pointer bugs as a beginner. Python is short and easy to read. It's slower, and some interviewers expect you to know how its built-ins work. JavaScript is fine if you're a frontend developer, but it has no built-in heap.

The rule is simple. Pick the language you already know best, and stick with it. Switching halfway is the biggest time-waster there is. Java, C plus plus and Python are accepted everywhere. In this series we use Java, but every idea works in any language.

Whatever you pick, learn the basics first: variables, loops, conditions, functions, arrays, strings and classes. In Java, also get comfortable with ArrayList, HashMap, HashSet, Stack, Deque and PriorityQueue.

Now, the main event. The complete roadmap, in seven phases. The order matters, because every phase builds on the one before. So don't jump to graphs or dynamic programming before arrays and recursion are solid.

Phase one: Foundations. One to two weeks, about fifteen to twenty problems. Start with time and space complexity, Big O notation. It's how you measure whether a solution is fast enough. Learn the ladder: O of one, O of log n, O of n, O of n log n, O of n squared, and O of two to the n. Here's a rule worth remembering. A computer does roughly a hundred million simple operations per second. Pause and screenshot this one. If n is up to twenty, exponential is fine. Think recursion and backtracking. Up to a thousand, n squared works. Up to a million, you need n log n, or linear. Beyond a billion, you need log n, or constant. Round out phase one with basic maths: primes, GCD, modulo, and the Sieve of Eratosthenes. Plus bit manipulation: AND, OR, XOR and shifts. XOR alone cracks a surprising number of questions.

Phase two: Linear data structures. Three to four weeks, sixty to seventy problems. This is the most important phase, because about forty percent of interview questions are on arrays and strings. Arrays: traversal, reversal, rotation and matrices. Prefix sum, to answer range queries instantly. Two pointers, from both ends or slow and fast, for pair sums and removing duplicates. Sliding window, for things like the longest substring without repeating characters. Kadane's algorithm, for the maximum subarray sum. Strings: palindromes, anagrams and frequency arrays. And hashing, with HashMap and HashSet, which turns many slow brute-force answers into linear ones. If you master only one phase deeply, make it this one.

Quick pause. If this roadmap is already helping, subscribe to Compiled Canvas, so every episode in this series lands on your home screen, in order.

Phase three: Searching, sorting and recursion. Three weeks, forty to fifty problems. Binary search, including first and last occurrence, and the powerful "binary search on the answer" pattern. Sorting: the simple ones to understand the basics, then merge sort and quick sort properly, because they're asked directly. Recursion: base case, recursive case, and how the call stack works. Draw the recursion tree at first. And backtracking: subsets, permutations, N Queens and sudoku, all with one template. Choose, explore, un-choose. Recursion is where most beginners struggle. Don't rush it. Once it clicks, the second half of this roadmap gets much easier.

Phase four: Linked lists, stacks and queues. Two weeks, thirty to thirty-five problems. Build a linked list from scratch, reverse it, find the middle, and detect a cycle with fast and slow pointers. Stacks for balanced brackets, and the monotonic stack for next greater element problems. Queues and deques, the foundation of BFS and the sliding window maximum. And one interview favourite: the LRU cache, a HashMap plus a doubly linked list.

Phase five: Trees and heaps. Three to four weeks, forty-five to fifty-five problems. Binary trees: the four traversals, height, diameter, views, and the lowest common ancestor. Binary search trees: search, insert, delete and validate. Heaps and priority queues: top K elements, merging K sorted lists, and the median of a data stream. Here's the secret to trees. Solve it for the left subtree, solve it for the right subtree, and combine the answers. See that once, and trees become one of the easiest topics.

Phase six: Greedy and graphs. Three to four weeks, forty to fifty problems. Greedy: activity selection, meeting rooms and jump game, and learning when greedy fails. Graph basics: adjacency lists, BFS, DFS, and number of islands. Cycle detection and topological sort, like course schedule. Shortest paths: BFS for unweighted graphs, Dijkstra for weighted ones, and Bellman Ford for negative weights. Then union find, and minimum spanning trees. And remember: many graph problems don't look like graphs. A grid, a word ladder, a list of prerequisites. Spotting the hidden graph is half the battle.

Phase seven: Dynamic programming and advanced topics. Four to five weeks, fifty to sixty problems. Dynamic programming sounds scary, but it's really just recursion plus memory. If you solve the same subproblem twice, store the answer. Start with simple problems like climbing stairs and house robber. Then grids, the knapsack family and coin change, subsequences like longest common subsequence and edit distance, and the stock problems. For top product companies, add dynamic programming on trees, bitmask problems, tries, segment trees and Fenwick trees. And use one method for every dynamic programming problem. Write the recursive brute force. Add memoization. Convert it to a bottom-up table. Then optimize space. Never jump straight to the table.

So in total: about five to six months, and around three hundred problems. Targeting service companies or startups? Phases one to five, plus basic dynamic programming, is enough. Aiming for Google or Amazon? Finish all seven.

Remember the practice method I promised? Here it is. Because knowing the topics isn't enough. How you practice decides whether you remember anything a month later.

Six steps. Step one: read and restate. Read the problem twice, and say it back in your own words. Step two: work an example by hand, then try an edge case. Empty input, one element, duplicates, negatives. Step three: brute force first. Any correct answer, even a slow one, with its complexity. Step four: optimize with patterns. Ask yourself. Is it sorted? Think binary search, or two pointers. A contiguous subarray? Sliding window, or prefix sum. Need fast lookup? Hashing. Top K? A heap. Every combination? Backtracking. Overlapping subproblems? Dynamic programming. Step five: code it cleanly, then dry-run it line by line. Step six: review and record. Compare with the best solution, and write the key insight in one line.

Stuck? Use the twenty-forty rule. Twenty minutes with no new idea, take a hint. Forty minutes, read the solution. Then close it, and write the code yourself from memory.

And the step most people skip: spaced revision. Re-solve every problem after three days, after one week, and after one month. Keep a simple tracker. The problem, the pattern, the key insight, and three revision dates. That sheet becomes gold the week before your interview.

Now let's turn this into a schedule. Plan A is six months, for working professionals, or anyone starting from zero. About two hours on weekdays, and four on weekends. Month one: foundations, arrays, prefix sum and two pointers. Month two: sliding window, strings, hashing and binary search. Month three: sorting, recursion, backtracking and linked lists. Month four: stacks, queues, trees and heaps. Month five: greedy and graphs. Month six: dynamic programming, tries, revision and mock interviews.

Plan B is a three-month fast track, if you already know a language and have four or more hours a day. Month one: complexity, arrays, strings, hashing, two pointers, sliding window, binary search and sorting. Month two: recursion, backtracking, linked lists, stacks, queues, trees and heaps. Month three: graphs, greedy, core dynamic programming and mock interviews. Be honest with yourself. If you burn out in week five, the six-month plan would have taken you further.

Your daily two hours look like this. Twenty minutes learning or revising a concept. Seventy minutes solving two problems with the six-step method. Twenty minutes re-solving an old problem. And ten minutes writing insights in your tracker. Weekdays are for new topics. Saturday is one timed contest. Sunday is revision, and a little rest. Burnout is real.

You don't need an expensive course. It's all free. LeetCode, for practice and company-tagged questions. GeeksforGeeks, for theory. NeetCode one fifty, or Blind seventy-five, for a short list of the most-asked patterns. Striver's A to Z sheet, for a full path that matches this roadmap. VisuAlgo, to see algorithms animated. And weekly contests on LeetCode or Codeforces, for speed. Pick one from each, and finish it. And beware of tutorial hell. For every hour of watching, spend two hours solving.

Now, the real interview. Because solving at home and solving in front of someone are very different.

Most companies start with an online assessment: two or three problems in sixty to ninety minutes. Then one to three live DSA rounds. Experienced roles add design rounds. And there's always a behavioural round.

A forty-five minute DSA round flows like this. Five minutes of intro. Five minutes to clarify. Ten minutes on your approach. Twenty minutes to code. And five minutes to test and ask questions. Clarify first. Ask about input size, duplicates, negatives and empty input. Say the brute force out loud, with its complexity. Optimize while thinking aloud, because silence is your enemy. Get agreement before you code. Write clean code, then test it yourself, before they ask.

And here's what they actually score. Problem-solving. Coding. Communication. Testing. The perfect answer is only one part. People who explain beautifully but don't fully finish often get selected, and people who silently write correct code often get rejected. So do at least five mock interviews before the real ones.

Finally, ten mistakes to avoid. One: jumping between resources. Two: skipping basics to reach hard topics. Three: counting problems instead of patterns. Four: reading solutions too early. Five: never revising. Six: only doing easy problems. Aim for thirty percent easy, sixty medium, and ten hard. Seven: practising in silence. Eight: ignoring complexity. Nine: waiting to feel ready. Start applying around month four or five. Ten: quitting after a bad week. Missing one day is fine. Missing two in a row is how habits die.

Let's recap. Complexity first. Then arrays, strings and hashing. Then searching, sorting and recursion. Linked lists, stacks and queues. Trees and heaps. Greedy and graphs. And finally, dynamic programming. About three hundred problems in five to six months, with the six-step method and spaced revision.

Your homework, today. Pick your language and your plan. Create a free LeetCode account. Make your tracker sheet. And comment below: Day one, your language, your plan. Writing it down makes you far more likely to stick with it.

And don't forget to subscribe to Compiled Canvas, so you don't miss anything new in tech and the job market. Like the video, so it reaches more students. And hit the bell, so you catch the next episode the moment it drops.

Share this with that one friend who keeps saying, "I'll start DSA on Monday." You know who.

Next episode, we start for real: time and space complexity, and how to find the Big O of any code in under a minute.

Keep coding, stay consistent, and I'll see you in the next one.