The 17 Coding Interview Patterns (2026): A Recognition Cheat Sheet

Coding interviews are mostly a recognition test. You are rarely asked to invent an algorithm; you are asked whether you can look at an unfamiliar problem and see which of a small number of known shapes it is. That set of shapes is what people mean by "patterns" — and the useful skill is not implementing them, which takes a few weeks, but recognising them, which takes months.

This is the hub for that skill. The table below is the part worth bookmarking: the observable signal on the left, the pattern it implies on the right. Everything after it is detail.

The recognition table

Read a problem for structural signals, not for the story it is dressed in. "You are given a list of trades" and "you are given an array of integers" are the same problem wearing different clothes.

The numbers match the sections below, and the last column is one problem per pattern — solve that one and you own the recognition, not just the template.

Why seventeen, and not twenty

Every list you will find publishes a suspiciously round number, and the clearest evidence that the number is an editorial choice rather than a finding is that the same publisher cannot reproduce its own list.

DesignGurus, whose founder wrote the original Grokking course, publish at least three articles on this, and they do not agree with each other. Two of them say twenty, and they are not the same twenty. One lists backtracking at #15, monotonic stack at #19 and "multi-threaded" at #20; the other drops all three and fills the slots with Fibonacci Numbers, Palindromic Subsequence and Longest Common Substring. One opens "here are the top 20 coding interview patterns"; the other, more honestly, says "I have gathered around 20." A third article gives ten and closes by pointing readers at "the complete guide to all 42." The course page says 40+. I went through that whole family separately in Grokking the Coding Interview alternatives.

Educative's article lists twelve numbered patterns, then names three more in a "next steps" aside — k-way merge, bitwise manipulation, math and geometry — while its own course sells twenty-eight. Prefix sum appears in none of them. The article also carries the claim that "about 87% of questions are built around only 10 to 12 core problem-solving patterns." Treat that as a marketing figure: it links no study, publishes no methodology, and carries no date. "Recent data from hundreds of real interviews" is an assertion wearing the clothes of a citation, and I would not repeat the number as a fact. AlgoMonster, to its credit, refuses to give a number at all; it publishes a keyword-to-technique table and lets the count fall where it falls. Sean Prashad's widely-used list is an index rather than a syllabus — 179 questions grouped by pattern, with no total ever published, which is arguably the most honest format of the lot.

Competitor pages above read on 11 August 2026. All of them are live documents; if you are checking my work later, expect the numbers to have moved.

And the disagreement is not at the margins. DesignGurus' twenty omits union find, trie, greedy and prefix sum — four things that between them account for a large slice of what gets asked, and any one of which showing up unprepared would cost you the round. So the comforting idea that some core set appears on every list is simply false; it does not survive opening two of them side by side.

The lists disagree because they are cutting a continuum in different places. If you are specifically weighing that course against the rest of the market, I broke the whole family down separately in Grokking the Coding Interview alternatives — including the five different pattern counts its own publishers ship.

So here is my actual position, and where I differ:

What I added. Prefix sum appears on neither of DesignGurus' twenty-pattern lists, not among Educative's twelve, and not in its twenty-eight-pattern course either. That is a mistake. It has a clean recognition signal, a two-line implementation, and it is the base for a family of problems — subarray sums equal to k, range queries, difference arrays — that people otherwise solve badly with nested loops. It earns its slot more than several patterns that are on those lists.

The test I applied throughout: does this give you a different way of looking at an unfamiliar problem, or is it a solution you have memorised for a specific one? Only the former is a pattern.

What happened to everything else. A cut list is easy to write selectively, so here is the full accounting — every entry that appears on DesignGurus' two twenties, Educative's twelve and twenty-eight, ByteByteGo's nineteen, or NeetCode's roadmap, and where it went:

Seventeen is where that test stops admitting entries — and the fact that it is not a round number is the point.

The second signal: what the constraints tell you

The table above reads the problem's phrasing. There is a second, colder signal that most pattern lists skip entirely, and it is the one I lean on hardest when the phrasing is ambiguous: the size of n rules out most of the seventeen before you have thought about any of them.

The reasoning is crude and it works. Assume the judge affords you somewhere around 10⁸ simple operations — that is the interview folklore number, not a benchmark, and the real figure swings by an order of magnitude with language and constant factors. It does not need to be right. It needs to be right about the exponent, and for that it is plenty.

