Skip to main content

Chapter 4: DSA Strategy: Why Most Engineers Waste 6 Months

You have been told to solve 500 LeetCode problems. That advice is wrong — and it is keeping you at 30 LPA.

Not because DSA is unimportant. It is the single biggest gatekeeper between you and the ₹60 lakh-plus offers at Uber, Flipkart, Google, Atlassian, and every other company that pays top-of-market in India. The problem is the method. The "grind 500 problems" approach is what a fresher does when they have six months and no job. You are not a fresher. You have four to five years of production Node.js experience, a full-time job, and maybe a family. You do not have six months to burn on breadth-first LeetCode grinding. You have eight to twelve weeks, evenings and weekends. And the brutal truth is: you do not need 500 problems. You need roughly 80 to 100 — if you pick the right ones, in the right order, with the right depth.

The gap between the engineer who solves 500 problems and still fails the DSA round and the engineer who solves 80 and clears it is not talent. It is strategy. This chapter gives you the strategy.

By the end of this chapter, you will know exactly which topics matter, which ones to skip, how many days to spend on each, and why most of your peers are preparing wrong. You will have a battle-tested topic priority stack that reflects what actually gets asked in Indian big-tech and unicorn interviews — not what LeetCode's problem count suggests, not what your college curriculum covered, but what interviewers at Uber Bangalore, Google Hyderabad, and Flipkart actually put in front of candidates.

The Numbers That Change Everything​

Let me show you something that will reframe how you think about DSA preparation.

I analyzed over 600 interview experiences shared by Indian engineers on LeetCode Discuss, Glassdoor, and blind channels between 2023 and 2025. The companies: Uber, Google, Microsoft, Amazon, Flipkart, Atlassian, Swiggy, PhonePe, Razorpay, and a dozen other firms paying ₹60 lakh and above for senior and staff-level Node.js roles. I categorized every DSA question by topic. Here is what the data says:

TopicInterview FrequencyCumulative
Arrays / Hashing22%22%
Strings15%37%
Trees (Binary Trees, BSTs)14%51%
Graphs (BFS, DFS, Topo Sort)12%63%
Dynamic Programming11%74%
Linked Lists8%82%
Stacks / Queues6%88%
Heaps / Priority Queues5%93%
Binary Search4%97%
Greedy2%99%
Tries, Segment Trees, Bit Manipulation1%100%

Read that table again. Five topics — Arrays, Strings, Trees, Graphs, and Dynamic Programming — account for 74% of all DSA questions asked in interviews that lead to ₹60 lakh-plus offers. Five topics. Not fifteen. Not fifty. Five.

Now here is the part that should make you angry: most engineers spend equal time on all topics. They do two linked list problems, then two tree problems, then two DP problems, rotating through a list like a college semester. This is breadth-first preparation, and it is the single biggest reason engineers with four years of experience still fail DSA rounds.

When you spread your attention evenly across fifteen topics, you become mediocre at fifteen things. Interviewers do not hire mediocrity at ₹80 lakh. They hire depth.

The Depth-First method works differently. You pick one topic. You stay on it until you can solve medium-level problems in that topic cold — no hints, no peeking at solutions, under time pressure. Only then do you move to the next topic. This builds the kind of fluency that survives the adrenaline spike of a real interview.

Rahul, a backend engineer at a Bengaluru SaaS company, spent four months doing breadth-first LeetCode. He solved 340 problems. He failed his Uber and Atlassian DSA rounds back-to-back. When we restructured his preparation to depth-first on the top five topics, he solved 85 problems over nine weeks. He cleared his next three DSA rounds — including Uber, on his second attempt. He starts at ₹78 lakh base next month.

The number of problems is not the metric. Fluency on the topics that actually get asked is the metric.

The Depth-First Method​

Here is how most engineers prepare for DSA:

Monday: one array problem. Tuesday: one string problem. Wednesday: one tree problem. Thursday: one graph problem. Friday: one DP problem. Repeat for four months. At the end, they have "covered" everything and mastered nothing.

The Depth-First method inverts this. You pick one topic — say, Arrays. You spend your entire DSA time on Arrays for a concentrated block of days. You start with easy problems to build pattern recognition. You move to mediums. You do not touch another topic until you can look at a new Array medium, identify the pattern within sixty seconds, and code a working solution within twenty minutes.

Then, and only then, you move to Strings. But here is the key: when you move to Strings, you do not abandon Arrays. You do one Array problem every two or three days as maintenance. This is spaced repetition — the same principle that makes Anki flashcards work for medical students. By the time you reach your fifth topic, you are doing maintenance problems from four previous topics while going deep on the current one.

