DSA · Placement strategy

Three tracks, three different papers

A service-company test and a top product interview are not the same exam, and preparing “for placements” prepares you for neither. You will map the three formats side by side, turn ten weeks into a 150-hour calendar, and set up the revision loop that keeps a solved problem solved.

Service track2–3 h online test · aptitude first · breadth wins

→

Mass-hire product2 mediums in 60–75 min · speed wins

→

Top product1 medium + 1 hard + LLD · depth wins

01 The idea

One word, three different papers

Placement season is not one exam. A student who prepares only arrays and trees walks into a service-company test and loses on percentages and reading comprehension. A student who grinds aptitude for three months walks into a product-company round with two medium problems in seventy-five minutes and runs out of time on the first one. Both prepared hard. Both prepared for the wrong paper.

The format is set by hiring volume, not by how good the company is. A company taking thirty thousand freshers cannot put an engineer in front of every applicant, so it filters with a cheap test that auto-grades: aptitude, verbal, one or two small coding questions, sometimes SQL. A company taking two hundred can afford ninety minutes with an engineer, so it tests the expensive thing — whether you pick a workable approach under a clock and can defend it out loud. Same industry, same year, completely different paper.

Find out which of the three tracks your target company runs, then prepare for that paper. Breadth wins the service track, speed wins the mass-hire product track, depth wins the top product track.

TrackThe interview format a company runs, decided mostly by how many freshers it hires. Three of them cover almost every campus offer in India: service, mass-hire product, top product.

Cold re-solveSolving a problem again from a blank editor — no notes, no re-reading the old solution — at least two weeks after the first attempt. It is the only honest test of whether you learned the pattern.

Problem logA running record of every problem you solve: the problem, the pattern it used, the mistake you made, and the minutes it took. It is the input to your revision, not a diary.

02 Worked example

Ten weeks, 150 hours, one calendar

Priya has 10 weeks until her first campus drive. She can give two hours on each weekday and five hours across the weekend, and she does not yet know which companies will visit. Here is her plan, built from the hours she actually has rather than from a topic list. Every line below adds up; check them as you read.

Count the hours, not the weeksTen weeks sounds like a lot until you price it. Hours are what you spend; weeks are what you lose. Convert first, because every later decision is a subtraction from this one number.5 weekdays × 2 h + weekend 5 h = 15 h / week · 15 × 10 = 150 hours

Split the 150 across the four papersDSA is the only block that pays on all three tracks, so it takes the largest share. Aptitude pays mainly on the service track, but it is the one paper with a hard cut-off you cannot argue with, so it gets a real block instead of leftovers.DSA 90 h · aptitude 24 h · core CS + SQL 21 h · mocks 15 h = 150 h

Weeks 1–4 · build the baseArrays, strings, hashing, two pointers, sliding window — the patterns every track tests. Aptitude runs alongside from week one: percentages, ratios, time and work, permutations. Core CS is SQL only at this stage, because SQL is what the earliest tests ask for.DSA 40 h + aptitude 12 h + SQL 8 h = 60 h (15 × 4 weeks)

Weeks 5–8 · patterns and core CSRecursion, trees, BST, heaps, BFS and DFS, and the standard set of DP problems. Core CS widens to OS scheduling and deadlock, DBMS normalisation, and TCP/IP basics. Mocks start here, not in the last fortnight — one timed two-problem round a week.DSA 38 h + aptitude 8 h + core CS 9 h + mocks 5 h = 60 h

Weeks 9–10 · nothing newNo new topic enters after week 8. All the DSA hours are cold re-solves pulled from the log, and the mock hours double: two full timed rounds and two spoken 45-minute interviews with a friend who is allowed to interrupt.DSA 12 h (re-solves only) + aptitude 4 h + core CS 4 h + mocks 10 h = 30 h

The loop that runs through all ten weeksEvery problem is logged the moment it is solved, and every problem you needed help on gets a return date. One you solved cleanly on your own does not come back, however long it took. One you needed a hint or the editorial for comes back on day 14, from a blank editor. This is spaced repetition: the gaps grow, and the recall happens just as the memory starts to fade.day 0 solve · day 3 recall the approach (2 min) · day 14 cold re-solve · day 35 only if day 14 failed

✓

