Most coding interview problems are variations of a small set of patterns. Learn to recognize the structural signal that triggers each one, and you stop memorizing 500 problems and start solving the ones you have never seen.
This is an open guide to the 15 LeetCode patterns behind most coding interview problems: the trigger that fires each one, a template, a worked step-by-step trace, the classic problems, the complexity, and the mistakes that cost people the interview. Everything here is free markdown, MIT licensed, and reads on its own.
Want them on one page? The LeetCode patterns cheat sheet puts all 15 signals side by side.
Start here. These cover the bulk of medium problems.
| Pattern | Trigger (structural signal) | Classic problems | Doc |
|---|---|---|---|
| Sliding Window | Contiguous subarray/substring + "longest/shortest/at most K" | Longest Substring Without Repeat (LC 3), Min Window Substring (LC 76) | → |
| Two Pointers | Sorted input, or pairs from both ends, or in-place partition | Two Sum II (LC 167), 3Sum (LC 15), Container With Most Water (LC 11) | → |
| Binary Search | Sorted array, or a monotonic answer space ("minimum X that works") | Search Insert (LC 35), Koko Eating Bananas (LC 875) | → |
| BFS | Shortest path in unweighted graph/grid, or level-order | Number of Islands (LC 200), Rotting Oranges (LC 994) | → |
| DFS | Visit everything reachable: components, paths, cycle detection | Number of Islands (LC 200), Clone Graph (LC 133) | → |
| Dynamic Programming | Overlapping subproblems + optimal substructure ("count ways", "min cost") | Climbing Stairs (LC 70), Coin Change (LC 322), House Robber (LC 198) | → |
| Dijkstra | Shortest path in a weighted graph, non-negative weights | Network Delay Time (LC 743), Cheapest Flights (LC 787) | → |
Each one owns a specific family of problems. When a problem resists the core 7, it is usually one of these.
| Pattern | Trigger (structural signal) | Classic problems | Doc |
|---|---|---|---|
| Backtracking | Generate all subsets, permutations or combinations; choose, explore, undo | Subsets (LC 78), Permutations (LC 46), N-Queens (LC 51) | → |
| Monotonic Stack | Next greater or smaller element, spans bounded by the nearest taller bar | Daily Temperatures (LC 739), Largest Rectangle in Histogram (LC 84) | → |
| Fast & Slow Pointers | Cycle or middle node in a linked list or sequence, O(1) space | Linked List Cycle (LC 141), Find the Duplicate Number (LC 287) | → |
| Prefix Sum | Repeated range sums, or count subarrays that sum to K | Subarray Sum Equals K (LC 560), Range Sum Query (LC 303) | → |
| Heap / Top K | k largest, kth largest, k most frequent, running median | Kth Largest Element (LC 215), Top K Frequent Elements (LC 347) | → |
| Merge Intervals | Ranges that may overlap: merge, insert, count active at once | Merge Intervals (LC 56), Meeting Rooms II (LC 253) | → |
| In-place Linked List Reversal | Reverse a list, or part of it, without new nodes | Reverse Linked List (LC 206), Reverse Nodes in k-Group (LC 25) | → |
| Topological Sort | Tasks with dependencies: find a valid order or prove a cycle | Course Schedule (LC 207), Alien Dictionary (LC 269) | → |
More:
- Decision framework — the questions to ask an unfamiliar problem to find its pattern
- Combining patterns — how the hard problems stack two patterns together
- Complexity cheatsheet — time and space by pattern
Reading a finished solution tells you what the code does. It does not show you how the algorithm moves. You see the two pointers in the final code, but not the moment the right pointer stops and the left one starts catching up. You see the DP array, but not the order the cells fill in.
That gap, between reading code and understanding execution, is why 150 solved problems still end in a freeze during the interview. You memorized outcomes, not mechanics.
The way to close it is to learn each pattern by its structural trigger and trace it step by step until the mechanic is obvious. That is what makes a pattern recognizable the next time, on a problem you have never seen. Each doc here walks one pattern through a worked trace with exactly that goal.
- Start with the decision framework — learn to read a problem for its trigger before you touch code.
- Work through the core 7, then the 8 more. For each, read the trigger, then follow the worked example until the mechanic is clear.
- Use the complexity cheatsheet to sanity-check your solutions.
- When problems start feeling like combinations, read combining patterns.
The goal is not to finish this repo. It is to reach the point where a new problem announces its own pattern.
Built by the team behind Expora, a visual algorithm debugger for coding interviews (early access).