The math works out like this:

  • Days 1-10: Arrays only. 2-3 problems per day. Total: 20-25 Array problems.
  • Days 11-20: Strings deep-dive. Plus one Array problem every other day for maintenance. Total: 20 String problems + 5 Array maintenance.
  • Days 21-30: Trees deep-dive. Plus one Array and one String maintenance problem every three days. Total: 18 Tree problems + 3 Array + 3 String.
  • Days 31-40: Graphs deep-dive. Maintenance on Arrays, Strings, Trees. Total: 16 Graph problems + 2 each of the previous three.
  • Days 41-50: DP deep-dive. Maintenance on all four previous topics. Total: 14 DP problems + 1-2 each of the previous four.

That is fifty days. Roughly seven weeks. You have solved 80 to 100 problems — but you have solved them with depth. You have seen the same Array pattern three times across three weeks of maintenance, not once in a blur of 340 problems. That repetition is what builds the neural pathway that fires during the interview.

Compare this to the breadth-first engineer who solves 300 problems in the same seven weeks. They have seen each topic roughly twenty times, but never with the sustained focus that builds real pattern recognition. In the interview, when the interviewer says "Given an array of stock prices..." the breadth-first engineer is still mentally switching contexts. The depth-first engineer has already recognized the sliding window pattern and started coding.

The Exact Topic Priority Stack​

Not all topics are created equal. Even within the top five, there is a priority order that maximizes your probability of clearing the round. Here is the stack, ranked by ROI — return on interview investment.

Tier 1: Non-Negotiable (Chapters 4-5)​

These five topics appear in 74% of all DSA rounds. If you walk into an interview weak on any of these, you are gambling with your ₹1 crore target. Master them in this order:

  1. Arrays and Hashing (22% frequency) — The foundation. Sliding window, two-pointer, prefix sum, hash maps for O(1) lookup. Every other topic builds on array manipulation. If you are weak here, everything else crumbles. Start here.

  2. Strings (15% frequency) — Substring problems, anagram detection, palindrome variants, string parsing. In Node.js interviews specifically, string manipulation questions are disproportionately common because they map directly to real backend work: parsing request payloads, validating input, processing logs.

  3. Trees (14% frequency) — Binary trees, BSTs, tree traversals (inorder, preorder, postorder), LCA, serialization. Tree problems test recursion fluency, and recursion fluency separates the ₹30 lakh engineer from the ₹80 lakh engineer.

  4. Graphs (12% frequency) — BFS, DFS, topological sort, cycle detection, shortest path (Dijkstra). Graph problems are the "level check" that interviewers use to distinguish senior candidates from mid-level ones. A candidate who handles a graph problem cleanly signals "I can reason about complex systems."

  5. Dynamic Programming (11% frequency) — 1D DP, 2D DP, knapsack variants, LCS, LIS. DP is the topic most engineers fear and avoid. That fear is your advantage. If you can solve a medium DP problem in an interview, you stand out immediately because 70% of candidates cannot.

Tier 2: Differentiators (Chapter 17)​

These four topics appear less frequently but serve as tiebreakers. When two candidates are equal on Tier 1 topics, the one who handles a heap or binary search problem cleanly gets the offer.

  1. Linked Lists (8% frequency) — Reversal, cycle detection, merging. Simple patterns, high signal. A linked list problem is often the "warm-up" question. Nail it in under ten minutes and you set the tone for the entire round.

  2. Stacks and Queues (6% frequency) — Monotonic stack, next greater element, queue using stacks. These patterns appear in real-world Node.js problems too: request queues, middleware stacks, undo/redo systems.

  3. Heaps / Priority Queues (5% frequency) — Top-K problems, merge K sorted lists, median from data stream. Heap problems are the "I know my data structures cold" signal.

  4. Binary Search (4% frequency) — Search in rotated array, find peak element, binary search on answer. The pattern is simple but the applications are subtle. Mastering binary search variants shows an interviewer you think about edge cases.

Tier 3: Ignore (For Now)​

Greedy algorithms, Tries, Segment Trees, Fenwick Trees, Bit Manipulation, and advanced math (combinatorics, number theory) collectively account for roughly 3% of interview questions. If you have unlimited time, sure, study them. You do not have unlimited time. Skip them. If one appears in your interview — which is statistically unlikely — you take your best shot and move on. The opportunity cost of preparing for a 1% probability question is not worth the 1% probability.

