You solved 300 problems and still froze
Three months of daily LeetCode. Four hundred problems in your submission history. Then the interviewer shares a screen with a question you have never seen, and your mind goes completely blank.
This happens to good engineers constantly, and the reason is uncomfortable: solving 300 problems teaches you 300 answers. It does not teach you what to do when the 301st is different. What separates the candidate who gets the offer is not volume. It is recognition — looking at an unfamiliar problem and thinking I have seen this shape before.
LeetCode patterns are those shapes. There are roughly fifteen of them, and between them they cover the overwhelming majority of what Amazon, Google, Microsoft and every company copying their process actually asks.
Why patterns beat problem counts
Chess grandmasters do not memorise games. Studies of expert players found they remember board positions far better than novices — but only when the pieces are arranged in ways that could occur in a real game. Show them a random scatter and their advantage disappears. They are not storing squares. They are storing structures.
Interview problems work the same way. "Find the longest substring with at most K distinct characters" and "find the smallest subarray whose sum is at least target" look nothing alike. Different data, different question, different answer. Structurally they are the same problem: a contiguous run that grows and shrinks against a constraint. One pattern solves both.
Learn the answer and you can solve one problem. Learn the structure and you can solve every problem built on it, including the ones nobody has published yet.
The 15 patterns, and the signal that triggers each one
A pattern is only useful if you can recognise it under pressure. So learn each one paired with its recognition signal — the phrase or constraint in the problem statement that should make you reach for it.
- Two pointers — sorted input, a pair or triplet summing to a target, comparing from both ends, in-place deduplication.
- Sliding window — a contiguous subarray or substring, plus "longest", "shortest", "maximum" or "minimum" with a constraint.
- Fast and slow pointers — linked list cycles, finding the middle in one pass, number sequences that repeat.
- In-place linked list reversal — reverse a list or a sublist, reorder nodes, and no extra memory allowed.
- Stacks and monotonic stacks — matching brackets, "next greater element", parsing expressions, anything that depends on the most recent unmatched thing.
- Modified binary search — sorted or rotated-sorted input, "find the minimum X that works", or an explicit O(log n) demand.
- Tree BFS — the word "level" appears, or you need the shortest path in an unweighted structure.
- Tree DFS — root-to-leaf paths, sums along a path, height and diameter, validating a tree property.
- Graphs on grids — a 2D grid of cells, connected regions, "how many steps to reach or fill everything".
- Topological sort — prerequisites, build order, task scheduling, detecting a cycle in a directed graph.
- Heaps and top-K — "K largest", "K closest", "K most frequent", a running median, merging sorted streams.
- Subsets and backtracking — generate every combination, permutation or subset; constraint puzzles like N-Queens.
- Dynamic programming — "number of ways", "minimum or maximum cost", overlapping subproblems, "can you make X from these".
- Greedy and intervals — intervals to merge or schedule, "maximum non-overlapping", "minimum to remove", jump and reach problems.
- Tries and union-find — prefix search and word dictionaries for tries; connected components and "are these two joined" for union-find.
Read that list again and notice what it is not. It is not fifteen algorithms to memorise. It is fifteen questions to ask the problem statement. Most candidates can already implement BFS. Very few can look at a grid of rotting oranges and say "that is multi-source BFS" within thirty seconds.
How to actually use a pattern in the room
Recognising the pattern is step four, not step one. Interviewers score the whole approach, so run the same sequence every time:
- Clarify. Input size, value ranges, duplicates, empty input, whether the array is sorted. Two minutes here prevents a wrong solution.
- Work an example. By hand, out loud, on the smallest interesting case. This is where the pattern usually reveals itself.
- State the brute force and its complexity. Say the O(n²) out loud and say why it fails: "at n equals 100,000 that is 10¹⁰ operations, which will time out."
- Name the pattern. "The array is sorted and I need a pair summing to a target, so I will use two pointers." Naming it is the moment the interviewer relaxes.
- Code it. Talking while you type, not silently.
- Test and handle edge cases. Empty input, one element, all duplicates, the target not present.
Step three matters far more than people expect. Skipping straight to the optimal solution reads as memorisation. Deriving it from a brute force reads as thinking, and thinking is what is being scored.
Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.
The mess: studying by volume
The default study plan is a list. Work through the top 150, tick them off, feel productive. The problem is that a list has no structure, so your brain files each solution as an isolated fact. Two weeks later you remember that you solved "Course Schedule" but not that it was topological sort — and when "Alien Dictionary" appears, nothing connects.
Volume also hides your real weakness. Solving forty easy array problems while never touching a heap feels like progress and leaves a hole exactly where the interview will land.
The fix: study by pattern, in order of payoff
Take the patterns one at a time. For each one: learn the recognition signal, solve one easy problem, then three or four mediums, then write the template from memory on a blank page. Only move on when you can state the signal in one sentence without looking.
Order matters. Two pointers, sliding window, stacks, binary search, tree BFS and tree DFS cover more interview questions than the other nine combined and are the cheapest to learn. Do those first. Dynamic programming is the one people fear, and it is worth doing late — after the others have built your confidence, because half of DP is noticing an overlapping subproblem, and that is itself a recognition skill.
Track your practice by pattern rather than by count. "I have done 40 problems" tells you nothing. "I recognise sliding window instantly but I still cannot see topological sort" tells you exactly what to do tomorrow.
How to talk about this in an interview
You will occasionally be asked how you prepared. Have a thirty-second answer ready:
"I studied by pattern rather than by problem count. There are about fifteen recurring shapes — two pointers, sliding window, BFS and DFS, heaps, backtracking, dynamic programming and so on — and for each one I learned the signal in the problem statement that triggers it. So when I see a new problem, my first move is to work an example and figure out which shape it is, then derive the solution from the brute force. That way I am not relying on having seen this exact question before."
That answer does two things at once: it explains your method and it demonstrates the method, because it is structured, specific and honest about the limits of memorisation.
Where system design fits
Patterns get you through the coding rounds. They do not get you through the loop. At mid-level and above, a system design round is usually the one that decides the offer, and it rewards a completely different skill — reasoning about scale, trade-offs and failure rather than about complexity classes.
The overlap is smaller than people assume, so treat it as separate preparation. Start with the complete system design interview preparation guide, then the step-by-step interview framework. If you want a coding problem that bridges both worlds, designing a coding contest platform is the natural one.
Key Takeaways
- Roughly fifteen patterns cover the large majority of coding interview questions; problem count is a vanity metric.
- Learn each pattern paired with its recognition signal, not just its implementation — recognition is the transferable skill.
- Always state the brute force and why it times out before giving the optimal solution. Deriving beats reciting.
- Do two pointers, sliding window, stacks, binary search and the two tree traversals first; leave dynamic programming for later.
- Coding patterns and system design are separate skills. Prepare for both, separately.
Next Steps
The next article takes the single highest-payoff pattern and goes deep: the sliding window, why the naive version is O(n²), how to know whether the window should be fixed or dynamic, and the four problems that teach the whole pattern. If you are preparing for a specific company, the Google coding interview preparation guide covers how Google's problem set and scoring rubric differ from everyone else's. Both patterns courses — the Amazon 15-pattern course and the Google 50-problem course — are in production, with their full curricula published now.