What the problems look like
A typical new-graduate coding round draws from a small, stable core. Arrays and strings with a hash map or two pointers. Sorting followed by a scan. A stack or queue problem. Recursion and simple backtracking. Binary trees traversed recursively, and grids or graphs walked with BFS or DFS. Dynamic programming shows up at some companies, usually at the one-dimensional end (climbing stairs, coin change) rather than the exotic end.
The format varies by region and employer, so check the invitation rather than assuming. In the US, new-grad hiring commonly starts with an online assessment and then one or more live interviews. Indian product companies hiring on campus often run an online test first and then several technical rounds on the day or soon after. UK and European graduate software roles may combine an online test with a technical interview or an assessment centre. The difficulty band is similar across all of these. The number of rounds is what changes.
Some panels, particularly in campus hiring, also ask fundamentals between problems: the cost of a hash map lookup and when it degrades, the difference between a process and a thread, what an index does. These are short, but a memorised one-liner with no reasoning behind it is noticed.
What the coding round scores beyond the answer
The interviewer is grading a process, not only an output. A student who says "the obvious approach is to compare every pair, which is O(n squared); a hash map of seen values gets it to O(n)" has already shown more than one who types the optimal solution in silence. Stating the brute force first proves you understood the problem. Stating its cost proves you know why you are improving it.
Clean code counts more than students expect. Meaningful variable names, a helper function where the logic repeats, and no dead code make your solution easy to check. An interviewer who cannot read your code cannot give you credit for it.
Testing is the other signal. Before you say "done", walk a three-element input through the loop and try one edge case: an empty array, a single element, all duplicates. Finding your own off-by-one error is scored well. Having the interviewer find it is scored less well.
Calibrating your DSA practice
The number of problems you have solved is a weak measure of readiness. A student with three hundred solved problems who looked up half the solutions is less ready than one with a hundred and twenty solved cleanly and revisited. Calibrate against the conditions of the coding round instead.
A useful self-test is to pick an unseen medium problem on a core topic, set a timer for about thirty-five minutes, and solve it out loud as if someone were listening. If you can reach working, tested code in that window on most attempts, your DSA practice is at the right level. If you cannot, more hard problems will not fix it; more mediums on your weakest topic will.
| Stage of DSA practice | What to do | Ready when |
|---|
| Topic by topic | Five to ten problems per core topic, easy then medium | You recognise the pattern without looking at the topic tag |
| Mixed sets | Random mediums from all core topics | You choose the right structure on most problems in a few minutes |
| Timed and spoken | Thirty-five-minute timer, narrate as you go | Working, tested code inside the window most of the time |
| Revisit | Re-solve problems you failed a week later | You can reproduce the idea, not the memorised code |
The difficulty labels on practice sites are one site's judgement and they do not map neatly onto any company's interview. Treat "medium" as a rough band, not a target.
Peer mock interviews are the cheapest way to practise the spoken part. One student interviews, one solves, and both switch. You learn quickly how hard it is to follow someone who codes in silence.
Preparing for hard problems you cannot win
The tempting mistake is to spend the last month on advanced dynamic programming, segment trees and graph algorithms because they feel like what separates strong candidates. For most new-grad coding rounds, they do not. Students are more often rejected for a buggy or unexplained solution to a medium problem than for failing a hard one.
That reverses the usual instinct. Your marginal hour is worth more spent making medium problems reliable than making hard problems possible. If a hard problem does come up, the same habits still earn credit: a correct brute force, a clear statement of its cost, and a sensible attempt at improving it, with the interviewer's hints taken and used.
The core topics and their usual traps are covered problem by problem elsewhere in the bank, for example the maximum contiguous subarray, grouping anagrams by a hash key and spotting when a problem is a graph.
When hard problems do matter
A minority of employers, and some roles within large ones, set harder problems for new graduates. If several seniors from your course report the same company asking difficult dynamic programming or graph problems, take that seriously for that company. Ask people who interviewed in the last season rather than relying on forum posts from years ago, and remember that one person's round is one sample.
A medium problem solved cleanly, tested and explained beats a hard problem half-solved in silence. Practise until the medium is boring.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).