What DSA rounds actually test

Most IT hiring processes for freshers include some form of coding assessment. It might be an online test with two or three problems, a live coding interview, or a mix of aptitude and programming. The exact format varies by company and even by year, so always check the official careers page or the test instructions you receive.

What stays fairly consistent is the skill being tested. Interviewers want to see that you can read a problem, choose a sensible approach, write working code, and explain its time and space complexity. They care less about whether you have memorised a rare algorithm and more about whether you can think clearly under mild pressure.

Mass recruiters often test basic programming and logic, while product companies tend to go deeper into DSA. If you are aiming at service companies, read our guide on TCS NQT and mass recruiter online tests as well, because aptitude matters there too.

  • Arrays, strings and hashing appear almost everywhere.
  • Two pointers, sliding window and binary search are common in online tests.
  • Trees, graphs and recursion show up more in product company interviews.
  • Dynamic programming is tested at many product companies, but the depth varies.

Before week 1: set yourself up

Spend a day or two on setup before you start the plan. A little clarity now saves weeks of wandering later.

Pick one language and stick with it. C++, Java and Python are all widely accepted in coding rounds. Choose the one you are most comfortable with, not the one a friend says is "best". Switching languages mid-way is one of the most common reasons freshers lose momentum.

Decide how much time you can honestly give. Around one and a half to two hours on weekdays and a bit more at weekends is a sustainable pace for most students. If you can only manage less, stretch the plan to 16 weeks rather than burning out.

  • Choose one practice platform and one reference (a good book or structured course) — do not collect ten.
  • Keep a simple notebook or doc: problem name, pattern used, mistake made, one-line insight.
  • Learn your language's standard library: dynamic arrays, hash maps, sets, stacks, queues, priority queues and sorting.
  • Avoid paid "placement guarantee" schemes. Genuine employers never charge a fee to apply, test or interview you.

Weeks 1–4: foundations

The first month is about building confidence and speed with the basics. Do not rush this. Most medium-level problems are simply easy patterns combined, so weak foundations show up later.

Aim for around three to five problems a day, mostly easy with a few medium ones by week 4. Quality matters more than count: if you solve something, make sure you could explain it to a classmate.

  1. Week 1 – Complexity and arrays: Big-O notation, time vs space trade-offs, traversals, prefix sums, basic sorting and searching. Write a few problems in two ways (brute force, then improved) and compare complexities.
  2. Week 2 – Strings and hashing: frequency counting, anagrams, palindromes, substring checks, using hash maps and sets to drop nested loops.
  3. Week 3 – Two pointers and sliding window: pair sums on sorted arrays, removing duplicates, longest substring problems, fixed and variable-size windows.
  4. Week 4 – Binary search and recursion basics: classic binary search, searching on the answer, first/last occurrence, then simple recursion such as factorial, power and generating subsets. End the week with a timed set of four mixed problems in 90 minutes.

Weeks 5–8: core data structures

Month two covers the structures that appear in most interview rounds. By now you should move to mostly medium problems, with easy ones only to warm up a new topic.

This is also when you should start timing yourself. Give each medium problem about 30–40 minutes. If you are stuck after that, read a hint or the approach, then close it and write the solution yourself. Revisit the same problem three or four days later.

  1. Week 5 – Linked lists, stacks and queues: reversal, cycle detection, merging lists, fast and slow pointers, valid brackets, next greater element, monotonic stacks.
  2. Week 6 – Recursion and backtracking: permutations, combinations, subsets, N-Queens style problems. Focus on drawing the recursion tree before coding.
  3. Week 7 – Trees and binary search trees: traversals (recursive and iterative), height, diameter, lowest common ancestor, level order using a queue, BST insert/search/validate.
  4. Week 8 – Heaps and greedy: top-k elements, merging sorted lists, scheduling and interval problems. Finish with a full mock: two problems in 60 minutes, then review every mistake in your notebook.

Weeks 9–12: advanced topics and mock tests

The final month brings in the harder topics and shifts your focus from learning to performing under exam conditions. If the advanced topics feel heavy, prioritise depth on graphs and basic dynamic programming over rare algorithms.

