Most people prepare for coding interviews by grinding through problem after problem, hoping to have seen something close enough on the day. It sort of works, but it’s slow and it’s fragile — the moment you get a problem you haven’t seen, you’re stuck.
There’s a better mental model: interviewers don’t have infinite questions. Almost every problem is a variation on a small set of patterns. Learn to recognize the pattern, and a “new” problem becomes a “which of these five approaches applies here” problem. That’s a much smaller thing to hold in your head under pressure.
Here are the patterns worth knowing, and the tells that point to each one.
1. Two pointers
The tell: a sorted array (or one you can sort), and you’re looking for a pair, triplet, or a subarray that meets some condition.
Instead of a nested loop checking every pair (O(n²)), you walk two pointers inward or in the same direction, using the ordering to skip work. Classic uses: “find two numbers that sum to a target,” “remove duplicates in place,” “is this a palindrome.”
Why it comes up: it’s the simplest example of using structure (sortedness) to beat brute force, so interviewers love it as a warm-up.
2. Sliding window
The tell: “longest / shortest / maximum sum” of a contiguous subarray or substring.
A window expands to include new elements and contracts when a condition breaks, so each element is visited at most twice — O(n) instead of recomputing every window from scratch. Classic uses: “longest substring without repeating characters,” “maximum sum subarray of size k.”
Why it comes up: it’s the go-to when brute force would recompute overlapping ranges, and recognizing it instantly separates prepared candidates from the rest.
3. Hashing / frequency maps
The tell: “have I seen this before?”, counting occurrences, or needing O(1) lookups.
A hash map (or set) trades memory for speed, turning an O(n²) “check everything against everything” into a single O(n) pass. Classic uses: “two sum” (unsorted), “find the first non-repeating character,” “group anagrams.”
Why it comes up: it’s the single most common way to drop a time complexity by an order of magnitude, so it shows up everywhere.
4. Binary search
The tell: a sorted input — or a problem where you’re searching for a number in a range and can check “is this answer too big or too small?”
The second case is the one people miss. “Binary search on the answer” applies to problems that don’t look like search at all, like “minimum capacity to ship packages in D days.” If you can phrase it as “find the smallest value that works,” binary search often applies.
Why it comes up: it’s the canonical O(log n) tool, and the “search on the answer” twist is a favorite for separating strong candidates.
5. Breadth-first and depth-first search
The tell: anything shaped like a tree, a graph, a grid, or “explore all connected things.”
BFS explores level by level (best for shortest-path-in-unweighted problems), DFS goes deep first (best for “does a path exist,” backtracking, and exhaustive exploration). Classic uses: “number of islands” in a grid, “shortest path in a maze,” tree traversals of every kind.
Why it comes up: a huge fraction of “medium” problems are just a traversal wearing a costume. Once you see the grid-as-graph trick, they collapse into the same solution.
6. Dynamic programming
The tell: “count the number of ways,” “find the min/max cost,” or a problem where the answer builds on answers to smaller subproblems that repeat.
DP is the hardest pattern and the one most people over-fear. The core move is always the same: define the subproblem, find the recurrence (how a bigger answer is built from smaller ones), then either memoize the recursion or fill a table bottom-up. Classic uses: “climbing stairs,” “coin change,” “longest common subsequence.”
Why it comes up: it’s the ceiling — interviewers use it to probe how you break a hard problem into pieces. Even partial progress (stating the recurrence) scores points.
How to actually use this
The patterns aren’t the whole job — recognizing them fast is. A practical prep loop:
- Do a handful of problems per pattern, not a hundred random ones. Five or six per pattern is enough to internalize the tell.
- After each problem, name the pattern out loud. “This was sliding window because we needed the longest contiguous run.” That labeling habit is what transfers to new problems.
- When you get stuck, don’t jump to the solution — jump to the pattern. Ask “which of the six does this smell like?” first. You’ll be right more often than you’d expect.
Talk while you solve
Here’s the part pure problem-grinding doesn’t prepare you for: in a real interview, how you think out loud matters as much as whether you get the optimal solution. Interviewers are evaluating how you decompose a problem, how you handle a hint, and whether you can reason about trade-offs — not just whether you produce working code in silence.
That’s a performance skill, and like any performance skill it needs rehearsal under something resembling real conditions. InterviewLand AI includes coding challenges built into your prep flow, so you can practice narrating your approach — pattern, trade-offs, edge cases — the same way you’ll need to on the day. Pair that with realistic mock interviews and instant AI feedback, and you’re training the whole skill, not just the algorithm half.
And when a curveball still lands mid-interview, the Interview Copilot is built for exactly that gap — the moment between hearing an unexpected problem and needing a place to start.