How to Learn DSA from Scratch: A 12-Week DSA Roadmap for Beginners

How to learn DSA from scratch when you cannot solve a single problem yet

If you want to know how to learn DSA from scratch, you are probably in one of three places right now. You opened LeetCode, picked an "Easy" problem, stared at it for forty minutes and closed the tab. Or you watched a full playlist on arrays, linked lists and trees, felt like you understood every video, and still could not solve anything on your own. Or you solved sixty problems last semester and cannot remember how a single one of them worked.

All three are normal. I have seen every version of this from students in Pakistan and elsewhere, and none of them mean you are "not a DSA person". They mean the method is wrong, not the brain. This post is the method I would give you if you sat across from me: a phased 12-week DSA roadmap for beginners, how to start LeetCode without drowning, how many problems are actually enough, how to review so you stop forgetting, and whether to do it in C++, Java or Python.

Why most beginners get stuck (and it is not intelligence)

Before the plan, it helps to name the three traps, because the plan is built to avoid each one.

Trap 1: the tutorial loop

Watching someone solve a problem feels like learning because you follow every step. But following is recognition, and solving is recall plus decision-making. You can recognise a hundred solutions and still not be able to produce one. The fix is simple and uncomfortable: every time you watch or read something, close it and rebuild it from a blank file. If you cannot, you have not learned it yet. I wrote more about this in the question on how to start DSA when you cannot solve problems, and the same pattern shows up for people who can follow tutorials but cannot build anything alone.

Trap 2: random problem order

If you solve problems in whatever order LeetCode shows them, each one feels like a fresh puzzle with no connection to the last. Your brain never gets the chance to notice "this is the same shape as yesterday". Problems in the same family, solved back to back, are what build the reflex.

Trap 3: no review, so everything evaporates

You solved Two Sum in March. In May it feels brand new. That is not a memory problem, it is a scheduling problem. Nobody remembers something they saw once. You need to meet each idea again after a few days and again after a few weeks, and the plan below builds that in.

One more thing worth saying: DSA is not the same as competitive programming. Contests reward speed on puzzle-style problems under a clock. Job-oriented DSA rewards clear thinking about trade-offs and clean code. If contests make you miserable, you are allowed to skip them. I answered this directly in I enjoy technology but hate competitive programming.

What "knowing DSA" actually means

When a company tests you on data structures and algorithms, or when you use them at work, three abilities matter:

1. Choosing the right structure for the job: a hash map when you need fast lookup, a heap when you keep needing the smallest item, a queue when order of arrival matters. I explain this way of thinking in choosing a data structure is choosing what to make cheap.
2. Recognising the shape of a problem: "sorted array plus a target" suggests two pointers, "shortest path in an unweighted grid" suggests BFS. That recognition is what fifteen problem shapes and the move that solves each is about.
3. Reasoning about cost: saying out loud why your solution is O(n log n) and what would make it O(n).

Notice that "memorising 300 solutions" is not on that list. Everything below is aimed at those three abilities.

Step zero: pick one language and stop switching

The most common question I get after "where do I start" is "DSA in C++, Java or Python?" Here is the honest answer: the language matters far less than people think, and switching languages halfway matters far more.

My rule: use the language you already write most comfortably. If you have none, use Python for learning speed or C++ if your university and seniors use it and you want their help. Do not switch in week five because a video said another language is "better for interviews". Most interviews let you pick.

Sefism has the DSA roadmap plus language-specific versions for C++, Java and JavaScript, so you can follow the same order with code in your language.

The 12-week DSA roadmap for beginners

This plan assumes about 8 to 10 focused hours a week alongside university or a job. If you have more time, do not rush the order; add more review instead.

By the end you will have solved roughly 110 to 130 problems. That is deliberate, and I explain the number below.

Weeks 1 to 2: foundations without shortcuts

Learn what O(1), O(log n), O(n), O(n log n) and O(n²) mean by counting loops in your own code, not by memorising a chart. Implement a few things by hand once (reverse an array in place, count characters with a hash map, write binary search) so the built-ins stop being magic. If Big-O feels slippery, Grokking Algorithm Complexity and Big-O is a focused way to get it solid. VisuAlgo is a free visual tool that helps a lot with sorting and trees.

Recursion belongs here, early, because trees, graphs, backtracking and DP all depend on it. If recursion is the thing that makes you freeze, spend an extra week on it; Grokking the Art of Recursion is built for exactly that gap.

Weeks 3 to 4: your first patterns

This is where it starts to feel different. Instead of "solve problem 283", you are learning "two pointers moving toward each other" and then solving four problems that all use it. When the fourth one clicks faster than the first, that is the pattern forming.

Weeks 5 to 8: structures that power everything else

Linked lists teach pointer manipulation. Stacks and queues teach you to think about order. Trees teach recursion properly, and heaps teach you "keep the best k items cheaply". Do BFS and DFS on trees before graphs; a tree is just a graph with no cycles, and the jump will feel small.

Weeks 9 to 10: graphs and backtracking

Most beginner graph problems are grids in disguise (islands, rotting oranges, shortest path in a maze). Learn to convert "cells and neighbours" into a graph and run BFS. For backtracking, learn one template (choose, explore, un-choose) and apply it to subsets, permutations and combination sum. Grokking Graph Algorithms is a good companion for this phase.

Weeks 11 to 12: dynamic programming, then mix everything

DP scares people because it is usually taught as magic tables. Start with the recursive brute force, add memoisation, and only then convert to a table. Five or six DP families cover most of what beginners meet. Grokking Dynamic Programming Patterns teaches it family by family, which suits this plan. Then spend your final week on mixed sets where you do not know the pattern in advance, because that is what a real test looks like.

