DSA for Placements: How Much Is Actually Enough

The honest answer to how much DSA for placements you need is that it depends on which companies will actually interview you, and almost nobody asks that question before they start preparing. The usual pattern looks like this: a student opens a 450-problem sheet in July, grinds arrays for two weeks, reaches dynamic programming, feels stupid, and quietly stops. The test they were preparing for was a TCS NQT slot in September, where the coding section asked them to reverse a string and find the second largest element in an array.

There are three separate bars in Indian campus and off-campus hiring, and they are nowhere near the same height. Preparing for the wrong one costs you months you do not have. This article maps the three bars, gives you a topic order, explains why the number of problems solved is the wrong thing to count, and covers the part that decides most offers — which is not the coding round at all.

Three bars, not one

When people argue about DSA on the internet, they are usually arguing past each other because they are describing different hiring processes. Someone who cleared Amazon will tell you graphs and DP are non-negotiable. Someone who joined Infosys will tell you they barely wrote a loop. Both are telling the truth about their own experience.

Sort the market roughly into three tiers.

Tier one: large IT services. TCS, Infosys, Wipro, Cognizant, Capgemini, LTIMindtree, Accenture, HCLTech. These companies hire in very large numbers through standardised tests. The screening is a long aptitude and reasoning paper with a smaller coding section attached. The coding section is far easier than most students assume. It is closer to your first-year programming lab than to a competitive programming contest.

Tier two: mid-tier product companies and premium service roles. Zoho, Freshworks, Persistent, Publicis Sapient, Deloitte USI tech roles, TCS Digital and Prime, Infosys Power Programmer, plus a long tail of Bengaluru, Pune and Hyderabad product companies and funded startups. Here DSA is a real filter, but a bounded one. You need to write correct code under time pressure and reason about complexity out loud.

Tier three: top product companies. Google, Amazon, Microsoft, Atlassian, Uber, Adobe, Salesforce, Flipkart, Swiggy, Zomato, PhonePe, Razorpay, plus the quant and HFT firms. Genuine DSA depth is the bar. Graphs, dynamic programming, and the ability to reason about a problem you have never seen are all in scope, and the interviewer is deliberately probing the edge of what you know.

The tiers also broadly track compensation, which is why the effort is not evenly distributed. Fresher offers at large IT services usually sit around ₹3.2 LPA to ₹4.5 LPA for standard roles. Mid-tier and digital-track offers commonly land somewhere between ₹6 LPA and ₹14 LPA. Top product companies start around ₹20 LPA and go considerably higher once stock and joining bonus are counted. These bands shift every hiring season and vary by campus, so treat them as rough orientation rather than a promise.

What the large IT services tests actually ask

This is where the biggest mismatch happens. Students preparing for TCS NQT or the Infosys hiring process often spend their time on the wrong material entirely.

The coding section in these tests is usually one or two problems, in a plain browser editor, with a tight clock. What appears is fundamentals: string reversal, palindrome checks, vowel and character counting, prime numbers, factorials, Fibonacci, Armstrong and perfect numbers, GCD, array traversal for maximum, minimum and second largest, simple sorting, matrix printing, basic pattern printing, and small string manipulation. Sometimes there is a light word problem wrapped around arithmetic.

What decides the outcome here is not depth. It is three things. First, speed and accuracy on the aptitude and reasoning sections, which carry more weight than the coding section in most of these papers. Second, whether you can type out a working solution to a simple problem quickly, without a helpful IDE. Third, whether you handle input and output correctly, because a solution that is logically right but reads input wrongly scores zero.

If your realistic target list is dominated by these companies, the correct plan is quantitative aptitude, verbal ability and logical reasoning as your main effort, with fifty to eighty fundamental coding problems drilled until they are automatic. Working through company-specific patterns such as TCS interview questions and Infosys interview questions will tell you more about the real bar than any generic DSA sheet. A broader plan for the whole season is worth building alongside it, and campus placement preparation covers the parts of the process that sit outside coding.

Company tier to topic depth

This table is the short version of everything above. Find your realistic target column and prepare for that, not for the column you wish you were in.