What the calendar producesPrice the DSA block in problems before you trust it. The 78 DSA hours in weeks 1–8 do not all buy new problems: about 70 do, at roughly two an hour including reading and logging, and the other 8 pay for the day-14 returns, which start landing in week 3 and cannot wait for week 9. If three in ten need a hint or the editorial — which is normal — about 42 problems get flagged. Weeks 9 and 10 hold 48 re-solve slots: the ten returns still due from weeks 7 and 8, and 38 spare for anything that failed on day 14 or that you still do not trust.70 h × 2 = 140 new problems · 140 × 0.3 ≈ 42 flagged · 8 h × 4 = 32 returns in weeks 3–8 · 12 h × 4 = 48 slots in weeks 9–10

A problem you finished by reading the editorial is not a solved problem. It goes into the log with the mistake written in your own words, and it comes back on day 14 from a blank editor. If you cannot reproduce it then, the pattern was never learned — you watched someone else use it.

The log is four columns wide and takes forty seconds to fill. Here are three real rows from Priya’s week 3:

Problem	Pattern	What went wrong	Minutes
Two Sum	Hash map, one pass	Nothing. Solved it cold.	`9`
Longest substring without repeating characters	Sliding window + last-seen map	Moved the left edge one step at a time instead of jumping it past the duplicate.	`38 · hinted`
Trapping rain water	Two pointers from both ends	Only found the prefix-max version. Never saw why two pointers is correct.	`52 · editorial`

Row one is finished and never returns. Rows two and three go on the day-14 list before the editor closes. The what went wrong column is the one people skip and the one that does the work: “sliding window” tells you nothing two weeks later, but “I moved the left edge one step at a time” drops you straight back inside the mistake.

Thirty minutes a problem is an average, not a target — an easy array problem takes ten and your first graph problem takes ninety. Three things in this plan are worth copying whatever your number of weeks is. It is built from hours, so it cannot silently overrun. It front-loads aptitude, because service drives usually land first on campus and a missed cut-off cannot be appealed. And it stops adding new topics two weeks out. The next section is what decides which of those hours matters for which paper.

03 The three formats

What each track actually tests

Read the last column first. What gets you rejected differs more between these three tracks than what gets tested, and it is the column students never look at. Not one of the three rejection reasons below is a plain “you did not know the algorithm”.

These are the patterns each track usually runs, not a promise about any one company in any one year. Formats change between years, and the same company can run a shorter test at one college and a full product-style round at another. Treat the table as the shape to expect, then confirm it against last year’s drive on your own campus.

Track	Format and duration	What is tested	What gets you rejected
Service typically TCS, Infosys, Wipro, Cognizant, Accenture	Usually one online test of 2–3 hours: aptitude, verbal, logical reasoning, one or two small coding questions, often SQL. Then a 20–30 minute technical round and an HR round.	Breadth and speed. Percentages, ratios, time and work, data interpretation, reading comprehension. Loops, strings and a formula in one language. SQL joins and GROUP BY. The OOP pillars, and whatever core CS you claimed on your resume.	Missing the aptitude cut-off, or being unable to explain a line of your own project. Almost never for not knowing graphs.
Mass-hire product 50–300 freshers a year	An online round of roughly two medium problems in 60–75 minutes, then one or two 45-minute interviews in a shared editor.	Pattern recognition against a clock. Arrays, strings, hashing, two pointers, sliding window, stacks, binary search, sorting, basic trees and graphs. You are expected to reach a working solution and state its complexity without being asked.	Finishing one problem out of two, or finishing both after the timer. Submitting a brute force without ever naming the better approach ends it just as fast.
Top product 5–20 hires per team	Usually one medium and one hard in a 90-minute online round, then three or four interviews: two DSA, one low-level design, one behavioural with the hiring manager.	Depth and communication. Graphs, dynamic programming, heaps, tries, and an LLD discussion — a parking lot, a rate limiter, a bill splitter — where classes, interfaces and edge cases matter more than syntax.	Silence. Reaching the right answer without narrating the reasoning, or writing code before the approach was agreed. Also: no test cases, and no answer to “what breaks at scale”.

Why the service track leads with aptitude. Fifty thousand applications, a few thousand seats, and a hiring team that cannot read them. An aptitude section is the cheapest filter that scales: it grades itself in seconds, it cannot be defeated by memorising a repository of solutions, and it correlates well enough with finishing work on time. The coding question is deliberately small because the company plans to train you on its own stack anyway.