Run it forwards. If n is 200,000, then O(n²) is 4 × 10¹⁰ and dead on arrival, so whatever you write has to be O(n log n) or better — which quietly eliminates dynamic programming over pairs, most backtracking, and every nested-loop idea you were about to describe. If n is 18, the opposite happens: O(2ⁿ) is about 260,000 operations and completely fine, and a bound that small is a near-explicit instruction to enumerate subsets. A constraint of n ≤ 18 is not a detail the problem-setter left lying around by accident.

Two things this buys you in a live round. It kills wrong branches before you have spent ten minutes in one — the most expensive mistake in a 45-minute interview is not a bug, it is committing to an approach whose complexity was never going to fit. And saying the reasoning out loud ("n is up to 10⁵, so I need at least O(n log n), which points me at sorting or a heap") is one of the clearest seniority signals available to you. Interviewers hear it as knowing where the answer lives before searching for it.

The one caveat: this narrows the family, not the pattern. "O(n log n), so sorting or a heap or binary search" is as far as the constraint alone can carry you. The recognition table picks which of those three it actually is.

The precise ladder — every constraint band, what it admits, and the two rows where the folklore number quietly breaks down — is the first of the four reads in how to identify coding interview patterns. Slide the tool above to get the intuition; go there for the table you would actually check against.

The seventeen

Each block gives you the recognition signal, the mechanism that makes it work, the complexity to quote, and the failure mode I see most often in mock interviews. Code appears only where the shape is not obvious from the description — the full templates, variants and drill sets live in the linked breakdowns, because a page that reprinted seventeen templates would be a reference you scroll past rather than one you read.

1. Two Pointers

Signal: sorted input, and you are looking for a pair or triplet satisfying a condition.

Two indices move toward each other. Because the array is sorted, comparing the current sum against the target tells you unambiguously which pointer to move — moving left rightward can only increase the sum, moving right leftward can only decrease it.

That is the mechanism, but it is not the argument, and the argument is what gets asked. The question an interviewer will put to you is how do you know you haven't skipped a pair? The answer: if arr[left] + arr[right] is below the target, then arr[right] is the largest partner arr[left] has left — every remaining candidate is smaller — so arr[left] cannot reach the target with anything, and it is eliminated permanently, not merely passed over. Each comparison retires one endpoint along with every pair it still had. That is why n steps suffice to clear n candidates, and it is the sentence that turns "I've seen this" into "I can prove it."

On already-sorted input this is O(n) and O(1) space. If you have to sort first, it is O(n log n) — and on unsorted input a hash map beats it outright at O(n), which is why plain Two Sum — unsorted, and the first problem on most people's list — is not a two-pointer problem at all. See §17.

def two_sum_sorted(arr, target):
    left, right = 0, len(arr) - 1
    while left < right:
        total = arr[left] + arr[right]
        if total == target:
            return [left, right]
        if total < target:
            left += 1      # need a larger sum
        else:
            right -= 1     # need a smaller sum
    return []

Complexity: O(n) for the pair version once sorted, O(1) extra space. The triplet version (3Sum) fixes one element and runs the pair scan inside it, so it is O(n²) — say which one you mean, because "two pointers is linear" is only half true. Failure mode: using it on unsorted input. The correctness argument depends entirely on the ordering — without it, moving a pointer tells you nothing.

Full breakdown: Two Pointers. And if this is the one you keep confusing with sliding window — most people do — that comparison has its own page, including two worked cases where picking the wrong one returns a plausible wrong answer rather than failing loudly.

2. Sliding Window

Signal: the word contiguous (subarray, substring) plus an optimisation or a count.

A window slides across the data; you add the entering element and remove the leaving one rather than recomputing. Fixed-size windows slide one step at a time. Variable-size windows expand until they violate a constraint, then contract from the left until valid again.

Complexity: O(n) — each element enters and leaves at most once. Failure mode: recomputing the window aggregate on each step, which throws away the entire advantage and leaves you at O(n·k) with more code.

Full breakdown: Sliding Window.

3. Binary Search

Signal: sorted input — or, far more interestingly, a monotonic answer space.

The second case is where interviews actually live, and most candidates miss it. If you can write a function feasible(x) that is false below some threshold and true from that threshold onward, you can binary search over the answer itself, even when there is no sorted array anywhere in the problem. "Minimum capacity to ship packages in D days" is a binary search. So is "minimum eating speed", "split array largest sum", and a large family of optimisation problems that look like nothing of the sort.

def min_feasible(lo, hi, feasible):
    while lo < hi:
        mid = lo + (hi - lo) // 2   # avoids overflow in fixed-width languages
        if feasible(mid):
            hi = mid                # mid might be the answer; keep it
        else:
            lo = mid + 1            # mid is definitely too small
    return lo