Tier	Examples	Topics that actually appear	How deep to go	Rough fresher band
Large IT services	TCS, Infosys, Wipro, Cognizant, Capgemini, Accenture	Loops, conditionals, strings, 1D and 2D arrays, basic maths, simple sorting, pattern printing	Write it correctly in under fifteen minutes without an IDE. No advanced topics needed.	₹3.2 to ₹4.5 LPA
Digital and premium service tracks	TCS Digital, TCS Prime, Infosys Power Programmer, Wipro Turbo	Arrays, strings, hashing, two pointers, recursion, sorting, basic trees, occasional easy DP	Comfortable with easy and lower-medium problems. Explain time complexity clearly.	₹6 to ₹11 LPA
Mid-tier product and consulting	Zoho, Freshworks, Persistent, Publicis Sapient, funded startups	All of the above plus linked lists, stacks and queues, binary search on answer, trees, basic graph traversal	Solid on medium problems in familiar patterns. Clean code, edge cases handled.	₹7 to ₹14 LPA
Top product companies	Google, Amazon, Microsoft, Adobe, Atlassian, Flipkart, Swiggy, Razorpay	Everything, with real weight on graphs, dynamic programming, heaps, tries, intervals, and design of the approach itself	Medium fluently, hard sometimes. Must reason aloud through unseen problems.	₹20 LPA and above

Notice that three of the four rows do not require dynamic programming at all. That single fact changes how most students should spend their next two months.

The topic order that pays off earliest

Order matters more than volume, because the early topics appear in every tier and the late topics appear in one.

1. Arrays. Traversal, in-place modification, prefix sums, maximum and minimum, Kadane's, rotation, merging. Everything else sits on top of this.
2. Strings. Reversal, palindromes, anagrams, frequency counting, substring problems, basic parsing. Services tests live here.
3. Hashing. Maps and sets. This is the single highest-return topic in interviews because it converts a large number of quadratic solutions into linear ones.
4. Two pointers and sliding window. A small number of patterns that cover a surprisingly large share of medium problems.
5. Sorting and binary search. Know the standard library sort, know how to sort with a custom comparator, and know binary search on a sorted array and on an answer range.
6. Basic recursion. Factorials and Fibonacci first, then subsets, permutations and simple backtracking. Recursion is the gate to trees, graphs and DP, so build it properly.
7. Linked lists, stacks and queues. Pointer manipulation, reversal, cycle detection, next greater element, valid parentheses.
8. Trees. Traversals, height, diameter, binary search tree operations, lowest common ancestor.
9. Graphs. BFS, DFS, connected components, cycle detection, topological sort. Shortest paths if you are targeting tier three.
10. Dynamic programming. Last. Memoisation before tabulation, and the standard families: knapsack, subsequences, grids, partitions.

The first six items on that list will carry you through every tier one and most tier two screening rounds. Items seven and eight open up mid-tier interviews. Items nine and ten are for the top tier specifically.

Why chasing dynamic programming in month one is a common waste

Dynamic programming is the most discussed and least useful early topic for Indian placements, and the reason is structural.

DP is not really a topic. It is a way of thinking about recursion with overlapping subproblems. If your recursion is shaky, DP will feel like memorising unrelated tricks, because that is exactly what it becomes when you skip the foundation. Students who start DP in week two typically end up with a collection of solutions they can reproduce and cannot adapt. In an interview, a small twist on a memorised problem exposes this immediately.

There is also the pure arithmetic of return. DP appears in one of the four rows in the table above. Hashing appears in three. If you have eight weeks, spending week two on longest common subsequence instead of hash maps is a straightforwardly bad trade.

The exception is if you are aiming squarely at tier three and you have six months or more. Then DP belongs in your plan, after recursion is genuinely comfortable, and you should treat it as a long topic rather than a weekend.

How many problems is enough

The count is the wrong metric, and it is popular only because it is easy to measure. Two students can both have 300 solved problems on their profile, and one of them is ready while the other is not.

What separates them is pattern recognition. The useful question is not how many problems you have solved. It is: when you read a new problem, how quickly do you know which shape it is? Sorted array and a target sum means two pointers. Contiguous subarray under a constraint means sliding window. Counting or de-duplicating means a hash map. Shortest path in an unweighted graph means BFS. Choices with overlapping subproblems means DP. There are maybe twenty-five such patterns that cover the overwhelming majority of interview problems.

Rough working numbers, offered as orientation rather than a rule. For tier one screening, fifty to eighty fundamental problems, drilled to the point of boredom. For tier two, roughly 150 to 250 problems spread across the topic order above, weighted towards easy and medium. For tier three, 300 to 500 problems with real depth in graphs and DP, plus contest practice for the pressure.

The far better test than any number: pick a medium problem in a topic you have studied, from a source you have not seen. If you can identify the pattern within five minutes and write clean working code in thirty, you are ready in that topic. If you cannot, more problems in that topic will help. If you can, move on. This test is worth more than your solved count because it measures transfer, and transfer is the only thing the interview measures.

