Here is a confession almost every DSA student makes at some point: "I understood every lesson. I can trace binary search in my sleep. But when a NEW problem appears in the test, my mind goes blank — I don't know which technique to even start with."
If that's you, nothing is wrong with you. You've built eleven tools; nobody has yet taught you the skill of looking at a fresh problem and knowing which tool it is secretly asking for. That skill has a structure, it can be learned in one lesson, and this is that lesson. We'll also cover the second half of interview success: how to PERFORM a solution in front of an interviewer, step by step, even when you're nervous.
Why your mind goes blank on new problems
Think about how you learned the last eleven lessons. Each one introduced a technique and then gave you problems that use it. So your brain never had to ask "which technique?" — the chapter heading answered that before you read the question.
A test removes the chapter heading. Now the very first decision — the one you never practised — is the whole game. You're not blanking because you forgot the techniques. You're blanking because choosing the technique is a separate skill, and it was hidden from you by the way textbooks are organised.
A senior doctor doesn't run every test in the hospital on every patient. She listens for two minutes and already has three hypotheses, because thousands of patients taught her which symptoms point where. We are going to build that diagnostic sense for problems — deliberately, not by luck.
The naive plan: solve 500 problems and hope
The most common prep plan is volume: grind hundreds of random problems and trust that recognition appears by itself. Let's be honest about what this costs.
Say a problem takes 40 minutes. Five hundred problems is over 330 hours — months of evenings. And here's the waste: if you solve them without naming the pattern each one used, your brain stores 500 separate memories instead of 15 reusable patterns. New problem number 501 still looks brand new. Students on this plan often report the blank-mind feeling even after 400 solves — because they practised solving, never diagnosing.
Pause and ask yourself: after your last practice problem, could you say in one sentence which pattern it was and which words in the statement gave it away? If not, the hours aren't compounding.
The observation: problems repeat, in disguise
Now the observation that fixes it. Look at these three problems:
- Find two numbers in a sorted array that sum to a target.
- Find a pair of songs whose durations add up to exactly the flight time.
- Given trees planted along a road with heights sorted, find two whose heights sum to H.
Songs, trees, numbers — three stories, one problem: pair-sum on sorted data, which lesson 3 solved with two pointers. Interview problems are a small set of skeletons wearing different costumes. There are maybe 15–20 skeletons in total, and you already know almost all of them from lessons 1–11.
So the skill isn't "solve anything from scratch". It's strip the costume, name the skeleton. And skeletons leave fingerprints in the problem statement itself — specific words and constraints that point to specific techniques. Let's build the fingerprint chart.
Signal words — the problem names its technique
Read the left column the way a doctor reads symptoms. One signal is a hypothesis, two agreeing signals are near-certainty:
| The problem says… | First suspect | Because |
|---|---|---|
| "sorted array", "find position/target" | Binary search | sorted order exists to be halved |
| "pair", "remove duplicates", sorted input | Two pointers | walk ends inward instead of trying all pairs |
| "subarray/substring" + "longest / max sum / at most K" | Sliding window | contiguous ranges grow and shrink at the edges |
| "seen before?", "count frequency", "pair sums to" (unsorted) | Hash map / set | trade memory for instant membership checks |
| "ALL combinations / permutations / subsets" | Backtracking | only exploring the choice tree lists everything |
| "minimum/maximum … count the ways" + choices overlap | Dynamic programming | optimise over overlapping subproblems |
| "shortest path", unweighted / "minimum steps" | BFS | BFS reaches every node in fewest edges first |
| "shortest path" with weights ≥ 0 | Dijkstra | greedy settle-the-nearest works when weights can't refund |
| "connected components", "islands", "same group?" | DFS/BFS or Union-Find | connectivity is traversal (or merged sets) |
| "top K", "K-th largest", "most frequent K" | Heap of size K | never sort a lakh to keep 10 |
| "matching brackets", "undo", "nearest greater to the left" | Stack | most-recent-first is LIFO by definition |
| "XOR", "appears once, rest twice", "without extra memory" | Bits | pairs cancel under XOR; masks store sets in one int |
Here is the same map as a picture — worth keeping open during practice until it lives in your head:
💡 From today, end every practice problem with one written line: "Pattern: ___. Giveaway: ___." Ten seconds per problem. This single habit converts problem-grinding into pattern-building — it is the highest-return ten seconds in DSA prep.
Reading constraints: n tells you the complexity
The second fingerprint hides in the constraints line everyone skips: 1 ≤ n ≤ 10^5. That line is the setter whispering the intended complexity. Roughly 108 simple operations run per second, so:
| n up to… | Affordable complexity | Which usually means |
|---|---|---|
| ~20 | O(2ⁿ) or O(n!) | backtracking / bitmask over subsets is INTENDED |
| ~500 | O(n³) | triple loop, small DP tables |
| ~5,000 | O(n²) | 2-D DP, all-pairs checks |
| ~10⁵ – 10⁶ | O(n log n) or O(n) | sort + linear pass, heap, sliding window, hash map |
| ~10⁹ or more | O(log n) or O(1) | binary search or pure maths — loops are already dead |
Read it both ways. n ≤ 20 doesn't just PERMIT exponential — it practically announces "the answer is backtracking", because why else would the setter keep n so tiny? And n = 105 with a pairs-flavoured question is telling you the O(n²) brute force is a trap laid for the unprepared.
Dry run: diagnosing three problems live
Let's run the diagnosis procedure on three fresh problems. For each one, pause at the ❓ and commit to a guess before reading on — the pause is where the skill forms.
Problem A. "Given an integer array (n up to 10⁵) and k, find the maximum sum of any contiguous subarray of length k." ❓ What jumps out?
signal 1: 'contiguous subarray' + 'maximum' -> window flavour signal 2: fixed length k -> fixed-size window constraint: n = 10^5 -> need O(n); nested loops (n*k) too slow DIAGNOSIS: sliding window — add entering element, drop leaving one
Problem B. "n friends (n ≤ 16) must be split into two teams so the skill difference is minimum. Print the minimum difference." ❓ Your guess?
signal 1: 'split into two teams', minimise -> try groupings signal 2: n <= 16 (!!) -> 2^16 = 65,536 subsets: cheap DIAGNOSIS: enumerate subsets — backtracking or bitmask loop the tiny n was the loudest clue on the page
Problem C. "A grid of 0s and 1s. From the top-left, reach the bottom-right stepping only on 0s. Minimum number of steps, or −1." ❓ Last one — commit.
signal 1: grid + allowed moves -> a graph in costume (cells = nodes) signal 2: 'minimum number of steps', each step costs 1 -> unweighted DIAGNOSIS: BFS from the start cell; first arrival = fewest steps (weights on cells would upgrade this to Dijkstra)
Notice what never happened: we never "had an idea". We read symptoms and looked them up. That's the point — diagnosis is a procedure, not inspiration, which means it still works when you're nervous.
The interview ritual: 7 steps, every time
Diagnosis gets you the technique; the ritual gets you the offer. Interviewers grade the process as much as the code — a structured performance with a small bug beats silent perfect code. Run these seven steps in order, out loud, every single time:
- Restate the problem in your own words. Cheap insurance against solving the wrong question.
- Ask about edges and constraints: empty input? duplicates? negatives? how big is n? (You now know why n matters.)
- Work one small example by hand — 5 elements, on the whiteboard. This is a dry run before any algorithm exists, and it often reveals the pattern by itself.
- Say the brute force first, with its complexity: "I could check all pairs in O(n²); let me look for better." This banks a working answer and shows you know its cost. Never skip this step to look smart — naming the naive approach IS the smart move.
- Diagnose out loud: "sorted input plus pair-finding suggests two pointers…" — the signal table, spoken. Get a nod before coding.
- Code cleanly, narrating each piece: real names, edge cases first.
- Trace your own code on the example from step 3, then state time and space. Catching your own off-by-one is worth more than never making it.
Steps 4–7 look like this in miniature:
# Step 4 (said aloud): "brute force checks all pairs — O(n^2)."
# Step 5: "the array is SORTED — that's the two-pointers signal."
def pair_sum(arr, target): # Step 6: code, narrated
lo, hi = 0, len(arr) - 1
while lo < hi:
s = arr[lo] + arr[hi]
if s == target:
return (arr[lo], arr[hi])
if s < target: # sum too small -> need bigger
lo += 1
else: # sum too big -> need smaller
hi -= 1
return None
# Step 7: trace on the step-3 example, then state O(n) time, O(1) space
print(pair_sum([2, 5, 8, 11, 15], 16))Result
(5, 11)
When you're stuck: the unstick ladder
Even with the table, some problems won't open. Don't freeze and don't jump to the answer key — climb this ladder one rung at a time, and stop at the first rung that unsticks you:
- Shrink the input. Can't see it for n = 10⁵? Solve it by hand for n = 4. Watch what your own hands do — your hands often know the algorithm before your head does.
- Solve an easier version. Drop a constraint (assume sorted, assume no negatives), solve that, then ask what the constraint breaks.
- Interrogate every given fact. The problem said sorted / distinct / n ≤ 16 for a reason. Which technique does each fact feed?
- Change the data structure. Ask: what question am I answering repeatedly inside my loop, and which structure makes THAT question O(1) or O(log n)?
- Go brute force and stare at the waste. Write the O(n²) honestly, then name what it recomputes — the eleven lessons behind you are precisely a catalogue of wastes and their cures.
🎯 In a live interview, being stuck is survivable — being silent is not. Narrate the rung you're on: "Let me try a 4-element example… interesting, I only ever need the previous two values…" Interviewers routinely pass candidates who got unstuck with one hint over candidates who were silently perfect, because the ladder IS the job skill.
What if…? The edge-case checklist
Before you say "done" — in practice or in interviews — attack your own solution with these:
- What if the input is empty, or has one element? Half of all loop code assumes at least two.
- What if everything is equal? Duplicates break naive two-pointer moves and "strictly greater" logic.
- What if values are negative or zero? Negative numbers quietly kill greedy sums and Dijkstra alike.
- What if the answer doesn't exist? No valid pair, unreachable target — does your code return something sane or crash?
- What if n is at the maximum? Re-check your complexity against the constraints table one last time.
Common mistakes
- Coding in the first sixty seconds. The first idea is usually the brute force wearing confidence. Diagnose first; the minute you "lose" is repaid tenfold.
- Grinding problems without naming patterns. 500 solves that skip the "Pattern: ___" line build fatigue, not recognition.
- Ignoring the constraints line. It's the only place the setter tells you the intended complexity — reading it is legal and encouraged.
- Hiding the brute force. Students skip step 4 fearing it looks weak; interviewers read the skip as "can't analyse costs".
- Memorising code instead of reasons. Memorised code collapses at the first twist. The why — which waste this technique removes — survives every costume change.
Quick revision
| Idea | One line |
|---|---|
| Blank-mind cause | choosing the technique is a skill you never practised |
| Pattern reality | ~15–20 skeletons wear every interview costume |
| Signal words | the statement names its technique — read like a doctor |
| Constraints | n ≤ 20 → exponential intended; 10⁵ → O(n log n) or better |
| The ritual | restate → edges → example → brute force → diagnose → code → trace |
| Stuck? | shrink input → easier version → use every fact → new structure → name the waste |
| Practice habit | end every problem with "Pattern: ___. Giveaway: ___" |
One thing to remember
New problems are old problems in costume — don't hunt for ideas, hunt for fingerprints: signal words and constraints point to the skeleton, and the skeleton you already know. If you leave with only this sentence, your next mock test will feel different.
Practice Zone
Every question below is a diagnosis exercise in disguise — before answering, name the pattern and the giveaway, exactly as you'll do in the real thing.
"Find the longest contiguous stretch of days with total rainfall under X" — the signal words map to:
Asked in
Constraint n ≤ 10⁵ and a 1-second limit (~10⁸ simple ops). Which solution complexities are acceptable?
Asked in
"Minimum number of moves/steps to transform state A into state B" (word ladders, knight moves, lock combinations) is almost always:
Asked in
You're stuck at minute 5 of an interview problem. The best next move is:
Asked in
"Ship packages within D days; find the minimum ship capacity" — the give-away that this is binary search on the answer is:
Asked in
Your interviewer asks the complexity of your solution and then: "can you do better?" — but you believe it's optimal. You should:
Asked in
Name the technique (and the signal that gave it away) for each: (1) kth largest element in a stream; (2) all phone-number letter combinations; (3) max profit, one buy one sell; (4) smallest window in S containing all of T; (5) cheapest flight route with at most 2 stops; (6) count subsets summing to K.
Asked in
Problem: "Given n = 10⁵ stock prices, find the maximum profit from one buy and one sell." Write out the COMPLETE interview performance: clarify, constraints-read, brute force, optimise, code, test — as you would say it aloud.
Asked in
FAQ
How many problems should I solve before interviews?
Quality beats count: 100–150 problems chosen across the pattern map, each ended with the "Pattern: ___. Giveaway: ___" line, outperform 500 random grinds. When a new problem's pattern is obvious to you within two minutes for most of the map, you're ready.
What if a problem mixes two patterns?
Harder problems often chain them — binary search on the answer with a greedy feasibility check, or BFS where states are bitmasks. Diagnose the OUTER question first ("minimise the maximum" → binary search on answer), then the inner check. The signal table still works; you just run it twice.
Should I say the brute force even when I see the optimal instantly?
Yes — one sentence: "Brute force is all pairs at O(n²); I'll go straight to two pointers since the array is sorted." It costs ten seconds and proves the cost analysis the interviewer is grading. Skipping it risks looking like you memorised the answer.
How do I practise the interview ritual alone?
Speak it — literally, out loud, alone in your room, timer at 35 minutes. Restate, ask your own edge questions, whiteboard a small example, narrate the code. It feels silly for two sessions and then becomes automatic, which is the whole idea: rituals survive nerves; inspiration doesn't.
That's the course — all twelve lessons. Now mock-interview yourself company by company: Google, Amazon, Microsoft and the rest — three attempt-first questions each. And if you haven't yet, the Data Structures course is this course's other half.