Complexity: O(log n) comparisons over an array of length n. When you search an answer space there is no array, so it is O(log(hi − lo) × cost of feasible) — the range you are bisecting, not a collection size. Failure mode: the boundary. Almost every failed binary search in an interview is an off-by-one in whether hi becomes mid or mid - 1. Pick one template, understand why its invariant holds, and never improvise it under pressure. Note also that this template returns hi unchecked if nothing in the range is feasible — pick hi as a known-feasible bound, or test the result before returning it.

Full breakdown: Binary Search.

4. Prefix Sum

Signal: repeated range queries over data that does not change.

Precompute cumulative sums once, then any range answers in constant time as a subtraction. The variant worth knowing is pairing it with a hash map to count subarrays summing to a target — that combination solves a surprising number of problems that look much harder.

def subarray_sum_equals_k(nums, k):
    counts = {0: 1}          # empty prefix, so a prefix equal to k counts
    running = answer = 0
    for n in nums:
        running += n
        answer += counts.get(running - k, 0)
        counts[running] = counts.get(running, 0) + 1
    return answer

Complexity: the static cumulative array is O(n) to build and O(1) per range query. The counting variant above is a single O(n) pass with no separate query phase — two different shapes, so quote the one you actually built. Failure mode: forgetting to seed the map with {0: 1}, which silently loses every subarray that starts at index 0. The code runs, returns a plausible number, and is wrong.

5. Monotonic Stack

Signal: "next greater element", "previous smaller element", spans, or histogram-shaped problems.

You maintain a stack whose values are always increasing or always decreasing. When a new element violates that order, you pop — and each pop is the moment you learn the answer for the popped element. Every element is pushed and popped at most once, so despite the nested loop it is linear.

Complexity: O(n) time, O(n) space. Failure mode: storing values instead of indices. You almost always need the index to compute a distance or a width, and recovering it afterwards is painful.

6. BFS

Signal: shortest path in an unweighted graph, or anything that must proceed level by level.

Breadth-first search reaches every node by the fewest possible edges, which is why it answers shortest-path questions on unweighted graphs and why it is the right tool for level-order traversal. Mark nodes as visited when you enqueue them, not when you dequeue them, or you will process duplicates.

Complexity: O(V + E) time, O(V) space. Failure mode: using BFS on a weighted graph and expecting shortest paths. It does not work — you need Dijkstra, and knowing that boundary is itself a senior signal.

7. DFS

Signal: explore all paths, or visit the entire structure.

Depth-first search carries path state naturally on the call stack, which makes it the default for tree problems and for anything where the answer depends on the route taken rather than its length.

Complexity: O(V + E) time; space is O(H) for the recursion stack plus O(V) for the visited set on a graph — quote both, because the stack alone is the tree answer. Failure mode: stack overflow on deep inputs. Mention the iterative conversion before the interviewer asks — a graph with 10⁵ nodes in a line will blow the default recursion limit in Python.

Both traversals in context: Graph Algorithms.

8. Topological Sort

Signal: dependencies. "Must be completed before", prerequisites, build order.

Kahn's algorithm repeatedly removes nodes with in-degree zero. If you finish with nodes remaining, the graph has a cycle — which is usually the interesting half of the question, since "can this schedule be satisfied at all?" is really a cycle-detection problem wearing a scheduling costume.

Complexity: O(V + E). Failure mode: not handling the cycle case. Course Schedule is asked precisely because it has one.

9. Union Find

Signal: connectivity, grouping, or "are these two things in the same set".

A disjoint-set structure with path compression and union by rank answers both in near-constant amortised time. It is the right answer whenever connectivity is being built up incrementally — where a traversal would need to re-run after every edge.

Complexity: effectively O(α(n)) per operation, which is under 5 for any realistic n. Failure mode: implementing it without path compression, then claiming near-constant complexity. The interviewer will ask, and the two lines are worth memorising.

10. Heap / Top-K

Signal: k largest, k smallest, k most frequent, or a running median.

The insight is that you never need to sort everything. A heap of size k, holding the opposite extreme at its root, lets you discard candidates in O(log k) — so a min-heap for the k largest. This is also where two-heaps (median from a stream) and k-way merge live; they are heap usage, not separate patterns.

