Two students with the same DSA knowledge can walk out of the same coding test with very different results. The difference is rarely more knowledge. It is strategy under a timer: which problem to open first, when to stop debugging, and how to bank partial marks instead of chasing one hard problem to zero.
This is a strategy guide, not a topics list. It assumes you have done the practice and covers how to actually spend the ninety or so minutes of a coding round so your real ability turns into a real score. Confirm the exact number of problems, time limit, and scoring rules for your specific test on the company's official notification, since those vary by drive.
Read the constraints before you read the problem twice
The single most useful habit is reading the constraints first. The input size tells you what complexity the setter expects, before you have written anything.
n up to about 10 to the 5, or 10 to the 6: an O(n) or O(n log n) solution is expected. A nested loop will time out.
n up to a few thousand: O(n squared) is usually fine.
n up to about 20: an exponential or backtracking solution is likely intended.
This reading saves you from writing a correct-but-too-slow solution that passes the samples and fails on the hidden large cases. If the constraint rules out your first idea, find a better approach before you code, not after the time-limit-exceeded verdict.
Dry-run on paper before you type
It is tempting to start coding the moment an idea appears. Resist it for two minutes. Take the sample input, or a tiny case you invent, and trace your approach by hand. If it produces the right answer on paper, code it. If it does not, you just saved yourself twenty minutes of debugging a wrong idea.
This is the highest-return two minutes in the whole test. Most failed submissions are not typos; they are a flawed approach that felt right until the hidden cases exposed it.
Handle the edge cases the setter is hiding
Sample cases are gentle. Hidden cases are where marks are won and lost. Before you submit, run your solution through the usual traps in your head:
Empty input, or a single element.
The largest allowed input (does it overflow, does it time out).
Duplicates, negatives, and zero.
Values at the exact boundary of the constraints.
Integer overflow is the classic silent failure. If the problem multiplies or sums large values, use a 64-bit type. A solution that is correct in logic and wrong on overflow scores the same as no solution at all.
Budget your time across the whole round
Treat the timer as a resource to allocate, not a countdown to ignore. A workable model for a ninety-minute, three-problem round:
First five minutes: triage. Read all problems and rank them easiest to hardest by your own judgement. Do not solve in the given order; solve in your order.
Bank the easy one first. Take the problem you are most sure of and finish it completely. A solved easy problem is worth more than a half-solved hard one.
Middle block: the medium problem. Give it a firm time box, say thirty minutes. If you are stuck at the box, move on and come back.
Last stretch: partial scores. On the hardest problem, write the brute-force solution even if it will not pass every case. Many tests award marks per passing test case, so a slow solution that clears the small cases still scores.
The discipline that matters most is the time box. Sinking forty minutes into one stubborn problem, and leaving an easy one untouched, is how strong candidates score below weaker ones.
Play the partial-score game honestly
If the test scores per test case, a brute-force solution is not a failure, it is a deposit. Write the simple O(n squared) version, submit it for the marks it earns on the small cases, and only then try to optimise. Getting sixty percent of three problems usually beats getting one hundred percent of one.
Be honest with yourself about when to stop optimising, too. Once a solution passes and you have banked the marks, moving to the next problem is almost always worth more than squeezing a faster solution out of one you have already scored.
Choose a language you are fluent in, not the fastest one
Use the language you write most fluently under pressure, usually C++, Java or Python. The marginal speed of C++ rarely matters at placement-test constraints, and it never compensates for fumbling syntax you half-remember. Know your language's basics cold: how to read input fast, the standard collections (maps, sets, lists), and how to sort with a custom comparator. Those are the operations every problem needs, and hunting for the syntax mid-test burns the minutes you budgeted for thinking.
Prepare so the strategy has something to stand on
Strategy multiplies preparation; it does not replace it. Two or three problems a day in the weeks before your drive, deliberately across different patterns rather than your comfort zone, is what makes the in-test triage fast. If you are building that base, our Coding for Placements course covers C, C++, Java and Python with practice problems, and our DSA using Java course is built for the coding rounds and technical interviews at product-based companies.
Knowing which pattern a problem fits is what makes the constraint-reading and triage above fast, so pair this strategy with pattern practice. Our DSA interview questions for placements guide covers the recurring patterns each of these tests draws on, and the full placement preparation category lists our company-wise coverage.
The short version
Read the constraints first, dry-run before you type, solve in your own order, time-box every problem, and bank partial marks instead of chasing a perfect score. None of this is more knowledge. It is spending the knowledge you already have well, and it is the difference between walking out frustrated and walking out with an offer.
