Coding Interview Patterns You Should Know

Coding Interview Patterns You Should Know

Coding interview patterns are the reusable problem-solving shapes that appear again and again across interview questions. This guide is for anyone tired of grinding random problems with no system behind it. You will learn the core patterns worth knowing — two pointers, sliding window, hash maps, BFS/DFS, binary search, and a gentle on-ramp to dynamic programming — and, just as important, the signal that tells you which one to reach for.

Quick answer: The highest-value coding interview patterns are two pointers, sliding window, hash maps, BFS/DFS, binary search, and dynamic programming. Learn to recognize the signal for each — a sorted array, a contiguous subrange, a fast lookup, a graph or tree — and most medium problems become variations you have already practiced.

Why patterns beat grinding random problems

The most common preparation mistake is solving hundreds of random problems and hoping something sticks. Coding interview patterns fix that by giving you a mental index: instead of memorizing solutions, you learn to map a new problem onto a shape you already know.

A dozen patterns cover the large majority of medium-difficulty questions. Once you can name the pattern, the code almost writes itself, and you can spend your nerves on communicating instead of panicking. Here is a cheat sheet of the signals worth memorizing:

PatternSignal to watch for
Two pointersSorted array; find a pair or triple that meets a condition
Sliding windowLongest or shortest contiguous subarray or substring
Hash map“Have I seen this?”, counting, or fast lookup
BFS/DFSTrees, graphs, grids, connected components
Binary searchSorted input, or a monotonic yes/no condition
Dynamic programmingOverlapping subproblems; count or optimize choices

Two pointers

Two pointers walks two indices through a sequence — often one from each end, or a slow and a fast pointer. It shines on sorted arrays and linked lists, turning a quadratic brute force into a single linear pass.

Classic uses: find a pair that sums to a target in a sorted array, reverse or de-duplicate in place, or detect a cycle in a linked list. If the input is sorted and you are hunting for a pair or a triple, reach for two pointers first.

Sliding window

Sliding window is two pointers with a purpose: you grow a window to include more elements and shrink it to stay valid, tracking something as you go. It is the go-to for “longest” or “shortest” contiguous subarray and substring problems.

Think of the longest substring without repeating characters, or the smallest subarray with a sum of at least k. The signal is a contiguous range plus a constraint you can maintain cheaply as the window moves.

Hash maps for lookups

A hash map trades memory for speed, turning a repeated search into a constant-time lookup. Whenever a problem asks “have I seen this before?” or “how many times does this appear?”, a hash map is usually the answer.

Two-sum on an unsorted array, grouping anagrams, counting frequencies, or de-duplicating all fall to a single pass with a map. It is the most broadly useful pattern on this list, so make it second nature before anything else.

BFS and DFS

Breadth-first search (BFS) and depth-first search (DFS) are how you traverse trees, graphs, and grids. BFS explores level by level with a queue and finds shortest paths in unweighted graphs; DFS goes deep with recursion or a stack and suits exhaustive exploration.

Reach for these on anything shaped like a network or a maze: counting islands in a grid, the shortest path through a maze, level-order tree traversal, or detecting a cycle. If the problem mentions neighbors, connections, or levels, think BFS/DFS.

Binary search on the answer

Everyone knows binary search on a sorted array, but the sharper version is binary searching the answer itself. If you can phrase a problem as “is X feasible?” and feasibility is monotonic — true past some threshold, false before it — you can binary search for that threshold.

The minimum ship capacity to deliver packages in a fixed number of days, or the smallest divisor under a limit, both work this way. The signal is that you are minimizing or maximizing a value and can cheaply test whether a given value works.

Dynamic programming, gently

Dynamic programming (DP) intimidates people, but the core idea is simple: break a problem into overlapping subproblems and store each answer so you never recompute it. Start by finding a plain recursive solution, then add memoization — that alone solves most interview DP.

Climbing stairs, coin change, longest common subsequence, and the knapsack family are the classics. Do not try to master every variant; understand a handful deeply and you will recognize the rest. If a problem asks you to count the number of ways or optimize over a sequence of choices, suspect DP.

A practice plan

Study by pattern, not by random draw. A focused month or two of deliberate practice beats endless grinding with no structure.

  1. Learn one pattern at a time: read the idea, then solve five to eight problems that use it.
  2. After each solve, write one sentence naming the signal that pointed to the pattern.
  3. Once patterns feel familiar, mix them so you practice recognizing, not just executing.
  4. Redo your failures a week later — recall is the real test of learning.
  5. Finish with timed problems and, where relevant, take-home assignments.

This same pattern-first mindset carries into other rounds; the structure you build here makes system design feel a lot less alien too.

Frequently asked questions

How many coding patterns do I actually need?

Roughly eight to twelve core patterns cover the large majority of medium-difficulty problems. The ones in this guide are the highest-leverage starting set. Master those before chasing rare, exotic techniques.

Which programming language should I use?

Use the language you know best and can write fluently under pressure — usually Python, Java, C++, or JavaScript. Interviewers care about clear, correct thinking, not a specific language. Clarity beats cleverness every time.

How many problems should I do per pattern?

Five to ten well-understood problems per pattern is plenty to internalize it. Solving a few deeply, and being able to explain why the pattern fits, beats rushing through dozens. Depth compounds; volume alone does not.

What if I recognize the pattern but still cannot code it?

That is an execution gap, not a recognition gap, and it is common. Drill a clean template for each pattern until you can write it without thinking, then redo problems you failed. Speed and accuracy come from repetition, not talent.

Patterns turn a scary, open-ended problem set into a short, learnable list. Study them one at a time, name the signal every time you solve, and practice recognizing before executing. For the big picture, start with our cornerstone guide, and remember that steady, deliberate reps beat marathon cramming.

Last updated: July 6, 2026

Comments

Popular posts from this blog

The Tech Interview Prep Guide (Start Here)

System Design Interview Basics for Beginners