How to Actually Prepare for the Coding Round in Campus Placements (Not Just 'Do LeetCode')

Most campus candidates grind LeetCode for three months, solve 300-plus problems, and still blank on the actual online assessment. Then they conclude they're bad at DSA, apply to easier companies, and don't understand what went wrong.

The issue is not volume. A student who has worked through 50 problems with deliberate technique will consistently outperform one who has churned through 400 without it. This post is about the technique — how to read a problem, identify what kind of problem it is, and choose an approach before you write a line of code.

What the coding round is actually measuring

Most candidates treat the coding round as a memory test: have I seen this problem before? If yes, code it. If no, panic. What the OA is actually evaluating:

Pattern recognition. Can you read a new problem and identify which class of solution it belongs to — greedy, dynamic programming, BFS, sliding window — within three to five minutes? This is a trainable skill. Candidates who have practised categorising problems before coding develop this reflex. Candidates who jump straight to implementation don't.

Constraint reading. Problem constraints tell you the expected time complexity before you write a single line. An array of size up to 10^5 with a one-second limit almost always requires O(n log n) or better. An input with n ≤ 20 opens the door to exponential solutions. Candidates who skip constraints waste time implementing solutions they should have known would time out.

Composure under partial failure. In a timed OA you will not solve every problem fully. What separates a 70th-percentile result from a 90th is whether you bank partial marks with a brute-force submission while working on the optimised version, or spiral and submit nothing.

None of these come from random problem grinding. They come from deliberate, pattern-oriented practice.

Why random grinding doesn't work

It doesn't build pattern recognition. When you solve a linked-list problem on Monday, a tree problem on Tuesday, and a string problem on Wednesday, you are not building pattern recognition — you are building a loose collection of one-off solutions. Pattern recognition comes from solving eight to ten problems in the same category back to back, until you can identify the pattern in the problem statement before you read past the second line.

It prioritises completion over understanding. Looking at a solution after twenty minutes and moving on creates an illusion of progress. The real test: can you re-implement it from memory 48 hours later? Most candidates cannot. If you can't reproduce it, you haven't learned it.

It ignores company-specific distribution. Campus OAs from TCS, Infosys, and Wipro heavily test implementation and basic data structures. Flipkart, Amazon, and PhonePe skew toward medium-difficulty graph and DP problems. Knowing which patterns your target companies test lets you sequence prep intelligently.

The 7 patterns that cover 80% of campus OAs

These categories account for the vast majority of problems in Indian campus online assessments:

1. Arrays and hashing — frequency counting, two-pointer, prefix sums. Appears in nearly every OA.
2. Strings — sliding window, anagram detection, pattern matching.
3. Linked lists — reversal, cycle detection, merge operations.
4. Binary search — not just on sorted arrays, but on answer spaces.
5. Trees and recursion — traversals, lowest common ancestor, path-sum problems.
6. Greedy algorithms — sorting combined with a local-optimal choice.
7. Dynamic programming — 1D and 2D DP, subset problems, string edit distance.

Service company OAs (TCS, Wipro, Infosys, Cognizant) draw almost entirely from patterns 1–4. Product company OAs (Flipkart, Amazon, Meesho, PhonePe, Swiggy) add 5, 6, and 7 at medium-to-hard difficulty. Focused practice on these pattern families — eight to twelve representative problems each, re-implemented from memory — is more effective than 400 random problems at varying depths.

Two worked examples: how to approach an unseen problem

Example 1 — SDE online assessment: a medium array problem

The problem: Given an array of integers, find the length of the longest subarray whose sum equals exactly k.

What most candidates do: They read the problem, start writing an O(n²) nested loop that checks every subarray, then realise halfway through that the input is 10^5 and the solution will time out. They scrap it and panic with 12 minutes left.

The structured approach:

Step 1 — Read the constraints first. Input size up to 10^5 with a one-second limit. O(n²) is out. You need O(n) or O(n log n).

Step 2 — Identify the pattern. "Subarray with sum equal to a target" is a prefix-sum + hashmap problem. Key insight: store each prefix sum's earliest index in a hashmap. At index i, if (prefix_sum − k) exists in the map, the subarray between that stored index and i has sum exactly k.

Step 3 — Write a skeleton in pseudocode before coding:

prefix_sum = 0
seen = {0: -1}   # sum 0 exists before index 0
max_len = 0

for i, num in enumerate(nums):
    prefix_sum += num
    if prefix_sum - k in seen:
        max_len = max(max_len, i - seen[prefix_sum - k])
    if prefix_sum not in seen:
        seen[prefix_sum] = i   # store the earliest index only

return max_len

Step 4 — Test on two cases before submitting. The provided sample, then one edge case: what if k = 0, or the array has all negatives?

