TL;DR: Nearly every LeetCode problem is generated from a small set of reusable patterns, and each pattern has a tell: specific words and structures in the problem statement that give it away. This guide covers the 14 patterns that matter most, the tell for each one, a keyword-to-pattern lookup table, and a training method (block practice, tells, diagnosis drills, spaced review) that turns pattern knowledge into the recognition skill interviews actually test.
There are two kinds of people solving LeetCode problems at this moment.
The first kind opens a random problem, stares at it, tries something, gets stuck, reads the solution, nods, and moves on. Their problem counter goes up every day. Their skill doesn't. I call this grinding, and it's how most people prepare, because it feels like work and the counter provides the illusion of progress.
The second kind reads a problem and asks one question before anything else: "Which pattern is this?" They notice the phrase "longest substring" and think sliding window. They see "all possible combinations" and think backtracking. They see a sorted array and a target and think two pointers or binary search before they've consciously decided anything. For them, a new problem isn't a blank page; it's a recognition task.
I interviewed hundreds of candidates at Meta and Microsoft, and I can tell you the second kind of candidate is unmistakable within minutes. This article is the complete guide to becoming one: every major pattern, the tell that identifies it, and the training method that installs recognition. It's long, deliberately, because it's meant to be the reference you come back to. Bookmark it.
What a pattern actually is
A pattern is not a topic ("arrays") and not an algorithm ("quicksort"). A pattern is three things bundled together:
- A template: a reusable code skeleton that solves a whole family of problems with small modifications.
- A tell: the features of a problem statement that signal the family membership.
- A range of variations: the standard ways interviewers disguise the family (change the data type, invert min to max, add a constraint).
Grinders collect solutions. Pattern learners collect templates, tells, and variations. The difference matters because interviews are built from variations: your interviewer took a known problem and changed a constraint, precisely to check whether you learned the pattern or memorized the instance. If you know the template and recognized the tell, the variation is a small edit. If you memorized the instance, the variation is a brand-new problem and your preparation evaporates in front of the person grading you. (For the cognitive science of why recognition beats calculation, see Why Is LeetCode So Hard?)
How to read a problem statement like a diagnostician
Before we tour the patterns, here's the reading procedure that recognition runs on. When you open any problem, extract three signals before thinking about solutions:
Signal 1: the input shape. Array or string? Is it sorted? A linked list? A tree? A graph or a grid? Intervals? A stream? Input shape alone eliminates most patterns: a linked list points toward fast and slow pointers or in-place reversal; a grid points toward BFS/DFS; intervals point toward merge intervals.
Signal 2: the ask. What does the answer look like? A longest/shortest something suggests sliding window or DP. A "k largest/closest/most frequent" is a heap tell. "All possible X" is backtracking. "Minimum number of steps" on an unweighted structure is BFS. A yes/no about feasibility with an ordering flavor is often topological sort or greedy.
Signal 3: the constraints. Constraints are the most underrated hint on LeetCode. An input size of 10^5 rules out O(n²) and pushes you toward linear patterns (sliding window, two pointers, monotonic stack, heap). An input size of 20 or less practically announces backtracking or bitmask DP, because exponential is affordable. A required O(log n) means binary search, full stop. And "numbers are in the range 1 to n" is the classic cyclic sort giveaway.
Three signals, cross-referenced, usually leave one or two candidate patterns standing. That's the whole diagnostic skill, and every pattern section below is organized to feed it.
The field guide: 14 patterns and their tells
These are the highest-frequency patterns in real interviews. For each: what it is, the tell, and representative problems to learn it from.
1. Sliding Window
What it is: maintain a contiguous window over an array or string, growing it from the right and shrinking it from the left when a constraint breaks, tracking the best window seen.
The tell: the words contiguous subarray or substring, combined with longest, shortest, maximum, minimum, or count, under some constraint ("without repeating characters", "at most k distinct", "sum at least s").
Learn it from: Longest Substring Without Repeating Characters, Minimum Size Subarray Sum, Max Consecutive Ones III.
Watch for: fixed-size windows (easier: slide both ends together) versus variable-size windows (the real pattern). Nearly all interview versions are variable-size.
2. Two Pointers
What it is: two indices walking through a sequence, usually from both ends inward or in the same direction at different speeds, exploiting sorted order to skip work.
The tell: a sorted array plus a pair/triplet target ("two numbers that sum to X", "three numbers closest to zero"), or an in-place requirement ("remove duplicates without extra space").
Learn it from: Pair with Target Sum, 3Sum, Squares of a Sorted Array, Dutch National Flag.
Watch for: if the array isn't sorted and can't be sorted (indices must be preserved), the hash map version usually replaces this pattern.
3. Fast & Slow Pointers
What it is: two pointers moving at different speeds through a linked structure; if there's a cycle they meet, and the meeting point carries information.
The tell: a linked list plus the words cycle, loop, middle, or happy number-style problems where a sequence of transformations might repeat forever.
Learn it from: LinkedList Cycle, Middle of the LinkedList, Happy Number, Palindrome LinkedList.
Watch for: this pattern's superpower is O(1) space. If a linked list problem seems to need a hash set of visited nodes, fast and slow pointers is usually the intended answer.
4. Merge Intervals
What it is: sort intervals by start, then sweep once, merging or counting overlaps.
The tell: the input is intervals: meetings, ranges, bookings, timelines. Any mention of overlapping, conflicting, or free time.
Learn it from: Merge Intervals, Insert Interval, Meeting Rooms II.
Watch for: the "minimum rooms/platforms" variant, which upgrades the pattern with a min-heap of end times. It's the single most common interval question in real loops.
5. Cyclic Sort
What it is: when an array contains numbers in a known range (1 to n), each number's value tells you its correct index, so you can sort by swapping in O(n) and then scan for anomalies.
The tell: "array containing numbers from 1 to n" plus find the missing / duplicate / corrupt number. That range phrase is one of the most reliable tells on this list.
Learn it from: Find the Missing Number, Find All Duplicates, Find the Corrupt Pair.
Watch for: interviewers add "without extra space and in O(n)", which eliminates the hash set and sorting escapes and forces this exact pattern.
6. Monotonic Stack
What it is: a stack that maintains increasing or decreasing order; when a new element violates the order, popping resolves "next greater/smaller" relationships in O(n) total.
The tell: next greater element, previous smaller element, days until warmer, largest rectangle, or any question about how far an element "sees" in one direction.
Learn it from: Daily Temperatures, Next Greater Element, Largest Rectangle in Histogram.
Watch for: this pattern barely existed in interview circulation before ~2019 and is now common at every FAANG company. Older lists (including Blind 75) barely cover it; that gap loses offers.
7. Top-K Elements (Heap)
What it is: a heap of size k that maintains the k best elements seen so far, giving O(n log k) instead of full-sort O(n log n).
The tell: the literal letter K: k largest, k smallest, k most frequent, k closest. The most honest tell in interviewing.
Learn it from: Kth Largest Element, Top K Frequent Elements, K Closest Points to Origin.
Watch for: the counterintuitive part is using a min-heap to track the k largest (the heap's root is the weakest member, first to be evicted). Interviewers probe exactly this.
8. Two Heaps
What it is: a max-heap for the lower half of data and a min-heap for the upper half, giving O(1) access to the median of a growing dataset.
The tell: median of a stream or of a sliding window; more generally, needing the middle or balance point of data that changes over time.
Learn it from: Find the Median of a Number Stream, Sliding Window Median.
Watch for: the rebalancing invariant (heap sizes differ by at most one) is where solutions break; state it out loud in interviews before coding.
9. Modified Binary Search
What it is: binary search beyond "find x in a sorted array": on rotated arrays, on boundaries (first/last occurrence), and most importantly on the answer space itself.
The tell: sorted or rotated-sorted input; a demanded O(log n); or the sneaky version: "minimize the maximum" / "maximize the minimum" questions where you can check a candidate answer quickly. If feasibility is monotonic ("if capacity 15 works, 16 works too"), binary search the answer.
Learn it from: Order-agnostic Binary Search, Search in Rotated Array, Koko Eating Bananas, Capacity to Ship Packages in D Days.
Watch for: answer-space binary search is the most disguised pattern on this list. We'll diagnose one live in a moment.
10. Tree DFS
What it is: recursive depth-first traversal where each call returns information the parent combines: path sums, depths, diameters, validity.
The tell: binary tree plus path (root-to-leaf or any-to-any), sum, depth, diameter, ancestor, or validating a structural property.
Learn it from: Path Sum, Diameter of Binary Tree, Validate Binary Search Tree, Lowest Common Ancestor.
Watch for: the recurring trick is distinguishing "value I return to my parent" from "value I update globally" (diameter and max path sum both hinge on it). Master that distinction once and a dozen problems fall.
11. Tree BFS
What it is: level-by-level traversal with a queue, processing one level per loop iteration.
The tell: the words level, layer, row, zigzag, level averages, or right/left view of a tree; also minimum depth, because BFS finds the nearest leaf without exploring the whole tree.
Learn it from: Level Order Traversal, Zigzag Traversal, Right View of a Binary Tree.
Watch for: the pattern is trivial once known, which is why it appears in screens: it separates people who've prepared from people who haven't, cheaply.
12. Graph Traversal (BFS/DFS) and Topological Sort
What it is: systematic exploration of graphs and grids: DFS for connectivity and component counting, BFS for shortest paths in unweighted graphs, topological sort for dependency ordering.
The tell: an explicit graph, or a grid that behaves like one (islands, walls, infection spreading). Shortest/fewest steps on unweighted structure means BFS, always. Prerequisites, dependencies, build order, course schedule means topological sort.
Learn it from: Number of Islands, Rotting Oranges, Clone Graph, Course Schedule, Word Ladder.
Watch for: multi-source BFS (start the queue with all sources, like all rotten oranges) converts several "hard-looking" problems into standard ones.
13. Subsets and Backtracking
What it is: systematic enumeration of all candidates by building partial solutions, recursing, and undoing (backtracking) when a branch dies.
The tell: all possible subsets, permutations, combinations; generate every valid configuration; puzzles with placement constraints (N-Queens, Sudoku). Tiny constraint sizes (n ≤ 20) confirm it.
Learn it from: Subsets, Permutations, Letter Combinations of a Phone Number, Palindromic Partitioning.
Watch for: duplicates in the input ("Subsets II", "Permutations II") introduce the skip-duplicates idiom, a favorite follow-up.
14. Dynamic Programming
What it is: solving a problem by combining answers to overlapping subproblems, usually as "at each step, choose or skip" (knapsack family), "match or don't" (string family), or "best ending here" (sequence family).
The tell: maximum/minimum result from a sequence of choices, or count the number of ways, where a greedy choice demonstrably fails and brute force is exponential. Words like profit, cost, ways, longest common, edit distance.
Learn it from: 0/1 Knapsack, Coin Change, Longest Common Subsequence, House Robber.
Watch for: DP is really a family of sub-patterns, and learning it as sub-patterns (knapsack, unbounded knapsack, LCS-shaped, palindrome-shaped, Fibonacci-shaped) is what makes it tractable. Treating "DP" as one monolithic topic is why people fear it.
A few patterns didn't make the detailed list but are worth knowing exist: in-place linked list reversal, K-way merge, bitwise XOR tricks, greedy with sorting, prefix sums with hash maps (subarray-sum-equals-k family), and union-find. The full curriculum in Grokking the Coding Interview covers 27 patterns end to end, each taught exactly this way: tell, template, variations, then practice problems grouped for recognition.
The cheat sheet: from problem statement to pattern
| When the problem says... | Suspect... |
|---|---|
| "longest/shortest substring or contiguous subarray with..." | Sliding Window |
| sorted array + "pair/triplet summing to..." | Two Pointers |
| "remove in place / without extra space" (array) | Two Pointers |
| linked list + "cycle / middle / palindrome" | Fast & Slow Pointers |
| input is meetings, ranges, timelines | Merge Intervals |
| "array contains numbers from 1 to n" + missing/duplicate | Cyclic Sort |
| "next greater / previous smaller / how many days until" | Monotonic Stack |
| "k largest / k closest / k most frequent" | Heap (Top-K) |
| "median of a stream / running median" | Two Heaps |
| sorted/rotated input, or O(log n) required | Modified Binary Search |
| "minimize the maximum / maximize the minimum" | Binary Search on the answer |
| tree + "path / sum / depth / ancestor" | Tree DFS |
| tree + "level / view / zigzag / minimum depth" | Tree BFS |
| grid of cells spreading/connecting | Graph BFS/DFS |
| "prerequisites / dependency order" | Topological Sort |
| "all possible / generate every" | Backtracking |
| "max profit / min cost / count the ways" + choices | Dynamic Programming |
| "find the single number where others repeat" | Bitwise XOR |
| "count subarrays with sum exactly k" (unsorted, negatives) | Prefix Sum + Hash Map |
Print it, but understand what it's for: the table is training wheels for the three-signal reading procedure, not a substitute for it. Interviewers know these keywords too, and the better ones paraphrase around them. The tell you should ultimately rely on is structural (what's the input shape, what's the ask, what do constraints allow), because structure can't be paraphrased away.
A diagnosis, live
Let's run the procedure on a problem that fools grinders reliably:
A conveyor belt has packages with weights [1,2,3,...,10]. Ships have a weight capacity, and packages must be shipped in order within D days. What is the least capacity that ships everything in D days?
Signal 1, input shape: a plain array of weights, not sorted by us (order must be preserved). Nothing listy, treey, or graphy.
Signal 2, the ask: "least capacity such that...", a minimize question. First instinct for many: DP or greedy over allocations.
Signal 3, constraints: array up to 5×10^4, weights up to 500. O(n²) DP over positions and days would be borderline; something better is wanted.
Now the key observation, and it's the tell from pattern #9: the answer itself lives in a range (max single weight up to total weight), and feasibility is monotonic: if capacity 15 ships everything in D days, capacity 16 certainly does. Monotonic feasibility plus a cheap feasibility check (one linear scan simulating the shipping) means: binary search on the answer. Guess a capacity, simulate, tighten the range. O(n log(sum)).
Notice what happened: no flash of genius, no trick pulled from nowhere. A reading procedure extracted three signals, one signal matched a stored tell, and the stored template did the rest. That is what "being good at LeetCode" actually is, mechanically. It's also why grinding fails: solving 400 problems without ever naming the monotonic-feasibility tell means problem #401 with a new story (Koko's bananas, splitting arrays, allocating pages) still looks brand new.
How to train recognition: the practice system
Knowing the patterns exist gets you 20% of the way. The other 80% is making recognition automatic under pressure, and that requires practicing differently from the default. Here's the system, four habits deep:
Habit 1: block practice first. Learn each new pattern by solving 4 to 6 of its problems consecutively. Yes, you know what pattern it is going in; that's fine. Blocks exist to install the template and its variations in memory, the raw material recognition will later retrieve. A curated, pattern-ordered list matters here, which is exactly what Grokking 75 provides if you want it pre-built.
Habit 2: write the tell in your own words. After each block, write one sentence: "Suspect this pattern when ___." Your own words, not copied. This single habit separates pattern learners from pattern tourists, because articulating the tell is what converts "I understand sliding window" into "I noticed this is sliding window." Keep the sentences in one place; that document becomes your personal cheat sheet, and rereading it before a mock takes five minutes.
Habit 3: diagnosis drills on mixed sets. Once you hold 6+ patterns, start mixed sessions with a twist: for each problem, diagnose before solving, out loud, with justification. "Contiguous subarray, longest, constraint on distinct count: sliding window, variable size." Then, and only then, code. Twice a week, do a pure diagnosis drill: read 10 problem statements and only diagnose, no coding, 2 minutes each. Ten reps of the exact skill interviews test, in 20 minutes. Grinders never do this because it doesn't increment the problem counter; do it anyway.
Habit 4: spaced re-solving of failures. Every problem you misdiagnosed or failed goes on a list, and you re-solve it from scratch a week later, then two weeks after that if needed. Misdiagnoses are the most valuable items you own: each one marks a tell that isn't installed yet. (How many total problems does this system need? Far fewer than grinding: the full breakdown by situation is in How Many LeetCode Problems Should You Actually Solve?, but 100 to 150 covers almost everyone.)
Expect a strange emotional arc. Weeks one and two feel slower than grinding: blocks feel repetitive, tells feel bureaucratic, diagnosis drills feel like homework. Around week four, mixed problems start feeling familiar before you've consciously analyzed them. That's recognition consolidating, and it's the moment prep stops feeling like memorizing an infinite book and starts feeling like a finite skill you're finishing.
When recognition isn't instant: composite problems and honest limits
Two caveats, because this guide would be dishonest without them.
Composite problems exist. Harder interview questions often stack two patterns: Top K Frequent Words is a hash map feeding a heap; Sliding Window Median is a window feeding two heaps; Word Ladder is BFS over an implicit graph you must construct first. When your diagnosis produces two candidates, the question isn't "which one" but "in what order": what structure do I build from the input, and what pattern consumes it? Practicing a few composites teaches you that stacking is normal, not a sign your diagnosis failed.
Sometimes nothing matches. A small fraction of problems (and a smaller fraction of real interview questions) hinge on a one-off insight or an algorithm outside the common patterns. When ten minutes of diagnosis produces nothing, say so honestly in an interview and start with brute force plus analysis; interviewers credit calibrated honesty and a working baseline far more than silence. And in practice, treat no-match problems as data: if they cluster (say, everything with strings and counting defeats you), that's a missing pattern to go install, not evidence that you're bad at this.
The takeaway
LeetCode stops being an infinite grind the day you change the unit of progress from problems solved to patterns recognized. Fourteen patterns cover the bulk of real interviews; each has a tell you can learn to notice in the first read of a problem; and a four-habit practice system (blocks, written tells, diagnosis drills, spaced failure review) makes the noticing automatic. The grinders will keep telling you their problem counts. Let them. You'll be the candidate who looks at a problem they've never seen and says "this looks like binary search on the answer, here's why," and from the other side of the table, I can tell you exactly how rare and how hireable that sentence is.
Learn every pattern the way this guide teaches them: Grokking the Coding Interview: Patterns for Coding Questions covers all 27 patterns with tells, templates, variations, and hundreds of practice problems grouped for recognition, in Python, Java, JavaScript, C++, C#, and Go. It's the original patterns course, rated 4.6/5 by 62,000+ learners.
FAQs
What are LeetCode patterns? Reusable problem-solving templates (like sliding window, two pointers, or tree BFS) that each solve a whole family of problems. Since interview questions are variations drawn from these families, learning the pattern plus its "tell" prepares you for problems you've never seen.
How many LeetCode patterns are there? About 14 patterns cover the large majority of real interview questions, and roughly 27 provide comprehensive coverage including specialized ones (K-way merge, union-find, bitwise XOR, the dynamic programming sub-families). You do not need hundreds; the entire point of patterns is that the list is finite and learnable.
In what order should I learn the patterns? Start with array-based patterns (two pointers, sliding window), then linked lists (fast and slow pointers, in-place reversal), then trees (DFS, then BFS), then graphs, then heaps and intervals, and finish with backtracking and dynamic programming. Each stage reuses machinery from the previous one.
Is pattern-based prep enough, or do I still need to grind? Pattern-based prep is the efficient version of grinding: you still solve real problems, but grouped and sequenced so each one compounds. Most engineers are interview-ready after 100 to 150 pattern-organized problems plus weekly timed mocks, versus 300+ random problems for grinders, with better results.
Does pattern recognition work for dynamic programming? Yes, with one adjustment: treat DP as a family of sub-patterns (0/1 knapsack, unbounded knapsack, longest-common-subsequence shapes, palindrome shapes, Fibonacci shapes) rather than one topic. Each sub-pattern has its own tell and template. DP feels impossible only when every DP problem is approached from scratch.