How to practise so it survives a timed test

Most practice fails to transfer because the conditions are wrong. Solving a problem with autocomplete on, no clock, and a tab of hints open builds a skill you cannot use on test day.

Write code without an IDE. Use a plain text editor or paper for at least some of your practice. Services tests and many online assessments give you a bare browser editor with no autocomplete and no red underlines. If you have never compiled code from memory, you will lose minutes to syntax you thought you knew.

Explain your approach out loud before writing. Say the approach, then the complexity, then start typing. This feels silly alone in a hostel room and it is the single highest-return habit for interviews, because interviews are scored on the explanation as much as on the code. If your first spoken sentence of an approach is coherent, the interviewer relaxes.

Redo problems you have already solved. Come back after two weeks and solve it again from scratch, without looking. This is uncomfortable because it exposes how much you were pattern-matching to your own past answer rather than understanding the method. That discomfort is the point.

Use a clock. Forty-five minutes for a medium problem, then stop and read the editorial. An unlimited attempt teaches you almost nothing about performing under a deadline.

Keep a mistakes list. One line per problem you got wrong, naming the pattern you missed, not the problem. After a month, that list shows you where your gaps actually are, and it is usually two or three recurring blind spots rather than a broad weakness.

C++, Java or Python for Indian placement tests

All three are accepted almost everywhere. The differences that matter are practical.

C++ is the default in competitive programming and has the most compact standard library for interview work. Sorting, maps, sets and vectors are short to write. It is fast enough that a slightly inefficient solution can still pass time limits, which is a genuine safety net in an online assessment.

Java is verbose but is the working language of most large Indian IT services and enterprise product teams. If your target is tier one or a service-based role, being fluent in Java has value past the test, and some company-specific rounds effectively assume it.

Python is fastest to write and hardest to get wrong syntactically, which makes it a good interview language. The trade-off is execution speed. On a tight online assessment with large inputs, a correct Python solution occasionally times out where the same logic in C++ passes. Know your recursion limit too.

The real advice is simpler than the comparison. Pick one, and pick it early. Then do not switch in your final month. Switching late means relearning standard library syntax, input parsing habits and debugging instincts at exactly the moment you need those to be automatic. A student who is genuinely fluent in Java will outperform the same student two weeks into C++ every single time. Language choice is worth days of your attention, not weeks.

The part students skip entirely

Clearing the coding round does not get you an offer. It gets you a conversation. This is the most consistently ignored fact in placement preparation, and it explains a lot of otherwise confusing rejections.

Once you are in the interview room, the coding question is often only part of what is being assessed. Interviewers are also working out whether you actually built the projects on your CV, whether you can explain a technical decision you made and why, whether you can be understood in a meeting, and whether you will be a reasonable person to sit next to for two years.

Two failures are extremely common at this stage. The first is a candidate with strong DSA and a project they cannot describe. Asked why they chose a particular database or how authentication works in their own application, they go quiet. This reads as a copied project, fairly or not. The second is a candidate who can code well and cannot narrate. They solve the problem in silence, hand over a correct answer, and leave the interviewer with nothing to write on the feedback form.

So budget your preparation accordingly. If DSA is taking all your time and your CV still lists two tutorial projects you cannot defend, you have mis-allocated. Be able to talk for three minutes about each project: what problem it solves, what you chose, what broke, what you would do differently. Get the document itself in order too, since a strong software engineer resume format is what gets you into the room in the first place, and rehearse the opening question properly, because tell me about yourself sets the tone for everything that follows.

A realistic plan by time remaining

Four weeks left. Do not start anything new. Arrays, strings, hashing and basic recursion only, plus heavy aptitude practice if services companies are on your list. Drill the fundamental problem list until it is muscle memory. Fix your CV. Prepare your project answers.

Three months left. Work through the topic order to trees. Aim for roughly 150 to 200 problems with genuine understanding. Add mock interviews from week six, with a friend, out loud. Skip DP unless tier three is realistic for you.

Six months or more. The full order, DP and graphs included, with contest practice for time pressure. This is also the window in which building one substantial project is worth more to you than another hundred easy problems.

If campus placements are limited at your college, plan for applying directly as well, and off-campus drive hiring runs on a different calendar with different expectations.

The most common preparation mistake in Indian placements is not laziness. It is a strong student preparing seriously for a tier they were never going to be interviewed by, while the tier that was actually hiring them tested something simpler and they ran out of time to practise it.

Decide your realistic target list first. Prepare for that bar. Then spend the time you save on your projects and on being able to explain them, because that is where the offer is decided.