You Learned the 7 Patterns. The Hard Problems Combine Them.

I spent two months drilling the seven patterns until I could name any of them on sight. Sliding window, two pointers, BFS, DFS, binary search, DP, Dijkstra. Show me a problem, I tell you the pattern. I felt ready.

Then I got a medium in a real interview that asked for the longest substring with at most k distinct characters. I recognized the sliding window instantly. And then I stalled, because the window was the easy half. The actual difficulty was tracking the distinct count fast enough to know when the window became invalid, and that part was not sliding window at all. It was a hashmap doing bookkeeping inside the window.

The problem needed two patterns at once. Every course I had taken taught them one at a time, in separate chapters, as if real problems arrive pre-labeled with a single answer. They do not. The medium and hard problems, the ones that actually decide interviews, almost always stack two patterns on top of each other.

Nobody had taught me how to see the stack.

Why single-pattern training leaves a blind spot

Pattern courses are organized by pattern. One chapter for sliding window with ten sliding window problems. One chapter for binary search with ten binary search problems. You finish each chapter feeling like you understand the pattern, and you do.

But the structure of the course quietly teaches you something false: that each problem maps to exactly one pattern. Inside the sliding window chapter, every problem is a sliding window problem, so you never have to ask whether it might be something else, and you never have to handle the part of the problem that the window alone does not solve.

Real problems are not sorted into chapters. A hard problem is usually one pattern wrapped around another. An outer structure that drives the overall approach, and an inner operation that the outer structure keeps calling. If you only trained on pure single-pattern problems, you recognize the outer layer and freeze on the inner one, the same way I did.

The mental shift: stop labeling, start decomposing

For pure problems, the right question is "which pattern is this?" For hard problems, that question actively hurts you, because the honest answer is "two of them," and a brain looking for one label rejects that answer and keeps searching.

The better question has two parts. What is the outer structure that organizes the whole solution? And what is the repeated sub-question that the outer structure has to answer at every step?

The outer structure is the driver. The inner sub-question is what you optimize. Each one is a pattern you already know. The skill at the medium and hard level is not recognizing a new pattern. It is decomposing a problem into two familiar ones and noticing which is the driver and which is the helper.

Once you see problems as two layers instead of one label, the hard ones stop feeling like a different species.

The combinations that show up again and again

There are not many of these. A handful of combinations cover the large majority of two-pattern problems, and once you have seen each one explicitly, you start spotting them.

Sliding window plus a hashmap. The window is the driver. The hashmap answers "is this window still valid" in constant time. Longest substring without repeating characters, minimum window substring, and longest substring with at most k distinct characters are all this exact stack. The window moves, the hashmap tracks state. People who only learned the window get stuck on the bookkeeping.

Binary search plus a feasibility check. This is the one most people miss entirely. The driver is binary search, but not on the array. You binary search on the answer. The inner sub-question is a greedy or linear check that asks "is this candidate answer feasible?" Koko eating bananas, capacity to ship packages within d days, and split array largest sum are all binary search on the answer with a greedy validator inside. If you only think of binary search as searching a sorted array, you will never see it here.

DFS plus memoization. Most top-down dynamic programming is literally this combination. DFS explores the decision tree. Memoization kills the repeated work. If you can write the brute-force recursion, you are one cache away from DP. Seeing DP as "DFS that remembers" demystifies a pattern people are scared of.

Traversal plus a heap. Dijkstra itself is BFS with a priority queue swapped in for the plain queue. Network delay time and path with minimum effort are graph traversals where the driver is the search and the helper is a heap that always hands you the cheapest next node. The traversal is familiar. The heap is what makes it correct under weights.

Sorting plus two pointers. Three sum is the classic. Sort first, then fix one element and run two pointers on the rest. The sort is not incidental. It is what makes the two-pointer convergence valid. Two layers, one enabling the other.

Backtracking plus pruning. N-queens and combination sum are DFS that builds a candidate incrementally, with a constraint check that cuts dead branches before you waste time on them. The DFS is the driver. The pruning check is what turns an exponential mess into something that finishes.

Six combinations. Learn to see these and most "hard" problems reveal themselves as two easy ideas stacked.

How to decompose one in real time

When a problem resists a single label, do not push harder on the label. Switch to decomposition.

First, find the driver. Ask what shape the overall solution has. Am I scanning a range? Searching a space of answers? Walking a graph? Building something piece by piece? That answer is your outer pattern.

Second, find the repeated sub-question. Inside that driver, what do I have to compute over and over? Whether a window is valid. Whether a candidate answer works. The cheapest unvisited node. The answer to a smaller version of the problem. That repeated question is your inner pattern.

Third, pick a known pattern for each layer and connect them. The driver calls the helper. That is the whole solution.

This is what experienced engineers do without narrating it. They do not see "a hard problem." They see a binary search whose check function happens to be greedy, and they solve each layer with a tool they already trust.

How to practice the stacking specifically

You will not build this from more single-pattern problems, because those never force the second layer. You build it by changing what you write down.

When you finish a medium or hard problem, do not just note "sliding window" or "DP." Write both layers. "Outer: sliding window. Inner: hashmap for the distinct-character count." "Outer: binary search on the answer. Inner: greedy feasibility check." Naming both layers every time trains your brain to expect two, so that in the interview you are not thrown when one label is not enough.

The problems that needed two patterns and that you initially saw as one are the most useful entries in that log. They show you exactly where your decomposition is weak.

It also helps enormously to watch each individual pattern run before you try to stack them. When you have actually seen how a window expands and contracts, how binary search narrows a range, how a DFS unwinds, the layers become concrete objects you can picture combining rather than abstractions you are juggling. If you want to step through each of the coding interview patterns with live state visible at every move, Expora runs all seven interactively, which makes the moment they start nesting inside each other a lot easier to follow.

The reframe

The seven patterns are not the finish line. They are the vocabulary. Hard problems are sentences built from that vocabulary, and the skill that separates candidates at the medium and hard level is not knowing more words. It is reading two-word sentences without freezing on the second word.

Stop collecting patterns. Start stacking them.