From week 10 onwards, do at least two timed mocks a week. Simulate the real thing: no notes, a fixed time, and a proper review afterwards. Online tests are often proctored, so practise with your camera on and in a quiet space.

  1. Week 9 – Graphs: representation, BFS, DFS, connected components, cycle detection, topological sort, shortest path in unweighted graphs, then Dijkstra's algorithm.
  2. Week 10 – Dynamic programming, part 1: start from recursion, add memoisation, then convert to tabulation. Cover 1D problems such as climbing stairs, house robber and coin change.
  3. Week 11 – Dynamic programming, part 2, plus tries: 2D problems such as grid paths, longest common subsequence and knapsack variants. Add tries for prefix and word problems if time allows.
  4. Week 12 – Revision and mocks: no new topics. Re-solve the problems you marked as hard in your notebook, do three or four timed mocks, and practise explaining your approach out loud as if to an interviewer.

How to practise so it actually sticks

Solving hundreds of problems you quickly forget is not preparation. What helps is learning patterns. When you finish a problem, ask: what was the key idea, and where else would it work?

Use a consistent method for every problem. It feels slow at first, but it is exactly what interviewers want to see, and it stops you jumping into code too early.

Talk while you solve, even when alone. In live interviews, communication often matters as much as the final code. A clear brute-force answer with a sensible plan to optimise is usually better than silence followed by a half-finished clever solution.

  • Spaced revision: revisit solved problems after three days, a week and a month.
  • Track patterns, not counts: "I can spot a sliding window problem" beats "I have solved 400 problems".
  • Read good solutions after solving, to learn cleaner code and alternative approaches.
  • Rest one day a week. Consistency over 12 weeks matters more than heroic weekends.
  1. Read the problem twice and restate it in your own words.
  2. Work through two or three small examples by hand, including edge cases (empty input, one element, duplicates, negative numbers).
  3. Describe a brute-force approach and its complexity.
  4. Look for a better pattern: hashing, two pointers, sorting, binary search, a stack, BFS/DFS or DP.
  5. Write clean code with meaningful variable names.
  6. Dry-run your code on an example and on an edge case before submitting.

Pair DSA with real applications

A common mistake is waiting until you "finish DSA" before applying. Hiring windows do not wait, and real tests are the best practice you will get. Start applying from around week 6, once your core topics are in place, and treat early rejections as feedback.

Your resume needs to get you to the test in the first place. Keep it to one page, list your projects with clear outcomes, and mention your languages and core CS subjects. You can run it through the free ATS resume checker to catch formatting and keyword gaps before you apply.

For targeted preparation, look up the companies you are applying to. Hirastra's company pages collect role and process information so you can focus your final weeks on what each employer tends to test. Remember that formats change, so confirm details on the official careers page.

On pay, Hirastra's estimates from 355 recent fresher listings put the full-time median at about ₹12 LPA, with a very wide range of roughly ₹2–38 LPA. These are estimates, not official figures, and offers vary a lot by company, role and city. Check salaries and our guide on CTC vs in-hand salary before comparing offers.

Frequently asked questions

Is 12 weeks really enough to prepare DSA for placements?

For most freshers with basic programming knowledge, 12 focused weeks is enough to become comfortable with the patterns commonly tested in coding rounds. It will not make you an expert in every topic, and that is fine. If you are starting from scratch with programming, add three or four weeks at the beginning to learn your chosen language properly.

How many problems should I solve in total?

There is no magic number. Many students solve a few hundred problems over this plan, but what matters is how well you understand the patterns. If you can recognise the approach for a new medium problem within a few minutes and explain your reasoning, you are in good shape regardless of your count.

Which language is best for DSA in placements?

C++, Java and Python are all widely accepted. Choose the one you know best and learn its standard library well. Some online tests restrict languages, so check the instructions for each company's test on its official page or in the invitation email.

Should I prepare aptitude alongside DSA?

Yes, if you are applying to service companies or mass recruiters, since their online tests often include aptitude, logical reasoning and verbal sections. Add 20–30 minutes of aptitude practice a few days a week from around week 5. Product companies usually focus more on coding, but formats vary, so check each process.

Join on WhatsApp