LeetCode Patterns: How to Spot Them Before You Code

LeetCode patterns are not a list to memorize. They are signals hiding in the problem statement, and the interview reward goes to whoever spots the signal fastest, not whoever has solved the most problems.

What Are LeetCode Patterns, Really?

A pattern is a reusable strategy that solves a whole family of problems, not just one. Sliding window solves subarray and substring problems. Two pointers solves sorted-array and linked-list problems. Binary search solves anything with a monotonic search space, not just sorted arrays. Once you see the strategy behind a problem instead of the problem itself, a question you have never seen stops looking unfamiliar.

Ten to twelve patterns cover the large majority of questions asked in real coding interviews: sliding window, two pointers, modified binary search, BFS, DFS, dynamic programming, backtracking, topological sort, union-find, and a handful of heap or interval variants. Learn the signal for each one and you can approach a brand-new problem with a plan in the first thirty seconds instead of staring at it.

Why Doesn't Memorizing a List of Patterns Work?

Most pattern lists online give you a name and three example problems, then move on. That gets you exactly one thing: the ability to recognize a problem you have already seen. It does nothing for the problem you have not seen, which is what an actual interview gives you.

The skill that transfers is recognition from the problem statement itself, before you touch the constraints or think about code. Every pattern has a small set of phrases and shapes that tip you off. Learn those signals instead of memorizing solved problems, and pattern recognition works on a question you are reading for the first time, live, with someone watching.

The rest of this guide walks through each major pattern the same way: what to look for, why that signal points to that pattern, and where it breaks down.

How Do You Recognize the Sliding Window Pattern?

Sliding window applies when you need a contiguous subarray or substring that satisfies some condition, and shrinking or growing a window is cheaper than recomputing from scratch every time.

Signal phrases: "contiguous subarray", "substring", "at most k distinct", "longest run", "maximum sum of size k". Any time the word contiguous shows up next to subarray or substring, check window first.

Example: "Find the longest substring with at most two distinct characters."
Signal: substring + a bounded count constraint = shrink the window when the
constraint breaks, grow it otherwise.

Where it breaks down: if the problem allows non-contiguous selection, or the answer depends on elements outside the current window, sliding window stops being a clean fit. Watch for "any subsequence" instead of "any subarray" - that single word swap usually rules the pattern out.

How Do You Recognize the Two Pointers Pattern?

Two pointers applies when the input is sorted, or can be sorted without losing what the problem asks for, and you are looking for a pair, triplet, or partition point.

Signal phrases: "pair that sums to", "sorted array", "remove duplicates in place", "partition around a value". The sorted-array signal is the strongest one: if a problem hands you a sorted array and asks about pairs, two pointers is almost always faster than the nested loop your first instinct reaches for.

Example: "Given a sorted array, find two numbers that add up to a target."
Signal: sorted input + pair search = start pointers at both ends and move
based on whether the current sum is too high or too low.

Where it breaks down: unsorted input with no sort step allowed, or a problem that needs every pair rather than just one, usually rules it out.

How Do You Recognize a Binary Search Pattern?

Binary search is not only for finding a value in a sorted array. It applies to any problem where you can ask "is this answer good enough" and get a yes-or-no result that flips exactly once as you move across the search space.

Signal phrases: "minimize the maximum", "find the smallest value such that", "search a rotated sorted array". That "smallest value such that" phrasing is the giveaway for search-on-the-answer problems, a variant a lot of candidates miss because there is no literal sorted array in sight.

A full walkthrough of binary search mechanics, including five language implementations, lives in our binary search guide - worth a read if this pattern feels shaky.

Where it breaks down: if the search space is not monotonic, meaning the yes/no answer can flip back and forth instead of flipping once, binary search does not apply no matter how sorted the input looks.

How Do You Recognize BFS and DFS Problems?

Both traverse a graph or tree, and the words in the problem tell you which one to reach for.

BFS signal phrases: "shortest path", "minimum number of steps", "level by level". Anything asking for a minimum number of hops or steps in an unweighted graph wants BFS, because BFS explores in order of distance from the start.

DFS signal phrases: "all paths", "connected components", "does a path exist", "explore as far as possible". If the question wants every possibility rather than the shortest one, or just wants to know whether something is reachable, DFS (often with memoization) is the simpler tool.

Example: "Find the shortest path from a start cell to an end cell in a grid,
moving only through open cells."
Signal: shortest + unweighted grid = BFS, not DFS. A DFS solution would find
a path, but not necessarily the shortest one, without extra bookkeeping.

Where it breaks down: a weighted graph needs Dijkstra's algorithm instead of plain BFS, and that distinction is worth naming out loud if you spot weights on the edges.

How Do You Recognize a Dynamic Programming Problem?

Dynamic programming applies when a problem can be broken into overlapping subproblems, meaning the brute-force recursive solution recomputes the same smaller answer many times.

Signal phrases: "number of ways to", "minimum cost to reach", "longest common", "maximum profit with constraints". The phrase "number of ways" is one of the strongest DP signals in interview questions, because counting problems almost always decompose into smaller counting problems.

The fastest way to confirm a hunch: sketch the brute-force recursive solution first, even just in your head. If you can point to the same subproblem being solved twice, memoize it. That single check turns a vague "this might be DP" into a confirmed plan before you write a line of code.

Where it breaks down: if subproblems do not overlap, you have plain recursion or divide and conquer, not DP, and adding memoization would do nothing useful.

How Do You Recognize Backtracking, Topological Sort, and Union-Find?

These three show up less often than the patterns above, but each has a distinct, easy-to-catch signal.

Backtracking signal phrases: "generate all", "all permutations", "all valid combinations". Any time a problem wants every valid arrangement rather than one optimal answer, you are building and unwinding a partial solution, which is backtracking.