Why the mass-hire round is two mediums and a clock. The company already believes you can code — your degree and your test score said so. What it cannot afford to discover in month three is that you freeze. Two problems in seventy minutes forces you to recognise the pattern in the first three minutes, because there is no time left to discover it by writing. That is why the practice reps that matter are timed ones, from week 3.

Why the top track adds design and a behavioural round. At five to twenty hires, one bad hire is a measurable cost, so they test the things that actually break teams: unclear thinking, code nobody else can extend, and an unwillingness to say “I do not know”. The DSA rounds are the entry ticket, not the decision. The decision is usually made in the design round and the manager round.

04 Cheat sheet

The clocks you are actually racing

Every one of these is a per-item budget, not a total. Rose marks the one with a cut-off you cannot argue with; amber marks the two rounds students most often run out of time in.

Round	Budget per item	How to spend it
Service · aptitude section	`60–90 s / question`	Sweep once and take everything you can finish inside a minute, then come back. One long question can cost you four easy ones.
Service · coding question	`~15 min / problem`	One or two easy problems: loops, strings, a formula. Full marks are the expectation here, not a bonus.
Mass-hire product · online round	`~35 min / problem`	Two mediums in 60–75 minutes. Aim for the pattern named in 5, code done by 20, tests run by 30.
Top product · online round	`~45 min / problem`	One medium and one hard in 90 minutes. Bank the medium in 25 and give the rest to the hard one.
Any live interview round	`~45 min`	5 minutes clarifying, 10 agreeing the approach out loud, 20 coding, 10 dry-running and stating complexity.
Cold re-solve	`~15 min`	A problem you already solved once, from a blank editor. It should take a fraction of the original attempt; if it takes as long again, the pattern was never learned.

Breadth or depth, not both at onceThe service track rewards touching twelve topics shallowly; the top product track punishes exactly that. You cannot peak for both in the same fortnight, so sequence them instead of blending them.

The clock is the real filterOn both product tracks the problems are rarely harder than the ones you practise. The timer is what is different. Put a visible countdown on single problems from week 3, well before the full mock rounds start in week 5.

Talking is a separate skillService HR rounds and top-product interviews both reject silent candidates. Narrating your reasoning has its own practice reps — say it out loud while you solve, alone, until it stops feeling strange.

05 Where & why

Which track to aim at first

You cannot peak for all three tracks in the same week, and you do not have to. On most campuses the service drives land first and the product drives follow, so the order is half-decided for you. The real question is how many of your own hours you let the earliest drives take — and the honest answer depends on how much base you already have, not on which company you would prefer.

Aim at the product tracks first when…

You already clear aptitude mocksYou score above 75% on a full-length service-company mock without preparing for it. Aptitude then needs maintenance, four hours a month, and DSA takes everything else.

Your campus calendar puts product drives earlySome colleges run product companies in the first slot. Check the previous year with your placement cell before you plan a single week; the order changes everything downstream.

You have twelve weeks or moreTwelve weeks is enough to build a real DSA base and still fit aptitude around it. Under eight it will not be there, and a half-built base fails the 70-minute round anyway. Between eight and twelve, aim at one product track only and drop the other.

You are applying to a team, not a headcountReferrals and off-campus applications to small teams almost always run the top-product format. There is no aptitude section to fall back on if the DSA round goes badly.

Rebalance toward the service track when…

Situation	Better choice	Why
Six weeks left and no DSA base at all	Service track, fully	Six weeks buys aptitude fluency and one solid language, which is what a service test asks for. It does not buy graphs and DP, and a half-learned graph is worth nothing in a 70-minute round.
Your test scores are the thing holding you back, not your code	Aptitude and core CS	Both are finite and score-based. Twenty-four hours of percentages and joins moves a test score further than twenty-four hours of new DSA topics at that stage.
You solve fine alone but freeze in interviews	Mock interviews, not more problems	The gap is verbalising, not knowing. Ten recorded 45-minute mocks fix more than a hundred additional solved problems.
Every company visiting your campus is a service company	Service track now, product track after	Optimise for the offers that actually exist. Keep DSA ticking at two problems a day so an off-campus product application stays open next year.

All three tracks ask the same question in a different accent: can you take a problem you have not seen, choose an approach, and defend it. Aptitude asks it under a stopwatch, the mass-hire round asks it in code, the top-product round asks it out loud. That is why the revision loop matters more than the topic list — a pattern you cannot reproduce cold after two weeks was never learned, only watched.

