How Much DSA Is Enough? A Realistic Plan for Placements in 2026
Every student wants a number — 300 problems, 500, 800 — and the number is the wrong question. Here is what interviewers actually test, the topic list that covers almost all of it, and how to know when you have done enough.
Two students from the same class asked me the same question in the same week. The first had solved 640 problems and was panicking that it was not enough. The second had solved 120 and had two offers. When I sat with both of them, the difference was not volume and it was not intelligence. The first had solved 640 problems by reading the editorial whenever he was stuck for more than ten minutes, so he had seen 640 solutions and internalised very few. The second had solved 120 problems slowly, alone, and could explain the reasoning behind every pattern she had learned.
"How much DSA is enough" is the most common question I get from third-year students, and the honest answer disappoints people: it is not a count. It is a set of patterns you can recognise and implement under time pressure while talking to a stranger. You can reach that state in 150 problems done properly, or fail to reach it in 700 done badly.
What the coding interview is actually testing
The round has an unusual structure, and misreading it is the root of most bad preparation. You are given a problem you have probably not seen, forty-five minutes, and an audience. The interviewer is watching four things.
Can you understand and restate the problem before writing code? Can you recognise which family of problems it belongs to? Can you write correct code with the edge cases handled? And can you explain your reasoning out loud while doing all of it?
That last item is why silent practice is insufficient. Students who have solved hundreds of problems in a quiet room often collapse in the interview, not because they cannot solve it but because they have never solved anything while narrating. It is a genuinely different skill, and it takes only a few weeks of practice to acquire — but only if you know it needs practising.
Notice also what the round is not testing. It is not testing whether you have memorised an obscure algorithm. Entry-level interviews in India overwhelmingly draw from a narrow, stable set of topics, and the exotic material students spend months on almost never appears.
The topic list that covers almost everything
Here is the list, ordered by how often it appears in fresher interviews. If you know the first two tiers well, you are prepared for the large majority of entry-level rounds.
| Priority | Topics | Why it matters |
|---|---|---|
| Essential | Arrays, strings, hashing, two pointers, sliding window, sorting, binary search | Appears in nearly every interview and every online assessment |
| Core | Stacks, queues, linked lists, recursion, basic trees and BST, BFS/DFS | The standard second question; very high frequency |
| Important | Heaps, greedy, basic dynamic programming, prefix sums, matrix traversal | Common at product companies and in harder OA sets |
| Situational | Graphs beyond traversal, tries, union-find, bit manipulation | Product companies and specific roles; learn after the above |
| Rarely needed | Segment trees, advanced DP, string algorithms, computational geometry | Competitive programming territory, not fresher interviews |
Students routinely invert this. They begin with dynamic programming because it is famous and difficult, get demoralised in week two, and never build the two-pointer and hashing fluency that would have carried them through eight out of ten actual interviews. Work down the table, not up it.
How many problems do I need to solve?
If you want a number as a planning device, use 150 to 250 problems solved properly — with roughly this distribution: 60 percent easy-to-medium on the essential and core topics, 30 percent medium on the important ones, 10 percent hard, mostly to lose your fear of them.
But "solved properly" is doing all the work in that sentence, so here is what it means. You attempted the problem for at least twenty-five minutes before looking at any hint. If you did look, you closed the editorial and re-implemented from scratch, then wrote one line in your own words about the pattern involved. You revisited it a week later and could still solve it. And you can state the time and space complexity without thinking hard.
A problem that fails those conditions has not been solved; it has been read. Fifty problems that meet them beat four hundred that do not, and this is the single largest difference between students who clear interviews and students who grind for a year and still freeze.
The corollary is that your practice log should record patterns, not counts. "Sliding window, variable size, with a frequency map" is a useful entry. "Problem 1438, solved" is not.
Should I learn DSA or build projects?
Both, and the question is really about sequencing, because the two are tested by different rounds and neither substitutes for the other.
DSA gets you through the online assessment and the first technical round. Without it you are filtered before anyone reads your resume, which is why the assessment round deserves dedicated attention. Projects get you through everything after that: the deep-dive interview, the conversation about trade-offs, the questions that reveal whether you have built anything real. A candidate with excellent DSA and nothing built struggles the moment an interviewer asks how they would design something. A candidate with impressive projects and no DSA usually never gets asked.
A sensible split for a third-year student is roughly an hour a day on DSA through the year, with projects taking the larger weekend blocks and the semester break. Your final-year project is not competing with your interview preparation — it is what the second half of the interview will be about.
The exception is the two months immediately before placements begin, when DSA and mock interviews should dominate, because that is the gate closest in time. Do not start a new project in September of your final year.
A twelve-week plan that works
For a student with reasonable programming basics, twelve weeks at ninety minutes a day is enough to go from unprepared to competitive.
Weeks one to three: arrays, strings, hashing, two pointers, sliding window. Nothing else. Do forty to fifty problems in this block, and finish it able to recognise a sliding-window problem within thirty seconds of reading it.
Weeks four to six: sorting, binary search including the answer-space variety, stacks, queues, linked lists. Another forty problems. Binary search on the answer is the single highest-leverage topic most students skip.
Weeks seven to nine: recursion, trees, BFS and DFS, heaps. This is where students who avoided recursion earlier have to face it, and where a fortnight of discomfort pays for years.
Weeks ten to twelve: basic dynamic programming, greedy, one graph algorithm beyond traversal — plus, crucially, two mock interviews a week with a real person. By now the bottleneck is not knowledge; it is performing under observation.
Throughout, keep a revision loop: every Sunday, re-solve three problems from two weeks earlier. Without this, weeks one to three have decayed by week ten and you will be surprised in the worst possible setting.
Do I need competitive programming?
For the overwhelming majority of fresher roles in India, no. Contest programming and interview preparation overlap for about the first two months and then diverge sharply: contests reward speed on algorithmically exotic problems, while interviews reward clean implementations of common patterns explained out loud. A high contest rating is a genuine signal and a handful of companies weight it, but it is an expensive way to reach a bar you could clear with far less.
Where contests do help is in two specific respects. They build speed under time pressure, which transfers directly to the online assessment, and they force you to handle edge cases properly because hidden tests punish sloppiness. If you enjoy them, one or two contests a week alongside structured practice is a good arrangement, and the enjoyment matters — sustained practice that feels like a game beats disciplined practice you resent.
What you should not do is treat contest rating as the measure of your readiness. I have met students with strong ratings who could not explain their own solution slowly enough for an interviewer to follow, and students who had never entered a contest converting offers comfortably. Different tests, different training.
Where AI tools help and where they quietly destroy the skill
This is new enough that most advice has not caught up. Using an AI assistant to explain a concept you do not understand, to review your solution after you have written it, or to generate practice variations of a pattern you are drilling is genuinely useful — it is a patient tutor available at midnight.
Using one to produce the solution while you are practising destroys the exact ability the interview measures. The skill is generating the approach under uncertainty; if you outsource that, you are training a different muscle and it will show the moment the tool is unavailable. We wrote about this at length in using AI tools without hollowing out your skills, and the rule there applies here without modification: struggle first, then check.
A practical discipline: no assistance for the first twenty-five minutes of any problem, and never for anything you would call a mock.
Knowing when you have done enough
The signals are behavioural, not numerical. You are ready when you can read an unfamiliar medium problem and name a plausible approach within two minutes; when you can write a clean solution without looking up standard library syntax; when you can state complexity immediately; when you can talk through your reasoning without going silent; and when a problem you have never seen produces curiosity rather than panic.
If those are true at 140 problems, stop grinding and switch to mocks. If they are not true at 500, the volume is not the problem — the method is, and the fix is to slow down, work alone for longer before looking, and start writing down patterns instead of counts.
There is one more signal worth respecting. If your fundamentals are genuinely shaky — if loops and recursion themselves are uncertain — then problem-solving practice is the wrong tool and will just produce demoralisation. Go back to the basics for three weeks first; the honest version of that recovery is in rebuilding after a bad semester.
What the two students did next
The student with 640 problems stopped adding new ones. He spent six weeks re-solving 60 of them cold, alone, writing one line per problem about the pattern, and doing two mocks a week with a friend. He converted his fourth interview after that.
The student with 120 kept doing exactly what she had been doing. She did not need more problems. She needed the confidence to stop counting, which she had already found.
Do the work properly and the number takes care of itself. Do it badly and no number will save you.
Grinding problems and still freezing in interviews? Talk to a Career Call counsellor. We'll run a mock coding round, find out whether your gap is knowledge, method, or nerves, and build a twelve-week plan around the real one.