Every few days on LastRound AI's live copilot, the same stall shows up. A candidate names the correct data structure inside ten seconds, then burns the next several minutes rebuilding two-pointer logic from memory of a different problem, because they memorized code instead of learning the shape underneath it. That's the whole argument for coding interview patterns over problem-grinding: a new LeetCode-style question is almost never actually new, it's one of about fifteen recurring shapes wearing a different costume.
Most candidates already sense this. Fewer can name the fifteen, and even fewer can spot which one a problem is hiding behind on the first read. This post is the list of coding interview patterns, the tell that gives each one away, and the handful that still trip up strong engineers even after they've grinded 300 problems.
None of the fifteen are secret. Every major prep course teaches some version of this list. What's harder to find is a straight answer to the actual question candidates have: given a fresh problem I've never seen, how do I decide which pattern applies in the first thirty seconds, before the clock starts working against me. That's what the sections after the table are for.
Why coding interview patterns matter more than the problem count
Coding interviews are stress tests dressed up as skill tests. A 2020 study out of NC State and Microsoft Research, run as a randomized controlled trial with 48 computer science students and published at ACM's ESEC/FSE conference, found that being watched while coding measurably hurt performance compared to solving the identical problems in private, per Behroozi et al.'s "Does Stress Impact Technical Interview Performance?" The candidates who held up best under observation weren't the ones who'd seen more problems before. They were the ones who could reconstruct a solution shape fast once the pressure hit.
That's the case for patterns over raw volume. If you've internalized "sorted array plus target sum, reach for two pointers" as a reflex, you don't need to have seen that exact problem before. You need to recognize the shape under stress, which is a much smaller and much more learnable skill than memorizing hundreds of solutions. Ashish Pratap Singh, who writes the AlgoMaster newsletter, made almost the same point in a widely read 2024 post: interview prep is "less about the number of problems you have solved and more about how many patterns you know," and he counted roughly the same fifteen shapes we're using here, per his July 2024 breakdown.
There's a reason course marketing loves round numbers like "solve 150 problems and you're ready." It's an easier thing to sell than "learn to notice fifteen shapes and get fast at recognizing them," even though the second one is closer to what the interview actually measures. My guess is most candidates over-invest in volume and under-invest in recognition speed by a wide margin, though I don't have a clean way to prove the exact ratio, just years of watching people prep the wrong half of the problem.
The 15 coding interview patterns, at a glance
Skim the table once. Then read the two sections after it, because five of these fifteen don't reduce cleanly to a one-line tell and that's exactly where interviews go sideways.
| Pattern | The tell | Example problem |
|---|---|---|
| Sliding window | Contiguous subarray or substring, "longest/shortest/max sum of a window" | Longest Substring Without Repeating Characters |
| Two pointers | Sorted array, looking for a pair or triplet that hits a target | Two Sum II (Input Array Is Sorted) |
| Fast & slow pointers | Linked list, "does it cycle" or "find the middle node" | Linked List Cycle II |
| Merge intervals | A list of ranges that overlap, need merging, or need inserting | Merge Intervals |
| Cyclic sort | Array of numbers from 1 to n, asked to find a missing or duplicate value | Find the Duplicate Number |
| In-place linked-list reversal | Reverse a list, or part of one, without extra memory | Reverse Nodes in k-Group |
| Tree BFS | Level-order traversal, "shortest path," or "process level by level" | Binary Tree Level Order Traversal |
| Tree DFS | Root-to-leaf paths, subtree sums, or tree depth/height | Path Sum II |
| Two heaps | Running median, or splitting a stream into a smaller and larger half | Find Median from Data Stream |
| Subsets | "All combinations," "all permutations," or "all subsets" of a set | Subsets II |
| Modified binary search | Sorted or rotated array, asked to find something in O(log n) | Search in Rotated Sorted Array |
| Top-K elements | "K largest," "K most frequent," or "K closest" items | Kth Largest Element in an Array |
| K-way merge | Merge several already-sorted lists or arrays into one | Merge k Sorted Lists |
| Topological sort | Dependencies, prerequisites, or "valid order" on a directed graph | Course Schedule |
| Backtracking / dynamic programming | Explore every choice, then check whether the same sub-choice repeats | Word Break |
How do you know which pattern to reach for?
Read the input shape first, not the story wrapped around it. A sorted array almost always points to two pointers or modified binary search. A stream of numbers with a running statistic points to two heaps. A grid or a graph points to BFS or DFS. Decode the shape underneath the shipping-crate or inventory-system flavor text a company likes to dress a problem in, and the pattern usually falls out inside the first minute, before you've written a line of code.
Most lists of coding interview patterns stop at naming the fifteen and leave the actual recognition step as an exercise for the reader, which is backwards, because recognition is the hard part and the code for most of these patterns is fifteen to twenty lines once you know which one applies. A rough decision order that works for most problems: check if the input is sorted, check if it's a linked list or tree, check if you need all combinations of something, and only then start thinking about the specific pattern.
Sliding window is the pattern most people recognize fastest once they've seen it, and it's a good one to hold as a mental template, because most window problems follow the same skeleton: expand the right edge, check a condition, shrink the left edge when the condition breaks.
def longest_unique_substring(s):
seen = {}
left = 0
best = 0
for right, ch in enumerate(s):
if ch in seen and seen[ch] >= left:
left = seen[ch] + 1
seen[ch] = right
best = max(best, right - left + 1)
return bestTwo pointers and fast-and-slow pointers borrow the same "keep two positions and move them at different rates" idea, just on different data. Once you've written the window template above by hand a couple of times, the other pointer-based patterns stop feeling like separate topics.
The five patterns that don't reduce to a one-liner
Ten of the fifteen coding interview patterns above are close to mechanical once you spot the tell. Five aren't, and they're where candidates with otherwise strong fundamentals lose time.
Modified binary search
This is the one people think they know and don't. Standard binary search on a sorted array is muscle memory for most candidates by the time they're interviewing. The modification, on a rotated array, an unknown-length array, or a matrix, requires figuring out which half is still sorted before you decide where to move your pointers, and that one extra check is where a clean O(log n) solution turns into a buggy O(n) fallback under pressure.
Two heaps
This one confuses people because the "aha" isn't the heap itself, it's the balancing invariant: keep a max-heap for the smaller half of the data and a min-heap for the larger half, and rebalance so their sizes never differ by more than one. Miss that invariant and you'll reach for a single sorted structure instead, which works but blows your time complexity.
Cyclic sort
This is the one I'd cut first if I had to trim this list to ten. It solves a narrow band of "array holds values 1 through n" problems and, in what we've seen across candidates prepping on LastRound AI, it shows up in a real interview far less often than courses treat it. I might be wrong about how rare it actually is at companies we haven't sat in on. But treat it as a nice-to-know, not a must-drill, if your prep time is limited.
Topological sort
This one gets missed for a different reason. Candidates recognize "dependencies" as a graph problem but jump straight to DFS or BFS without noticing the graph is directed and acyclic, which is the one detail that makes ordering even possible. Ask yourself whether the graph can have a cycle, and if it can, whether a valid answer even exists, before picking BFS-based Kahn's algorithm or DFS-based ordering.
K-way merge
This one trips people up on the data structure choice, not the concept. Everyone knows to merge sorted lists two at a time. Fewer default to a min-heap holding one element from each list, which turns an O(nk) approach into O(n log k) with barely more code.
Where backtracking turns into dynamic programming
Of all the coding interview patterns here, this is the single spot where we watch strong candidates lose the most time on LastRound AI's live copilot. They correctly spot a backtracking shape, try a choice, recurse, undo it, but don't notice the recursion tree has overlapping subproblems until they've already written the brute-force version and the interviewer is now asking about time complexity they can't fix with the minutes left.
The fix isn't memorizing more DP problems. It's asking one extra question before writing any code: does this recursive call ever get made with the same arguments twice? If yes, memoize it and you've turned backtracking into dynamic programming. If the sub-problems never repeat, backtracking was the right answer all along, and forcing a DP table on top of it just wastes the clock.
The part problem-grinding doesn't teach
Solving 300 LeetCode problems teaches you syntax and builds real muscle memory for the mechanical parts: writing a correct binary search without an off-by-one bug, or getting heap operations right on the first try. It doesn't teach you to spot "sorted array, need a pair" inside the first thirty seconds of reading a problem you've never seen dressed up in a company's flavor text. That recognition gap between knowing the fifteen coding interview patterns and applying the right one fast is exactly what a copilot is built to close.
LastRound AI's AI interview copilot listens to the problem as it's read out loud and surfaces the likely pattern in under 200 milliseconds, so you're deciding on an approach instead of staring at a whiteboard trying to remember which of the fifteen coding interview patterns this even is. It runs quietly in the background during a live call, which matters more than it sounds like it should. The moment of freezing usually isn't a knowledge gap. It's a working-memory gap under time pressure, and that's a different problem to solve than "read more solutions."
If you want the underlying data structures first, our data structures interview questions guide covers arrays through graphs with sample answers. For the pattern that trips up the most senior candidates specifically, we go deeper in dynamic programming interview questions, including where it splits from plain backtracking. And if Amazon is on your list, its SDE loop leans on roughly ten of these fifteen patterns across the online assessment and onsite rounds, which we break down problem by problem in our Amazon SDE-2 interview questions guide. And if you're still working on getting enough of these interviews lined up in the first place, a sharper resume and a steady auto-apply pipeline solve a different, earlier problem than pattern recognition does, but they're usually the bottleneck before this one is.
Fifteen patterns, one clock, and the only real skill being tested is how fast you can match the two. Learn the shapes these coding interview patterns share, not the stories a job description dresses them up in.