Coding Interview Questions: the patterns that solve most of them
Search for coding interview questions and you drown in tagged problem lists — hundreds of them, sorted by company and difficulty, with no indication of where to start. The candidates who pass do not grind all of them. They learn the two or three dozen patterns underneath, because almost every interview question is one of those patterns wearing a different story. Master the patterns and an unfamiliar problem stops being a blank wall: you read it, recognise the shape, and the approach is already in your hands.
This guide is the map. It covers the coding interview patterns that account for the overwhelming majority of questions, the one-line tell that lets you recognise each one from the problem statement, a cheat sheet from statement to pattern, and the order to learn them so each builds on the last. It ends where every honest guide ends — on the fact that naming a pattern is only half the round; the other half is defending your solution out loud when the interviewer changes the constraints.
Why patterns beat problem count
The reason "just do 500 LeetCode problems" fails is that it trains recognition of specific problems, not the technique behind them — so a twist you have not seen resets you to zero. Patterns invert that. The list is finite and learnable: roughly a couple of dozen patterns cover the field, and about 80% of interview problems fall to just six — two pointers, sliding window, hash maps, binary search, BFS/DFS, and dynamic programming. Learn the pattern and you get the whole family of problems it solves, including the ones you have never seen.
The skill the interview actually rewards, then, is pattern recognition: read the problem, name the pattern, recall the template, adapt. That is a far smaller thing to learn than five hundred solutions, and it transfers.
The patterns that cover most questions
Here are the core patterns with the tell that gives each one away. "Leetcode patterns" and "coding interview patterns" are two names for exactly this set.
| Pattern | The tell | Example |
|---|---|---|
| Sliding Window | "longest/shortest/count" contiguous subarray or substring under a constraint | Longest Substring Without Repeating Characters |
| Two Pointers | sorted array + pair/triplet target, or in-place without extra space | 3Sum, Squares of a Sorted Array |
| Fast & Slow Pointers | linked list + cycle / middle / palindrome | Linked List Cycle, Middle of the List |
| Merge Intervals | overlapping intervals; merge / insert / can-attend-all | Merge Intervals |
| Cyclic Sort | numbers in range 1..n; find the missing / duplicate | Find the Missing Number |
| Prefix Sum | repeated range-sum queries; subarray sum equals k | Subarray Sum Equals K |
| Hash Map | O(1) lookup; unsorted pair-sum; frequency counts | Two Sum, Group Anagrams |
| Tree BFS | tree + level / view / zigzag / minimum depth | Binary Tree Level Order Traversal |
| Tree DFS | tree + path / sum / depth / ancestor | Path Sum, Lowest Common Ancestor |
| Graph BFS/DFS | grid of cells spreading or connecting | Number of Islands |
| Topological Sort | ordering with dependencies; "valid order / is there a cycle" | Course Schedule |
| Top-K Elements (Heap) | "k largest / smallest / most frequent" | Top K Frequent Elements |
| Modified Binary Search | sorted or rotated + find / boundary in O(log n) | Search in Rotated Sorted Array |
| Backtracking | "all possible / generate every"; tiny n (≤ ~20) | Subsets, Permutations, N-Queens |
| Dynamic Programming | overlapping subproblems; max/min/count where greedy fails | Coin Change, Edit Distance |
The recognition cheat sheet
Most of the battle is the first thirty seconds — matching the words in the prompt to a pattern. Keep this mapping automatic:
| When the problem says… | Suspect… |
|---|---|
| "longest / shortest contiguous subarray or substring with…" | Sliding Window |
| sorted array + "pair / triplet summing to…" | Two Pointers |
| "remove in place / without extra space" | Two Pointers |
| linked list + "cycle / middle / palindrome" | Fast & Slow Pointers |
| tree + "path / sum / depth / ancestor" | Tree DFS |
| tree + "level / view / zigzag" | Tree BFS |
| grid of cells spreading / connecting | Graph BFS/DFS |
| "all possible / generate every" | Backtracking |
| "k largest / smallest / most frequent" | Top-K Heap |
| sorted or rotated + "find / boundary in log n" | Modified Binary Search |
When you can say, within seconds, "two strings and we're comparing them, so this is the LCS family", you have turned a scary open problem into a known template.
The order to learn them
Patterns build on each other, so learn them in an order where each reuses the last:
- Arrays and strings — two pointers, sliding window, hash maps, prefix sum. The foundation and the highest-frequency patterns.
- Linked lists — fast and slow pointers, in-place reversal.
- Trees — DFS first (paths, sums), then BFS (levels).
- Graphs — BFS/DFS on grids and graphs, then topological sort.
- Heaps and intervals — top-K, two heaps, merge intervals.
- Backtracking — subsets, combinations, permutations.
- Dynamic programming — last, because it reuses recursion and the subproblem thinking from everything before it.
Do four to six problems per pattern in rising difficulty, and once a few patterns are solid, interleave them — mix patterns in one session so you practise choosing the pattern, which is what the interview tests, not just applying one you were told to use.
Coding
Company-agnostic · Onsite coding · 45 min
Name the pattern and solve it out loud, with follow-ups
From naming the pattern to defending it out loud
Recognising the pattern starts the round; it does not finish it. Once you have the template, the interviewer's job is to push: "that's O(n log n) — can you do better?", "now the array doesn't fit in memory, what changes?", "why a heap and not a sort here?". Those follow-ups are where offers are decided, and they are exactly what a pattern list cannot rehearse, because they demand you justify the pattern and adapt it live.
That maps to the four dimensions a scored round grades — problem solving (naming the right pattern and reaching an optimal solution), communication (narrating why the pattern fits), technical execution (clean, correct code), and time management (solving inside the window with room for the follow-up). Knowing the patterns gets you to a solution; defending it out loud gets you the hire.
How to practise the patterns
- Learn the tell before the template. For each pattern, be able to state in one sentence how you recognise it from a problem.
- Drill a few problems per pattern, not dozens — enough to make the template automatic.
- Interleave once the basics are solid. Mixed, unlabelled practice trains pattern selection, the real skill.
- State complexity every time. Say the time and space cost the moment your solution works.
- Finish with out-loud mocks. Timed rounds where someone changes the constraint are where recognition becomes performance.
If you want raw volume to make the templates automatic first, the sister platform PipeCode is built for structured problem reps across exactly these patterns; use it to drill, then come back here to rehearse naming and defending them out loud.
Coding
Company-agnostic · Phone screen · 45 min
Rehearse pattern recognition on the clock, out loud
Frequently asked questions
What are coding interview patterns?
They are reusable problem-solving templates — sliding window, two pointers, tree BFS, backtracking, dynamic programming and so on — that each solve a whole family of problems rather than one. Instead of memorising individual solutions, you learn the pattern and the "tell" that signals it, then apply the template to any problem in that family. Because the set of patterns is finite and small relative to the number of possible problems, learning them is far more efficient and transfers to questions you have never seen.
How many patterns do I need to know?
Fewer than you fear. Roughly two dozen patterns cover the field, and about 80% of interview problems fall to just six: two pointers, sliding window, hash maps, binary search, BFS/DFS, and dynamic programming. If you learn those six deeply and add trees, heaps, intervals, topological sort and backtracking, you are ready for the vast majority of coding rounds. The goal is depth on a finite list, not coverage of an infinite one.
Are "leetcode patterns" and "coding interview patterns" the same?
Yes — they are two names for the same set of techniques. "LeetCode patterns" references the platform most people practise on; "coding interview patterns" is the generic term. Nothing about the actual techniques changes depending on which phrase you searched. The sliding window is the sliding window whether you call it a LeetCode pattern or a coding interview pattern.
In what order should I learn the patterns?
Start with array and string patterns (two pointers, sliding window, hash maps, prefix sum) because they are the highest-frequency and the foundation. Then linked lists (fast and slow pointers, in-place reversal), then trees (DFS, then BFS), then graphs (BFS/DFS, topological sort), then heaps and intervals, then backtracking, and finally dynamic programming — which reuses the recursion and subproblem thinking from everything before it. Each stage builds on the last, so the order matters.
How many problems should I solve per pattern?
About four to six per pattern, in rising difficulty — enough to make the template automatic without over-drilling one shape. Quality beats quantity: solving six problems and being able to state the tell in your own words beats rushing through thirty. Once several patterns are solid, spend your remaining time on interleaved, mixed practice, because the interview tests whether you can pick the right pattern, not just apply one on command.
How do I practise coding patterns out loud?
Recognising a pattern silently is not the same as defending your solution while an interviewer changes the constraints. On Zynter, the Coding track runs live voice rounds modelled on real company loops — you write code that runs in a real editor, name and justify your pattern to a voice interviewer that asks "can you do better?" and "what changes at scale?", and get a debrief on problem solving, communication, technical execution and time management. You get genuine mock-coding-interview feedback on demand, and the score is a practice signal, not a hiring decision.
Practise it on Zynter
You can recognise every pattern. The round is won defending the one you picked, out loud.
Pick a coding round, name the pattern, write the solution in a real editor, and defend it to a voice interviewer that keeps asking "can you do better?" and "what changes at scale?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies (Sep 2026) — about $8–$12 for a full 60-minute mock, and two free credits to start.
Top comments (0)