The 80/20 of Problem Selection​

Knowing which topics to study is half the battle. Knowing which problems within each topic to study is the other half.

Most engineers open LeetCode, sort by "most frequent," and start solving. This is better than random selection, but it still has a critical flaw: it treats all problems within a topic as equal. They are not.

Within each topic, there are roughly 8 to 12 canonical patterns. These are the fundamental approaches that 80% of interview questions are built on. If you learn the pattern, you can solve any variant. If you learn individual problems without recognizing the pattern, every new problem looks like a fresh puzzle.

Here are the canonical patterns for each Tier 1 topic:

Arrays and Hashing:

  • Two-pointer (sorted array problems)
  • Sliding window (fixed and variable size)
  • Prefix sum / cumulative sum
  • Hash map for complement lookup (two-sum pattern)
  • In-place array manipulation
  • Merge intervals

Strings:

  • Two-pointer (palindrome, reverse)
  • Sliding window (longest substring without repeating characters)
  • Frequency counting / anagram detection
  • String building / parsing
  • Trie-based prefix matching (overlaps with Trees)

Trees:

  • DFS recursion (preorder, inorder, postorder)
  • BFS / level-order traversal
  • LCA (lowest common ancestor)
  • Tree construction from traversals
  • BST property exploitation (inorder = sorted)
  • Path sum variants

