The 15 Coding Interview Patterns That Cover Most Problems

Most engineers think learning coding interview patterns means memorizing templates. They collect fifteen or twenty pattern names, assume the hard part is over, and move on. Then they open an unfamiliar problem and nothing clicks. The template doesn't match. The pattern name doesn't help. The problem looks different enough that the connection never fires.

That gap between collecting patterns and actually using them? It comes down to construction. Knowing a pattern's name and being able to rebuild its logic from scratch are completely different skills.

⚡TL;DR

Fifteen algorithmic patterns cover roughly 90% of coding interview problems because those problems belong to a finite set of problem classes. Mastering the class, not memorizing the template, is what lets you solve problems you've never seen.

What Coding Interview Patterns Actually Are

A coding interview pattern isn't a solution template you paste onto a problem. It's a recurring algorithmic model that solves an entire class of problems sharing the same underlying constraint.

Fifteen patterns cover roughly 90% of interview questions because algorithmic problems belong to a finite set of problem classes. When you understand the class, that understanding transfers to every problem within it. You aren't memorizing individual solutions. You're learning the reasoning that generates them.

Take the variable sliding window. It doesn't just solve "longest substring without repeating characters." It solves every problem where you need to find an optimal contiguous range that satisfies a dynamic constraint. The problem might ask about character frequencies or subarray sums. It might involve multiplication thresholds or a completely different domain. The logic underneath is identical. When you understand the invariant that makes the window expand or contract, you've unlocked dozens of problems through a single mechanism.

Pattern lists typically stop at the label. They tell you "this is a sliding window problem" without explaining why the window works, what constraint class triggers it, or how to derive the window bounds from scratch. That's exactly where engineers get stuck in interviews. They recognise the name but can't rebuild the logic when the problem doesn't match their memorised version.

The 15 Coding Interview Patterns and What Each Solves

These fifteen patterns cover the problem classes that appear most frequently across FAANG interviews. Each one addresses a specific type of constraint, and the example problems listed aren't the only ones each pattern solves. They're one entry point from a class of dozens.

The 15 patterns that cover 90% of coding interviews

Two Pointers

This pattern converges from two ends of a sorted array or string and is commonly tested as Two Sum (sorted), Three Sum, and Largest Container.

Fixed Sliding Window

This pattern tracks a fixed-size subarray without redundant recomputation and is commonly tested as maximum sum of K consecutive elements.

Variable Sliding Window

This pattern expands and contracts a window to find an optimal range under a dynamic constraint and is commonly tested as longest substring with K distinct characters.

Binary Search

This pattern eliminates half the search space per step on sorted data or answer-space predicates and is commonly tested as search in rotated sorted array.

Prefix Sum

This pattern precomputes cumulative sums for O(1) range queries and is commonly tested as subarray sum equals K.

Frequency Counting

This pattern uses a hash map to track element counts for existence, grouping, and anagram detection and is commonly tested as group anagrams.

Fast & Slow Pointers

This pattern detects cycles and finds midpoints using speed differential and is commonly tested as linked list cycle detection.

Monotonic Stack

This pattern finds the next or previous greater or smaller element in linear time and is commonly tested as next greater element and largest rectangle in histogram.

BFS

This pattern finds shortest paths in unweighted graphs and grids through level-by-level exploration and is commonly tested as minimum steps in a grid.

DFS

This pattern enumerates paths, detects connectivity, and finds cycles through recursive exploration and is commonly tested as number of islands.

Backtracking

This pattern enumerates valid configurations by building candidates incrementally and pruning dead ends and is commonly tested as N-Queens and generate parentheses.

Interval Merging

This pattern combines overlapping intervals using a sorting-based line sweep and is commonly tested as merge intervals and minimum meeting rooms.

Tree Postorder

This pattern computes bottom-up tree answers where each node depends on its children and is commonly tested as binary tree diameter and maximum path sum.

Top K Elements

This pattern maintains a heap of size K for selection queries without full sorting and is commonly tested as Kth largest element and K most frequent.

Dynamic Programming (Knapsack and LCS)

This pattern optimises over overlapping subproblems using memoisation or tabulation and is commonly tested as coin change and longest common subsequence.

Some engineers have already internalised several of these patterns through sheer repetition. Solve enough problems in a particular category and the reasoning starts to feel intuitive without explicit training. That works, but it's slow. Transferring that intuition across categories is even slower. Explicit pattern training compresses the same process from months of trial and error into weeks of deliberate study.

ℹ️ Info

The identification lesson for variable sliding window on Codeintuition teaches you the exact constraint triggers that tell you this pattern applies, before you ever attempt a problem. Every pattern has an equivalent identification phase.

How Coding Interview Patterns Get Built from First Principles

Knowing the name monotonic stack doesn't help you in an interview. Building it from the invariant does. Take the next greater element pattern. You're given an array and need to find, for each element, the nearest larger element to its right. Brute force checks every pair for O(n²). But there's an observation hiding in the problem.

Python

The code isn't the point. The invariant is: the stack always holds elements in decreasing order, and each element gets popped exactly once. That guarantees O(n) total time. Without understanding why the decreasing order matters, you can't adapt this pattern to "largest rectangle in histogram" or "retained rainwater." Both use the same invariant with different entry conditions.

“The difference between knowing a pattern and owning it is whether you can derive the invariant from the problem constraints.”

Pattern construction principle

First-principles pattern construction starts with the core observation, the invariant that makes the efficient approach possible, and builds the algorithm around it. Not the other way around. The understanding lesson for monotonic stack on Codeintuition traces this exact derivation frame by frame, showing how each variable changes at every step.