06 Interview questions

What interviewers actually ask

Eleven questions in the order things escalate: what the tracks are, how you prepared, how you spend the clock, and then the ones that decide whether the interviewer believes you.

What is the actual difference between a service-company interview and a product-company interview?

Hiring volume, and everything else follows from it. A company taking thirty thousand freshers filters with a cheap auto-graded test — aptitude, verbal, one or two small coding questions, sometimes SQL — because it cannot put an engineer in front of every applicant. A company taking two hundred can afford ninety minutes with an engineer, so it tests the expensive thing: whether you pick a workable approach under a clock and defend it. The format is set by headcount, not by how good the company is.

Walk me through how you prepared.

"Fifteen hours a week for ten weeks — 90 on DSA, 24 on aptitude, 21 on DBMS, OS and SQL, 15 on timed mocks. About 140 problems, each logged with its pattern and my mistake, and the 42 that needed a hint or the editorial re-solved cold two weeks later." Answer in numbers, not adjectives: numbers are checkable, and they answer what the question is really probing, which is whether you can plan work and stick to it.

Seventy minutes, two medium problems. What do you do in the first five?

Read both problems before writing anything, then start with the one whose pattern you can name. Naming it means saying "sliding window" or "binary search on the answer" out loud, not feeling that the problem looks familiar. If neither is nameable after five minutes, take the one with the smaller constraints and write the brute force, because a working brute force scores partial marks and a blank editor scores nothing.

If the job is coding, why is there an aptitude section at all?

Because it is the cheapest filter that survives fifty thousand applications. It grades itself in seconds, it cannot be defeated by memorising a repository of solutions, and it correlates well enough with finishing work on time. It is not a claim that percentages matter on the job. It is a claim that a candidate who cannot do thirty timed questions in thirty minutes is a worse bet than one who can.

What actually gets asked in a service-company technical round?

Your own resume first, then the basics of one language you claimed. Expect the four OOP pillars with an example each, a SQL join written on paper, one or two compare-and-contrast questions such as array versus linked list or GROUP BY versus WHERE, and one project explained end to end including what you personally wrote. The round runs twenty to thirty minutes. It is checking that you are not bluffing, not that you know graphs.

How many problems should I solve?

The count is the wrong target, but you will be asked, so carry a real number: roughly 150 logged and re-solvable problems is enough for the mass-hire product track, and around 300 including graphs and dynamic programming for the top product track. The load-bearing word is re-solvable. A hundred and fifty you can reproduce cold beats five hundred you watched someone else solve, and the log is the only thing that tells you which number you actually have.

What is spaced repetition, and how does it apply to DSA?

It means revisiting something at growing gaps rather than all at once, so the recall happens just as the memory begins to fade. For problems that is four touches: solve on day 0, spend two minutes on day 3 recalling only the approach from your log, re-solve cold from a blank editor on day 14, and repeat on day 35 only if day 14 failed. Re-reading your old solution counts as none of those — it feels like revision and produces recognition instead of recall.

You solved this exact problem three weeks ago and cannot do it now. What went wrong?

Recognition was mistaken for recall. Reading a solution until it makes sense builds the ability to follow the idea, not the ability to produce it, and while you are reading the two feel identical. The fix is mechanical rather than motivational: every problem gets a return date, and the return is a blank editor with a timer running, not a re-read of your old code.

What is a low-level design round, and how is it different from a DSA round?

You are handed a small system — a parking lot, a rate limiter, a bill-splitting app — and asked to design the classes, interfaces and interactions, usually in forty-five minutes. Unlike a DSA round there is no single correct answer, so the marks come from how you handle ambiguity: asking what is in scope, naming the entities, deciding where behaviour lives, and saying what you would change when a new requirement arrives. It appears on the top product track and almost never on the other two.

What gets candidates rejected, on your track?

Hard

Write your own week-by-week plan to your first drive, then stress it three ways — four days lost to illness, one week lost to a mid-semester exam, and the drive moved two weeks earlier — and return the revised plan that still produces an employable candidate under all three.

Follow-up

A plan that only works when nothing goes wrong is a wish. The real output is not the calendar but the ordering: what you learn first, so that whatever gets cut is cut from the end and never from the middle.

Show the hint

The “what is tested” column of the three-formats table names the topics track by track. Count how many of the three tracks each of your topics appears in before you decide what goes first.