Example: "Generate all valid combinations of well-formed parentheses for n pairs."
Signal: generate all + a validity rule at each step = build one character at
a time, backtrack the moment a partial choice breaks the rule.

Topological sort signal phrases: "course prerequisites", "build order", "task scheduling with dependencies". A dependency graph where some things must happen before others, and the question asks for a valid order, is a topological sort problem almost every time.

Example: "Given course prerequisites, return a valid order to take all courses."
Signal: prerequisites + a valid order requested = topological sort;
a cycle in the dependency graph means no valid order exists at all.

Union-find signal phrases: "connected groups", "merge accounts", "redundant connection". Anything about grouping items into connected sets, especially when the groups merge as you process more input, points to union-find over a fresh graph traversal for every query.

Example: "Given pairs of accounts that share an email, merge all accounts
belonging to the same person."
Signal: pairs that merge groups over time = union-find, since re-running a
full graph traversal after every new pair would waste the work already done.

How Do You Recognize Heap and Interval Problems?

Heap-based problems and interval problems get grouped together because they share a common trigger: you need the current best or current overlap out of a changing set, not the full sorted set.

Heap signal phrases: "kth largest", "top k frequent", "merge k sorted lists", "median of a stream". Any time a problem asks for the kth something, or the running best as data keeps arriving, a heap keeps that answer available in log n time without re-sorting everything on every update.

Example: "Find the kth largest element in a stream of numbers."
Signal: kth + stream = maintain a heap of size k instead of re-sorting after
every new number.

Interval signal phrases: "merge overlapping intervals", "meeting rooms", "insert an interval", "minimum number of platforms". These almost always start with sorting the intervals by start time, then walking through once to merge or count overlaps, which turns an apparent scheduling problem into a single linear pass after the sort.

Where these break down: if the data does not need a running best, a full sort is simpler than a heap. And if intervals are not actually ordered by a meaningful axis like time, the sort-then-sweep approach for interval problems will not apply cleanly.

How Should You Talk Through Pattern Recognition in the Interview?

Name the pattern out loud as soon as you spot the signal, before you start coding. Something as short as "the sorted input and the pair search tell me this is a two-pointer problem" does two things at once: it shows the interviewer your reasoning instead of just your syntax, and it gives them a chance to redirect you early if you have misread the problem.

Tie the pattern back to complexity while you are at it. If you already have a feel for how time complexity works in interviews, say the Big O of your chosen approach before you code it, and compare it to the brute-force alternative you are skipping. "Brute force is O(n squared) with nested loops; two pointers gets this to O(n) after a single sort" is a complete, confident sentence that costs you five seconds and buys real credit.

If you guess wrong, say so and pivot. "I initially thought sliding window, but the subsequence in this problem does not need to be contiguous, so I am switching to a DP approach instead" reads as stronger signal than silently backtracking, because it shows you can catch your own mistake.

How Do You Build Pattern Recognition Without Memorizing 500 Problems?

Depth beats breadth for pattern recognition specifically. Solve four or five problems inside one pattern before moving to the next, and spend real time after each one asking what phrase in the problem statement should have tipped you off from the start, not just whether your solution passed.

Mixing patterns matters just as much once you have the individual signals down. A block of problems that are all sliding window in a row teaches you nothing about telling sliding window apart from two pointers under pressure, because you already know which pattern to reach for before you read the question. Real interviews do not announce the pattern in advance, so your practice should not either.

A practical structure for four weeks looks like this: week one, sliding window and two pointers, five problems each, since both operate on similar array-scanning intuition and pair well for comparison. Week two, BFS and DFS, again five problems each, deliberately mixed with a few from week one so the signal has to be re-identified instead of assumed. Week three, dynamic programming alone, since it is the pattern most candidates under-practice relative to how often it appears. Week four, backtracking, topological sort, union-find, heaps, and intervals together, mixed with everything from the previous three weeks. By the end of that mix, you are reading a new problem and asking "which of these ten signals is present" instead of "have I seen this exact question before."

Curated, currently-relevant problems save real time here, since a stale or unfiltered problem list makes it harder to tell which patterns are actually showing up in interviews right now versus which ones were common five years ago. Our question bank is organized so you can practice one pattern in depth, then mix it back in with others once the signal feels automatic, using problems sourced from actual candidate reports rather than a static public list.

Frequently Asked Questions

How many LeetCode patterns do I actually need to know?

Ten to twelve core patterns cover the large majority of questions in real coding interviews: sliding window, two pointers, binary search, BFS, DFS, dynamic programming, backtracking, topological sort, union-find, and heap or interval variants. Going deep on these beats a shallow pass over fifty named patterns.

How long does it take to learn one pattern well?

Two to three days per pattern is a reasonable pace for most candidates: one day to learn the signal and mechanics, then several problems over the following days to make the recognition automatic rather than something you have to think through each time.

Can a problem use more than one pattern?

Yes, and interviewers often design questions this way on purpose. A problem might need a sliding window to find a candidate range, then binary search to narrow it further. Naming both patterns as you move between them shows the interviewer you are tracking the shift, not just producing code.

Is it better to learn patterns or just solve as many problems as possible?

Learn the patterns before racking up a raw problem count. Solving problems without an organizing framework means each new question feels like starting over, while learning the signal behind ten to twelve patterns lets you transfer what you know to problems you have never seen, which is the actual skill being tested.

What should I do if I do not recognize any pattern in a problem?

Say so, out loud, and start from what you do know: restate the problem in your own words, work a small example by hand, and look for repeated sub-steps as you do. Naming your process, even without a pattern name attached yet, is far stronger than silence while you search your memory for a label.