Complexity: O(n log k) for the bounded-heap version, which beats sorting whenever k is meaningfully smaller than n. Know the two alternatives and when they win: heapifying all n and popping k times is O(n + k log n), which is faster for very small k, and quickselect is O(n) average if you may reorder the input and do not need the k in sorted order. Failure mode: using a max-heap for the k largest in the streaming case. When you are holding only k items, you need the smallest of them at the root so you can evict it in O(log k) — a max-heap puts the wrong element where you need to look. (If you already have all n in memory, a max-heap is fine; the objection is specifically about the bounded-size heap.)

11. Backtracking

Signal: "all combinations", "all permutations", "all subsets", or constraint satisfaction.

Systematic enumeration: choose, recurse, un-choose. The mechanical part is easy. The part that separates candidates is pruning — recognising a branch as doomed before exploring it. N-Queens is asked because the naive enumeration is 8⁸ and the pruned search is a few thousand nodes.

Complexity: exponential by nature — O(2ⁿ) for subsets, O(n!) for permutations. Say so plainly; pretending otherwise reads as not understanding the problem. Strictly it is Θ(n·2ⁿ) and Θ(n·n!) once you count copying each completed answer into the results list, and that is the follow-up if you state 2ⁿ flatly — the copy at every leaf is O(n) and there are 2ⁿ leaves. Failure mode: forgetting to undo state on the way back up, which corrupts every sibling branch and produces answers that look almost right.

12. Dynamic Programming

Signal: overlapping subproblems and optimal substructure. In practice: counting ways, or optimising over a sequence of choices.

The reliable route is to write the recursion first, memoise it, and only then convert to a table if you need the space. Candidates who start from the table usually cannot explain their own recurrence. This is the pattern that takes longest to internalise, and it is genuinely a family — knapsack, longest-increasing-subsequence, grid paths and interval DP share a mindset but not a template.

Complexity: states × work per state. Say it that way and the analysis becomes mechanical. Failure mode: an incorrect state definition. Almost every failed DP is a state that does not capture everything the recurrence depends on, and no amount of debugging the loop bounds fixes it.

Full breakdown: Dynamic Programming Patterns.

13. Greedy

Signal: a locally optimal choice can be shown to be globally optimal.

Greedy is short to write and hard to justify, and the justification is the interview. If you cannot argue an exchange argument — that any optimal solution can be transformed into your greedy one without getting worse — you do not actually know the answer is correct, and the interviewer will find the counterexample.

Complexity: usually O(n log n), dominated by the sort. Failure mode: asserting greed works because it passed the examples. Coin change with denominations and a target of 6 breaks the obvious greedy and is the standard counterexample.

14. Fast & Slow Pointers

Signal: cycle detection, or finding the middle of a linked list in one pass.

Two pointers over the same sequence at different speeds. If there is a cycle they must eventually meet; if there is not, the fast one exits. The follow-up — find the cycle's entrance — is the actual question, and it has a short proof worth knowing rather than memorising.

Complexity: O(n) time, O(1) space, which is the reason to prefer it over a hash set. Failure mode: null checks. fast.next.next needs both fast and fast.next to exist, and getting that wrong is the single most common runtime error in this pattern.

15. Trie

Signal: prefix lookups across a set of strings — autocomplete, word search, prefix matching.

A tree keyed by character, sharing prefixes rather than storing them repeatedly. Reach for it when the query is about prefixes; a hash set is better for exact membership and you should say so.

Complexity: O(L) per operation for a string of length L, independent of how many words are stored. Failure mode: proposing a trie for exact-match lookup, where a hash set is simpler and faster. Knowing when not to use a structure is a stronger signal than knowing how to build it.

16. Merge Intervals

Signal: overlapping ranges — merging, inserting, scheduling, or counting rooms.

Sort by start, then sweep, extending the current interval whenever the next one begins before the current ends. The scheduling variants (minimum meeting rooms) are the same sweep with a heap tracking end times.

Complexity: O(n log n) for the sort, O(n) for the sweep. Failure mode: sorting by the wrong endpoint. Sort by start to merge; sort by end for most interval-scheduling maximisation problems. Getting this backwards produces a clean-looking solution that is simply wrong.

17. Hashing

Signal: you keep wanting to ask "have I seen this before?", "how many of X are there?", or "where was X?" — and the input is unsorted.

The lens is trading space for time: store what you have already seen, keyed by the thing you will need to look it up by. That last clause is the entire skill, and it is where candidates lose the plot — the map from a value to its index solves Two Sum, the map from a sorted-letter signature to a list solves group anagrams, the map from a running prefix to its frequency solves subarray-sums-to-k (§4 above is a hashing solution that never says so), and the map from a value to its count is the step that must happen before the heap in top-k-frequent.