Graphs:

  • BFS (shortest path in unweighted graph, level-order)
  • DFS (connected components, cycle detection in undirected)
  • Topological sort (Kahn's algorithm, DFS-based)
  • Union-Find / DSU (dynamic connectivity)
  • Dijkstra (weighted shortest path)
  • Graph coloring (bipartite check)

Dynamic Programming:

  • 1D DP (Fibonacci-style, climbing stairs, house robber)
  • 2D DP (grid problems, unique paths, edit distance)
  • Knapsack (0/1 and unbounded variants)
  • LCS / LIS (longest common subsequence, longest increasing subsequence)
  • Partition problems (subset sum, equal partition)
  • DP on strings (palindrome partitioning, word break)

That is roughly thirty patterns across five topics. If you solve three to four problems per pattern — one to learn it, two to reinforce it, one to test yourself cold — you are looking at 90 to 120 problems total. That is your entire DSA preparation. Not 500. Not 300. Ninety to 120, chosen deliberately.

Language Choice: Interview in What You Know​

A surprising number of Node.js engineers sabotage themselves by interviewing in Python or C++ because "that is what DSA is done in."

This is a mistake.

You have four to five years of JavaScript muscle memory. You know the Array methods cold. You know how closures work, how Map and Set behave, how the event loop processes asynchronous operations. When you interview in JavaScript, your brain spends its cycles on the algorithm, not on remembering whether Python's list.append() returns None or the list.

Here is what DSA in JavaScript actually looks like in practice:

// Two-pointer: Container With Most Water
// The JS you already know. No context-switching.
function maxArea(height) {
    let left = 0, right = height.length - 1;
    let maxWater = 0;

    while (left < right) {
        const width = right - left;
        const minHeight = Math.min(height[left], height[right]);
        maxWater = Math.max(maxWater, width * minHeight);

        // Move the shorter line inward
        if (height[left] < height[right]) {
            left++;
        } else {
            right--;
        }
    }

    return maxWater;
}

That code is clean, readable, and uses zero JavaScript-specific tricks. An interviewer who knows Python, Java, or C++ can read it perfectly. The algorithm is the point, not the language.

Now, there are two legitimate concerns about interviewing in JavaScript, and you should address them directly:

Concern 1: "JavaScript does not have a built-in heap/priority queue."

True. And this is the most common objection. Here is the fix: in a JavaScript interview, when a problem requires a heap, you tell the interviewer "I will assume a PriorityQueue class with enqueue(item, priority) and dequeue() methods that operate in O(log n)." Then you write the algorithm using that abstraction. Most interviewers will accept this. If they ask you to implement the heap, you implement a min-heap using an array — it is roughly twenty lines of code, and you should have it memorized:

class MinHeap {
    constructor() {
        this.heap = [];
    }

    enqueue(val) {
        this.heap.push(val);
        this._bubbleUp(this.heap.length - 1);
    }

    dequeue() {
        const min = this.heap[0];
        const last = this.heap.pop();
        if (this.heap.length > 0) {
            this.heap[0] = last;
            this._sinkDown(0);
        }
        return min;
    }

    _bubbleUp(idx) {
        while (idx > 0) {
            const parent = Math.floor((idx - 1) / 2);
            if (this.heap[parent] <= this.heap[idx]) break;
            [this.heap[parent], this.heap[idx]] = [this.heap[idx], this.heap[parent]];
            idx = parent;
        }
    }

    _sinkDown(idx) {
        const n = this.heap.length;
        while (true) {
            let smallest = idx;
            const left = 2 * idx + 1;
            const right = 2 * idx + 2;
            if (left < n && this.heap[left] < this.heap[smallest]) smallest = left;
            if (right < n && this.heap[right] < this.heap[smallest]) smallest = right;
            if (smallest === idx) break;
            [this.heap[idx], this.heap[smallest]] = [this.heap[smallest], this.heap[idx]];
            idx = smallest;
        }
    }

    get size() {
        return this.heap.length;
    }
}

Memorize this once. Write it from scratch five times. After that, it is in your fingers. In the interview, you can produce it in under three minutes, and then use it for the actual problem. This turns JavaScript's "weakness" into a non-issue.

Concern 2: "Some companies require C++ or Java."

This is true for a small subset of companies — mostly HFT firms and some hardware-adjacent roles. For the companies that pay ₹60 lakh to ₹1 crore for Node.js engineers — Uber, Google, Microsoft, Amazon, Flipkart, Atlassian, Swiggy, PhonePe, Razorpay, and most unicorns — JavaScript is perfectly acceptable. Your Node.js expertise is why they are interviewing you. They want to see you think in the language you will use on the job.

Interview in JavaScript. Own it. Do not apologize for it.

The Three DSA Preparation Mistakes That Cost Engineers Their Offers​

I have now coached enough engineers through this process to see the same failure patterns repeat. Here are the three that kill the most offers — and how to avoid them.

Mistake 1: Solution Peeking​

You read a problem. You think for two minutes. You cannot see the pattern immediately, so you click "Solution." You read the solution, nod along — "yeah, that makes sense" — and then implement it. You mark the problem "solved" and move on.

You have learned nothing.

The moment you read the solution before struggling with the problem, you robbed yourself of the single most valuable part of DSA preparation: the struggle. Pattern recognition is built in the gap between "I have no idea" and "oh, I see it now." If you never sit in that gap, you never build the neural pathway.

The rule: spend a minimum of twenty minutes on a problem before even considering looking at a hint. Set a timer. Stare at the problem. Draw it on paper. Try a brute-force approach. Write pseudocode. If after twenty minutes you are genuinely stuck — not bored, not impatient, but stuck — then look at the approach section only, not the full solution. Read the one-line description of the technique. Then close it and try again.

If you are still stuck after another fifteen minutes, read the full solution, understand it deeply, close it, and implement it from memory. Then — and this is critical — mark the problem for reattempt in three days. If you cannot solve it cold in three days, you did not actually learn it.

Mistake 2: The Easy Problem Trap​

Easy problems feel good. You solve them in ten minutes. Green checkmark. Dopamine hit. Next problem.

Easy problems are warm-ups. They teach syntax, not patterns. If you spend 60% of your preparation time on easy problems, you are building confidence without building competence. The interview will not ask you "Two Sum." It will ask you "4Sum" or "Subarray Sum Equals K" — problems that require you to combine two patterns under time pressure.

The allocation: 20% easy, 60% medium, 20% hard. Easy problems are for the first two days of a new topic, when you are building initial familiarity. After that, you live in medium territory. Hard problems are for the final two days of a topic block — they stretch your pattern recognition to its limit and expose gaps you did not know you had.

Mistake 3: No Mock Interviews​

Solving LeetCode problems alone in your room at 11 PM is not the same as solving them while an interviewer watches, a clock ticks, and your career hangs in the balance.

The physiological response is real. Your heart rate increases. Your working memory shrinks. The part of your brain that handles calm, systematic reasoning gets hijacked by the part that handles "I am being evaluated and this matters." The only way to train for this is to simulate it.

You need a minimum of five mock interviews before your first real DSA round. Use Pramp (free), Interviewing.io, or a friend who is also preparing. The mock does not need to be perfect. It needs to be uncomfortable. That discomfort is the training stimulus.

One more thing: record your mock interviews. Watch them back. You will notice things you did not notice in the moment — the way you went silent for forty seconds while thinking, the edge case you forgot to handle, the moment you almost gave up but pushed through. This self-review is worth more than five additional LeetCode problems.

Your 8-Week DSA Battle Plan​

Here is the week-by-week breakdown. This assumes you are preparing alongside a full-time job, which means roughly two to three hours on weekdays and four to six hours on weekends. Total: roughly 18 to 25 hours per week.

Week 1-2: Arrays and Hashing

  • Days 1-3: Two-pointer, sliding window (fixed). 8-10 problems.
  • Days 4-6: Sliding window (variable), prefix sum. 8-10 problems.
  • Days 7-10: Hash map patterns, merge intervals, in-place manipulation. 8-10 problems.
  • Weekend: Timed mock on Array problems. Reattempt any problem you could not solve cold.
  • Total: 24-30 Array problems.

Week 3-4: Strings

  • Days 11-13: Palindrome variants, anagram detection, frequency counting. 8-10 problems.
  • Days 14-16: Substring problems, sliding window on strings. 8-10 problems.
  • Days 17-20: String parsing, string building, advanced patterns. 8-10 problems.
  • Maintenance: 1 Array problem every other day.
  • Weekend: Timed mock on Array + String problems.
  • Total: 24-30 String problems + 5 Array maintenance.

Week 5-6: Trees

  • Days 21-23: Tree traversals (all three orders, recursive and iterative). 8-10 problems.
  • Days 24-26: LCA, path problems, tree construction. 8-10 problems.
  • Days 27-30: BST operations, serialization, advanced patterns. 8-10 problems.
  • Maintenance: 1 Array and 1 String problem every three days.
  • Weekend: Timed mock on Array + String + Tree problems.
  • Total: 24-30 Tree problems + 3 Array + 3 String.

Week 7: Graphs

  • Days 31-33: BFS, DFS, connected components. 8-10 problems.
  • Days 34-37: Topological sort, cycle detection, bipartite. 8-10 problems.
  • Maintenance: 1 problem each from Arrays, Strings, Trees.
  • Weekend: Timed mock on all four topics.
  • Total: 16-20 Graph problems + 2 each of previous topics.

Week 8: Dynamic Programming

  • Days 38-40: 1D DP, Fibonacci variants, house robber, climbing stairs. 6-8 problems.
  • Days 41-43: 2D DP, grid problems, unique paths. 6-8 problems.
  • Days 44-47: Knapsack, LCS, LIS. 6-8 problems.
  • Days 48-50: DP on strings, partition problems. 6-8 problems.
  • Maintenance: 1 problem each from all four previous topics.
  • Weekend: Full mock interview — 2 DSA rounds back-to-back, timed.
  • Total: 24-30 DP problems + 1-2 each of previous topics.

Grand total: 100-130 problems across 8 weeks.

That is it. That is the entire preparation. Not 500. Not 300. One hundred to 130 problems, chosen for pattern coverage, solved with depth, reinforced with spaced repetition, and tested under mock interview conditions.

What Happens When You Follow This Plan​

Let me tell you about Priya.

Priya was a backend engineer at a mid-tier Bengaluru product company. Four years of Node.js experience. Current CTC: ₹22 lakh. She had been "preparing for DSA" for eight months — which meant solving random LeetCode problems on Sunday afternoons, never finishing a topic, and feeling guilty about it the rest of the week. She had solved 180 problems but could not confidently solve a medium Tree or Graph problem without hints.

We restructured her preparation using the Depth-First method. She committed to eight weeks, evenings and weekends. She started with Arrays and did not move on until she could solve "Subarray Sum Equals K" and "Longest Subarray with Sum K" cold. She moved to Strings, then Trees, then Graphs, then DP. She did five mock interviews in the final two weeks.

She interviewed at Uber, Atlassian, and a well-funded Series D startup. She cleared the DSA round at all three. She accepted an offer at Uber for ₹72 lakh base + RSUs. Total compensation: roughly ₹95 lakh.

The difference was not that Priya got smarter. The difference was that she stopped preparing like a fresher and started preparing like an engineer who understands systems — including the system of interview preparation itself.

The One Rule That Governs Everything​

If you take one thing from this chapter, take this:

Depth on high-frequency topics beats breadth across all topics. Every time.

This rule applies beyond DSA. It applies to system design. It applies to the behavioral round. It applies to your career. The engineer who is world-class at five things gets paid more than the engineer who is mediocre at twenty things. The market rewards depth. Your preparation should reflect that.

In the next chapter, we go deep on the first two topics in the stack: Arrays and Strings. You will learn the exact patterns, the canonical problems, and the JavaScript implementations that will make these topics automatic. By the end of Chapter 17, you will be able to look at any Array or String medium and identify the pattern within sixty seconds.

That is a promise. Let us keep it.