Total time for someone who has practised prefix-sum problems: eight to ten minutes. A candidate who doesn't recognise the pattern spends 25 minutes on a brute force that fails and scores zero.

Example 2 — Data analyst / analytics role: a lookup problem

The problem: Given a list of employee records (employee_id, manager_id, salary), return the IDs of all employees who earn more than their direct manager.

Product analyst OAs frequently frame these as data problems. Candidates who overcomplicate them lose time; the structure is always the same.

The structured approach:

Identify the type: Dictionary lookup with comparison. Build a salary map and a manager map, then iterate and compare.

salary  = {eid: sal for eid, mid, sal in records}
manager = {eid: mid for eid, mid, sal in records}

result = [
    eid for eid in salary
    if manager.get(eid) and salary[eid] > salary.get(manager[eid], float('inf'))
]

Total time: three to four minutes once you've seen the pattern. The category — entity-relationship lookup with comparison — appears consistently across data and analytics OAs. Candidates who approach it as a graph problem spend ten minutes and produce more complex, bug-prone code for the same result.

Before/after: how to read an unfamiliar problem

Before — unstructured approach:

Read problem → start typing the first idea → halfway through, realise it's O(n²) for n = 10^5 → scrap the code → try to rethink from scratch with 10 minutes left → submit broken code with an index error → score 0 test cases on a problem you understood

After — structured five-step approach:

1. Read the entire problem once without writing anything.
2. Note: input size, output type, explicit constraints.
3. From the input size, determine the required time complexity.
4. Ask: which pattern does this resemble? Subarray sum? Prefix sums. Shortest path? BFS. Optimum with a constraint? Possibly DP or binary search on the answer.
5. Write a three-line pseudocode skeleton in comments before any real code.

Then implement. Test on the provided sample. Test one edge case you create yourself. Submit.

The difference is not intelligence — it is a decision framework applied consistently at the start of every problem, before typing. This framework becomes reflexive with practice; eventually it takes under two minutes.

Why the structured approach works: it separates problem identification (a thinking task) from implementation (a coding task). Most unstructured candidates try to do both simultaneously and get stuck in both.

Common mistakes — and how to fix each

Mistake 1: Attempting the hardest problem first

Many candidates jump to the last problem — highest marks, hardest — and spend 40 minutes there. The right default: solve everything comfortable, in order, before attempting anything that might stump you. Hard problems you can't fully solve score the same as unsubmitted ones. Easy and medium problems you finish guarantee marks. Prioritise marks-per-minute, not prestige.

Mistake 2: Ignoring constraints and submitting a slow solution

If n = 10^5 and you are running a nested loop, your solution will time out on larger test cases. Read the input size before you code. If brute force won't pass: write it anyway, submit once to capture partial test-case marks, then start the optimised version. Partial marks from a slow but correct solution beat zero marks from an unfinished fast one.

Mistake 3: Not testing before submitting

Two minutes on two manual test cases catches the most common bugs — a missing modulus, an off-by-one, returning the wrong variable. These take one minute to find and one line to fix. Skipping this step costs you a full test-case group.

Mistake 4: Treating re-reading solutions as learning

If you cannot re-implement a solution two days after reading it, without looking at notes, you have not learned it. After every problem where you looked at the solution: add it to a short log — pattern name, the one key insight, a problem to check yourself. Before your OA, verify you can re-implement each entry from scratch. Ten to fifteen patterns at that level of fluency covers most campus OAs.

What to do this week

Day 1. Look up OA reports for two or three target companies — r/cscareerquestionsIN, r/india, and the experiences section on GeeksForGeeks are the best sources. Note which problem categories came up. That tells you which of the seven patterns to prioritise.

Days 2–3. Pick your two weakest patterns. Find six problems for each on LeetCode filtered by topic (easy to medium). Solve without reading solutions first. For problems you get stuck on: read the key insight, close everything, re-implement from scratch. The re-implementation is what builds the reflex — just reading solutions does not.

Day 4. Do a full timed mock OA: two medium problems in your target company's category, a 90-minute timer, no hints. Treat it as the real assessment.

Day 5. Review the mock. Which problem took longest? Which pattern did you not recognise quickly? Which constraint did you miss? Spend 45 minutes closing exactly that one gap.

Ten patterns, re-implementable from memory, beats three hundred problems solved once and half-forgotten. That is the whole strategy.

---

CareerClutch's technical practice includes timed coding rounds with per-problem feedback on time complexity, edge-case handling, and which pattern the problem belongs to — so you learn the category, not just the solution. If you know your weak patterns from the OA report research above, a few targeted sessions will show you exactly where your approach breaks down before it matters.