How to start LeetCode without drowning

LeetCode is where most people practise, and it is fine, as long as you use it deliberately.

• Filter by topic, not by "most popular". Pick the pattern of the week and solve 3 to 5 problems from it.
• Start with Easy for two weeks, then move to Medium. Staying on Easy forever is comfortable and teaches little. Hard problems are optional for most people.
• Use a time box. Give yourself 25 to 30 minutes of real attempt. Write down your approach in plain words first, even if it is brute force.
• If stuck, take the smallest hint. Read only the first line of a hint or the approach title, then try again. Reading the full solution at minute ten is the tutorial loop in disguise.
• After reading a solution, close it and rewrite it from memory. Then write two sentences: what the pattern was, and what clue in the problem should have told you.
• Ignore the ranking percentages. "Beats 12%" usually reflects server noise, not your skill.

A curated pattern list such as LeetCode Patterns by Sean Prashad is useful for picking problems by pattern for free. If you want a guided course that teaches the patterns themselves in order, Grokking the Coding Interview: Patterns for Coding Questions is the one I point people to, and Grokking Data Structures and Algorithms covers the structures from the ground up if you want more hand-holding on the basics.

How many LeetCode problems are enough?

This is one of the most searched DSA questions, and the honest answer is: fewer than you fear, if you choose them well.

Most guides written this year land in the same range: around 100 to 150 well-chosen problems organised by pattern is enough for most job-oriented tests, with 3 to 5 problems per pattern building the recognition reflex and returns dropping sharply after a couple of hundred. My own experience matches that. Someone who solved 120 problems in pattern order and reviewed them will usually beat someone who solved 400 at random.

A better question than "how many" is "can I do these three things?":

1. Given a new Medium problem, can I name a likely pattern within five minutes?
2. Can I write a working solution in 30 to 40 minutes and explain its time and space cost?
3. Can I re-solve a problem I did a month ago without looking?

If yes to all three across most patterns, you are ready to apply, whatever your count says. If no, more problems will not fix it; more review will. I answered this in more detail in how many LeetCode problems are enough.

How to review so you stop forgetting solutions

Forgetting is the biggest silent killer of DSA progress. Here is the review system I recommend, and it takes about 20% of your weekly time.

• Keep a simple log. A spreadsheet with: problem name, pattern, the key insight in one line, date solved, and a confidence mark (solved alone, solved with hint, needed solution).
• Re-solve on a schedule. Anything marked "needed solution" gets re-solved after 3 days, then after 2 weeks. Anything "with hint" gets one re-solve after a week.
• Re-solve from a blank file, not by reading your old code. Reading your old code feels like review and is not.
• One mixed session a week. Pick 3 or 4 problems from your log at random, without looking at the pattern column. This trains recognition, which is the actual skill.
• Explain one solution out loud each week, to a friend, a rubber duck or a voice note. If you cannot explain why it works, you memorised it.

The DSA cheat sheet is useful here as a quick refresher of patterns and their complexity before a mixed session; there are language versions for C++, Java and JavaScript too.

Mistakes I see every semester

• Starting with dynamic programming because a senior said it is "the important one". It is the last topic for a reason.
• Doing DSA only, with no projects. Most Pakistani software houses and product companies also look at what you have built. DSA gets you through one round, not the whole process.
• Comparing your count to someone's LinkedIn post. Their 500 problems tell you nothing about their understanding or yours.
• Quitting after one bad week. Weeks 3 and 9 feel hardest for most people. That is the pattern forming, not failure. If exams wreck a week, keep only the review day and resume; how to stay consistent when learning to code has more on this.

My honest read

DSA is not a talent test. It is a small, finite set of ideas that you meet again and again in slightly different clothing. The people who seem "naturally good" usually just saw those ideas in the right order and reviewed them. If you follow a pattern-based order, keep a log, and re-solve what you forget, twelve weeks is enough to go from "I cannot solve anything" to "I can handle most Medium problems with a clear explanation". That is enough for most jobs you will apply to as a fresher.

And please keep perspective. DSA opens a door, but it does not replace building things, reading other people's code, or learning how real systems work. Balance it with a project or two, and look at the wider job-ready roadmap once you are past week six.

FAQ

Can I learn DSA in 3 months from zero?

Yes, if you already know one programming language at a basic level and put in 8 to 10 focused hours a week. The 12-week plan above is designed for exactly that. If you are also learning your first language, add 4 to 6 weeks of plain programming practice first; the programming roadmap covers that.

Should I learn DSA in C++, Java or Python?

Use the language you are most comfortable in. Python is fastest to write, C++ has the most competitive programming material, Java is common in university courses. The concepts are identical and most coding tests let you choose. Switching languages mid-way costs more than any language difference.

How many LeetCode problems are enough for a job?

For most roles, around 100 to 150 problems chosen by pattern, with regular review, is enough. What matters more is whether you can recognise the pattern in a new problem and re-solve old ones without looking.

What if I cannot solve even Easy problems?

That is where almost everyone starts. Go back to one topic, learn it, solve the easiest problems in that topic only, and use small hints instead of full solutions. After two or three weeks of grouped practice, Easy problems start to feel manageable.

Ask your own question

If your situation is different from anything here, browse the career questions library first; someone has probably asked something close. Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: find a DSA study partner and share the problem that finally clicked for you.
• Sefism on YouTube: walkthroughs and talks.

Cover photo by ANOOF C on Unsplash