Why 15 Patterns Cover 90% of Interview Problems

Ninety percent sounds aggressive. It holds up because algorithmic interview problems aren't as diverse as they appear.

Most medium and hard problems on LeetCode, HackerRank, and in actual FAANG interviews are variations on the same problem classes. A problem that asks "find the longest subarray satisfying condition X" is a variable sliding window problem regardless of whether X involves character counts, sums, or cumulative values. One that asks "find the shortest path in an unweighted graph" is BFS whether the graph represents a word transformation, a grid, or a social network.

Codeintuition's problem bank has data on this. Across 450+ problems tagged by the companies that test them, the same patterns show up at Amazon, Google, Meta, Apple, and Microsoft with striking consistency. Counting appears at 9 companies, prefix sum at 8, backtracking at 8, binary search at 7. These companies test the same underlying reasoning, just wrapped in different problem descriptions.

The remaining 10% are edge cases: specific data structure design problems, mathematical reasoning, or questions that combine two patterns in non-obvious ways. The 90% figure is approximate. Google occasionally tests patterns outside the top fifteen, particularly predicate search variants. But for coverage per hour invested, these fifteen give you the highest return by a wide margin.

💡 Tip

Codeintuition's learning path covers all 15 of these patterns (and 60+ more) with explicit identification training before any problems begin. The ordering ensures you don't attempt a pattern until its prerequisite concepts are solid.

The Gap Between Knowing a Pattern and Using It

You can know all fifteen patterns and still lose interviews. Plenty of engineers do.

They can name them, explain them, write the template from memory. But when they see an unfamiliar problem under time pressure, they can't identify which pattern applies. The problem doesn't say "use two pointers." It says "given an array of integers and a target, find two numbers that add up to the target." The connection between the problem's constraint features and the correct pattern has to happen in real time, with a clock running.

Pattern identification is a separate skill from pattern knowledge. It's the ability to read a problem's constraints and recognise which problem class it belongs to before you start coding. "Contiguous range" plus "optimise length" signals a variable sliding window. "Find nearest larger/smaller" signals a monotonic stack. "Shortest path, unweighted" signals BFS. These are learnable triggers, not guesswork.

Platforms generally don't teach this layer. They assume you'll pick it up through volume. Some engineers do, after hundreds of problems. But that's an expensive way to train a skill that can be taught directly through interleaving, practising pattern identification across mixed problem sets where consecutive problems require different patterns. Cognitive science research on interleaving (Rohrer & Taylor, 2007) found it's harder during practice but produces significantly better transfer to new problems compared to blocked practice, where you do all sliding window problems, then all two pointer problems, then all BFS problems.

Codeintuition includes an explicit identification phase for every pattern. Before you solve a single problem in a pattern category, you've already trained on the recognition triggers that tell you when it applies and when it doesn't. That's the layer that turns pattern knowledge into pattern reasoning.

Going Deeper

These fifteen patterns are the starting point, not the finish line. Each one branches into variants. Two pointers splits into direct, reduction, and subproblem forms. Binary search splits into standard, lower bound, upper bound, and predicate search. Dynamic programming alone contains a dozen sub-patterns from knapsack to matrix chain multiplication.

For the complete progression from first principles to advanced patterns, the how to master DSA guide covers the full path, including how patterns build on each other and what order to learn them in. For DP specifically, covers the ten most important DP sub-patterns with worked examples.

Go back to the monotonic stack derivation earlier in this article. The key wasn't the code. It was the invariant: the stack always holds elements in decreasing order, and each element gets popped exactly once. That single observation unlocked O(n) time and transferred to "largest rectangle in histogram" without any new memorization. Every pattern on this list works the same way. Own the invariant, and the problems that belong to that class stop being individual puzzles. They become instances of reasoning you've already built.

Codeintuition's free Arrays and Singly Linked List courses cover eight of the fifteen patterns listed above, including two pointers, both sliding window variants, and interval merging, each with the identification-first training described in this article. Start with the two-pointer invariant. Trace it on a problem like Three Sum until you can derive the convergence logic without looking at the template. Then move to the next pattern and repeat.

Do you want to master data structures?

Try our data structures learning path made of highly visual and interactive courses. Get hands on experience by solving real problems in a structured manner. All resources you would ever need in one place for FREE

Start Learning

Fifteen patterns cover roughly 90% of FAANG interview problems. That's the minimum for strong coverage. Beyond that, each pattern has variants. Two pointers alone splits into direct, reduction, and subproblem forms. Prioritise depth on the core fifteen before expanding to advanced sub-patterns.

Frequency counting using hash maps appears at the most companies, based on problem tags across Codeintuition's 450+ problem bank. LRU Cache, which combines hash maps with linked list design, is tested at 19 companies including every FAANG member. Two pointers and sliding window are close behind in frequency.

Memorising patterns gets you past recognition, but interviews test construction. You need to identify which pattern applies to an unfamiliar problem, then adapt the invariant to that problem's specific constraints. Engineers who memorise templates without understanding the underlying reasoning often freeze when the problem doesn't match their stored version exactly.

With deliberate, focused practice, most engineers can build working fluency across all fifteen patterns in 8 to 12 weeks. The timeline depends on your starting point and how much time you invest daily. The critical factor isn't calendar time but practice quality. Interleaving across patterns produces faster transfer than studying one pattern at a time.

An algorithm is a specific procedure, like binary search or Dijkstra's. A pattern is a reusable problem-solving framework that applies across many problems sharing the same constraint type. Binary search is both an algorithm and a pattern. The sliding window is a pattern but not a single algorithm. Patterns are the higher-level reasoning layer that tells you which algorithmic approach fits which problem class.