Most DSA roadmaps you find are written for people preparing for placements two years from now. Following one in your first year is how you end up six months in, able to recite what a segment tree is, and unable to build anything. This is the version for someone who has just finished a semester of C.
The honest order
You do not need a new language. Whatever your college taught you — C, C++, Python, Java — is enough for everything below. Switching languages is the most common first-year procrastination, because it feels like progress and costs nothing to start.
Months 1–2: the things everything else is built on
- Arrays. Traversal, insertion, deletion, two-pointer problems, prefix sums. This is 40% of everything you will ever be asked.
- Strings. Reversal, palindromes, frequency counting, basic parsing.
- Time complexity. Not the formal definition — the practical skill of looking at two nested loops and saying "this is n squared, and n is 10⁵, so this will not finish."
Spend longer here than feels reasonable. People who are good at DSA later are almost always people who were unusually solid on arrays early.
Months 3–4: recursion, and then sorting and searching
- Recursion. Factorial, Fibonacci, tower of Hanoi, then subsets of a set. The last one is where it clicks or does not.
- Binary search. On an array, then on an answer range. The second one is the actually useful version and almost nobody teaches it in first year.
- Sorting. Write bubble and insertion once to feel why they are slow, understand merge sort properly, then use your language's built-in sort forever after.
Months 5–6: the first real data structures
- Hash maps. Whatever your language calls them. These solve an enormous share of problems and are underused by beginners because they feel like cheating.
- Stacks and queues. Including what they are actually for — balanced brackets, undo, BFS.
- Linked lists. Learn them, but know that in real code you will almost never write one. They exist on this list because interviews ask.
After six months
Trees, then graphs, then dynamic programming — in that order, and not before. If you reach here inside first year you are well ahead.
What to skip in first year
This is the part other roadmaps will not tell you, because a longer list looks more authoritative.
- Segment trees, Fenwick trees, tries. Competitive programming tools. You will not need them and learning them early builds nothing underneath.
- Advanced graph algorithms — Dijkstra, network flow. Later.
- Bit manipulation tricks beyond the basic AND, OR, shift.
- Memorising a 450-problem sheet. Sheets are reference lists, not curricula. Working through one in order, from problem 1, is how people burn out in month two.
How many problems, honestly
Two a day, consistently, beats twenty on a weekend. Around 150–200 problems over your first year, properly understood, puts you ahead of most of your batch. The number itself is not the achievement — being able to look at a new problem and recognise which shape it is, is.
A problem is "done" when you could re-solve it a week later without looking. If you cannot, you read a solution and felt like you learned something. That feeling is not the same as learning.
The mistake that costs the most time
Doing DSA and nothing else for a year.
DSA is one skill. It gets you through interview rounds. It does not teach you how to build software, how to work with someone else's code, how to finish something, or how to explain what you made — and those are the things that actually get you an internship, and the things nobody can assess from a LeetCode count.
Run them in parallel. Two problems a day, and one small project every couple of months. The project is where you find out that knowing binary search and building a working thing are completely different skills.
What a "small project" means in first year
Not an app with login and payments. Something that takes a weekend and does one thing: a command-line tool that renames files in bulk, a script that reads your timetable and tells you what is next, a program that finds duplicate photos on your laptop.
Boring is fine. Finished is the point. Finishing something small, badly, teaches you more than any tutorial, and it is the first thing on your CV that is actually yours.