I nearly left this out on the grounds that a hash map is a data structure rather than a way of seeing a problem. That objection does not survive contact with this list: trie, heap, union find and monotonic stack are all on it, and every one of them is a data structure. Excluding the most-used one while admitting four rarer ones would be a position I could not defend, so here it is — and it is the reason the count is seventeen rather than sixteen.

Complexity: O(1) average for insert and lookup, O(n) worst case under adversarial collisions or a bad hash. Quote the average, know the worst case exists. Failure mode: reaching for a map when the input was already sorted and the interviewer's actual constraint was O(1) space — the sorted case is two pointers, and the map is a worse answer that passes the tests. Second most common: mutable or unhashable keys, and forgetting that a dictionary keyed on a list will not compile in the first place.

The patterns compose, and the hard problems are where they do

Every list on the internet, including the one above, presents these as seventeen alternatives you pick between. Past the easy tier that stops being true: the problems that separate candidates are usually two patterns stacked, and if you are looking for the one right answer you will not find it.

The combinations worth knowing by name:

• Window + hash map. The window gives you the range; the map is the state describing its contents. Every "longest substring with at most k distinct" problem is this. Neither half solves it alone.
• Binary search + a greedy feasibility check. This is the whole of binary-search-on-the-answer. The search picks a candidate x; a linear greedy pass answers "is x achievable?"; monotonicity of that answer is what licenses the search. Koko Eating Bananas, capacity-to-ship-packages, minimise-the-maximum — all one shape.
• DFS + memoisation is dynamic programming. Not a cousin of it. If you can write the recursion and cache on the arguments, you have written the DP, and saying that out loud is worth more than producing a table you cannot explain.
• Sort + two pointers. The sort is what buys the elimination argument. It is also what costs you O(n log n) and rules the approach out whenever the answer must stay contiguous.
• Heap + hash map. Top-k-frequent needs the counts before it can rank them. The map is not a helper here; it is half the algorithm.

The practical consequence: when one pattern gets you most of the way and leaves a gap, do not discard it and start over. Name the gap — "the window handles the range, but I need to know how many distinct values are inside it" — and the second pattern is usually obvious from the gap alone. Interviewers read that as composition rather than recall, and it is the clearest way to sound senior on a problem you have not seen.

Training the recognition, not the templates

Here is the part most pattern guides skip, and it is the part that decides interviews.

Implementing seventeen templates is a few weeks of work. Recognising which one an unfamiliar problem needs, under time pressure, with someone watching, takes months — because it is a different skill, trained differently. Re-solving problems you have already seen trains recall, not recognition. The two feel identical while you practise and diverge completely in the interview.

The one change that matters: separate classifying from solving, and practise the classifying. Read a problem, commit to a pattern and to the signal that made you commit, then check — without writing code. A classification pass costs about ninety seconds against the half-hour a full solve takes, so you cover twenty problems in the time one solve would have taken, and every one of them drills the step that actually fails under pressure. Practise on problems you have not seen; the moment you recognise the problem rather than its shape, it has stopped teaching you anything.

The full procedure — the four reads to run on an unfamiliar statement, the log format that turns your misses into a study plan, and the rules that settle the pairs everyone confuses — is the companion to this page: how to identify coding interview patterns.

The failure I see most often in mock interviews is not a candidate who does not know the patterns. It is a candidate who recognises the pattern in four seconds, starts coding immediately, and never states the assumption that makes their approach correct. Recognition is the start of the answer, not the answer.

Build a schedule around this with the free study-plan generator, or take the printable version with you: the pattern cheat sheet has the recognition table above in one page.

Where to go next

Five of the seventeen have their own breakdown, with the template, the variants and the problems to drill:

Two Pointers · Sliding Window · Binary Search · Dynamic Programming · Graph Algorithms

Two more posts cover the choosing rather than the patterns themselves — the procedure for an unfamiliar statement in how to identify coding interview patterns, and the single most-confused pair in two pointers vs sliding window.

The remaining breakdowns are being written; this page will link them as they land.

If you would rather not do this alone, we drill exactly this recognition skill live every week in the DSA course — a cohort works through unfamiliar problems together, and the whole point of the format is that you have to name your reasoning out loud before you write code.

Get each new pattern breakdown as it publishes — one email, no filler.

Amit Singh is a Senior SDE at Amazon, a Claude Certified Architect, and the instructor at AlgoEngineer.