Here’s something I find genuinely useful to say out loud: there are roughly 15 patterns that cover most of what you’ll see in a coding interview. Not 150. Not “thousands of problems.” Fifteen patterns, applied in different combinations.
The Stack Overflow Developer Survey 2024 found that 62% of developers actively preparing for jobs said algorithmic problem-solving was their biggest source of anxiety. My guess is that number is high partly because of how most people prepare: they grind solutions instead of learning to recognize what kind of problem they’re looking at. This cheat sheet is about the second thing.
The recognition problem
The hard part of a coding interview isn’t usually the implementation. It’s the first 90 seconds: what am I even looking at here? If you can identify the pattern, the implementation tends to follow. If you can’t, you end up flailing at a whiteboard hoping your fingers remember something your brain doesn’t.
So here’s the framing I’d suggest: for each pattern below, focus on the “when does this apply” column more than the code itself. That’s the muscle you actually need.
The 15 patterns, with honest notes on each
Two Pointers. Use this when you have a sorted array and you’re looking for pairs or need to compare elements from both ends. Classic tells: “find two numbers that sum to X” or “remove duplicates in place.” Fast to implement once you see it.
Sliding Window. Subarray problems. Substring problems. Any time “contiguous sequence” appears in the problem. The window expands and contracts; you track a running value instead of recomputing. Good practice: Longest Substring Without Repeating Characters (LeetCode 3).
Fast and Slow Pointers (Floyd’s). Cycle detection. If someone asks whether a linked list has a cycle, or asks you to find the middle element in one pass, this is it. The slow pointer moves one step, the fast pointer moves two. They meet if there’s a cycle.
Merge Intervals. Any problem involving overlapping ranges. Interview scheduling. Calendar conflicts. Sort by start time, then check if the current interval overlaps the last merged one. Straightforward once the pattern clicks.
Binary Search. Not just “is this value in the sorted array.” Binary search applies to any monotonic function. “Find the minimum in a rotated sorted array” is binary search. “Find the smallest X such that condition holds” is binary search. I think people underuse this pattern because they associate it only with the textbook case.
BFS (Breadth-First Search). Shortest path in an unweighted graph. Level-order traversal. “Minimum number of steps” problems. BFS guarantees you find the shortest path first. DFS doesn’t.
DFS (Depth-First Search). Exploring all possibilities. Path existence. Tree traversals. Any problem where you need to visit every node or try every combination before backtracking.
Backtracking. Subset generation, permutations, combinations, constraint satisfaction. The pattern: try an option, recurse, undo the option. N-Queens is the textbook example but you’ll see it in “generate all valid parentheses” and similar problems. (Side note: backtracking problems look scarier than they are. Once you write the template once, it’s mostly filling in the pruning condition.)
Dynamic Programming. Overlapping subproblems, optimal substructure. The honest truth about DP is that it covers a huge range of problems and doesn’t have one clean template. What does have a template is the approach: define the state, write the recurrence, decide top-down or bottom-up. Coin change and longest common subsequence are the two I’d practice first.
Topological Sort. Dependency ordering. Build systems. Course prerequisites. Whenever you have a directed acyclic graph and need to order nodes so that all dependencies come first. Kahn’s algorithm (BFS-based) is easier to implement in an interview than DFS-based toposort.
Heap / Priority Queue. “K largest elements,” “merge K sorted lists,” “find the median of a data stream.” If the problem involves repeatedly pulling the smallest or largest element from a changing set, reach for a heap.
Union Find (Disjoint Sets). Connected components. Network connectivity. “Are these two nodes in the same group?” Union Find answers that question in near-constant time after initialization. It comes up less often than heaps or DP, but when it does come up, you want to recognize it quickly.
Trie. Prefix matching. Autocomplete. “Does any word start with this prefix.” A trie is a tree where each node is a character. You’ll see this mostly in string problems where suffix/prefix operations repeat across many queries.
Monotonic Stack. “Next greater element,” “daily temperatures,” problems involving “the next X that is bigger/smaller.” The stack maintains a decreasing (or increasing) sequence. When you push an element that breaks the monotonicity, you process whatever gets popped.
Bit Manipulation. XOR for finding unpaired elements. Bit shifting for fast multiplication/division by powers of two. Checking whether a number is a power of two (n & (n-1) == 0). These problems show up occasionally. They’re not the majority, but they reward having seen them before.
Quick recognition table
| If the problem says… | Think about… |
|---|---|
| sorted array, pairs, duplicates | Two Pointers |
| contiguous subarray, substring | Sliding Window |
| linked list cycle, middle element | Fast & Slow Pointers |
| overlapping intervals, calendar | Merge Intervals |
| find minimum X such that condition | Binary Search |
| shortest path, minimum steps | BFS |
| all paths, permutations, subsets | DFS / Backtracking |
| dependencies, prerequisites | Topological Sort |
| K largest / smallest, median | Heap |
| connected components, groups | Union Find |
| prefix search, autocomplete | Trie |
| next greater/smaller element | Monotonic Stack |
| find unique, XOR tricks | Bit Manipulation |
| repeated subproblems, optimal | Dynamic Programming |
How to actually use this
Print it out (or keep it open in another tab) while you practice. Before you look at a solution, write down which pattern you think applies and why. Getting this wrong isn’t a problem. Getting it wrong and then seeing the right answer teaches you more than solving problems where you already know the approach.
Three to five problems per pattern is enough for most people preparing for mid-level roles. More for senior positions where the problems get combined (sliding window plus heap, for example). I wouldn’t try to grind all 15 in a week; pick the five or six you’re weakest on and focus there.
If you’re doing mock interviews, having someone (or an AI interview tool) give you hints framed around pattern names rather than solutions is a much more effective way to practice than just reading the editorial. You want to build the recognition reflex, not the solution memory.
One last thing: this list doesn’t cover system design. That’s a separate skill entirely.