The Pattern Trigger Catalog: How a Coding Problem Statement Gives Away Its Algorithm

There's a sentence I keep coming back to when coaching people on coding rounds, and I first wrote it down in Talk While You Code: "X makes me think of Y" might be the highest value thing you can say in a coding interview. Enough people have asked for the actual X's and Y's that the mapping deserves its own article. What follows is the catalog: eight signals that show up in problem statements, the pattern each one points to, why the fit works, and one canonical problem to anchor each trigger in your memory.

The reason the sentence scores so well comes down to what an interviewer can actually grade. Having sat on that side of the table for a lot of coding loops, I can tell you pattern recognition is on nearly every rubric, and it's invisible unless you make it audible. A candidate who reads the prompt and says "contiguous substring with a condition, that suggests sliding window" has just let me grade the recognition step directly, in real time. A candidate who goes quiet and then writes the right pattern leaves me guessing whether they recognized the shape or had memorized the problem, and that guess has ended up in debrief notes I've written. Saying the trigger removes the doubt, even on the occasions the first instinct turns out wrong.

The skill itself has a lot in common with reading terrain in the backcountry. Nobody navigates by carrying a memorized photograph of every trail they might ever walk; you learn what the conditions are telling you (a drainage that tightens between steep walls, a treeline that gives out earlier than the map suggested) and you read the ground ahead as you go. You cannot see every interview problem ahead of time, and you don't need to, because the conditions that produce a sliding window problem repeat themselves, and they're printed directly in the statement if you know what to look for.

Sorted input: two pointers or binary search

"Given a sorted array" is expensive information handed to you for free, and it's rarely there by accident (sorting costs n log n, so an author who pre-pays it is pointing at something). Order buys you two things: the ability to throw away half the remaining search space per step, which is binary search, and the ability to move two pointers inward while knowing exactly how each move changes your sum or condition. Canonical problem: Two Sum II. Questions asking for a threshold ("the first version that fails," "the minimum speed that still works") are the binary search flavor, sometimes over the answer space itself rather than over an array.

Contiguous substring or subarray with a condition: sliding window

Contiguous is the load-bearing word. When the thing being optimized must be a single unbroken run, a window sliding across the input only ever changes at its two edges, which lets you maintain the condition incrementally rather than recomputing it for every candidate range. That edge-only property is the entire jump from quadratic candidates down to a single linear pass. Canonical problem: Longest Substring Without Repeating Characters, which is also the problem I used for the two narrations in the talking-while-coding article.

Top k, kth largest, or streaming min/max: heap

This smell appears whenever the question concerns a boundary element and a full sort would be more order than you need. A heap keeps precisely that boundary available at logarithmic cost per update, which is most valuable when elements keep arriving (a stream) and sorting on every arrival would be wasteful. Canonical problem: Kth Largest Element in a Stream. Top K Frequent Elements is the same trigger with a frequency map bolted onto the front.

Shortest path, minimum steps, or level order: BFS

Breadth-first search explores in rings of increasing distance, so the first time it reaches the goal it has provably used the fewest steps (in an unweighted graph). The version that catches people is the disguised one: any "minimum number of moves to turn this into that" question is a graph problem where states are the nodes and legal moves are the edges, even when nothing in the statement mentions a graph. Canonical problem: Word Ladder. Level order and nearest-node questions on trees run on the same machinery.

Generate all combinations or permutations: backtracking

The word "all" is the primary signal, because generating every valid arrangement means enumerating a decision tree: choose, recurse, un-choose, move on to the next option. The secondary signal hides in the constraints, where a suspiciously tiny bound on n (somewhere around 15-20) is the author conceding that the output is exponential and inviting you to enumerate anyway. Canonical problem: Permutations, with Subsets as the gentler introduction to the identical shape.

Count the ways, or optimize over a sequence of choices: dynamic programming

Counting paths and maximizing value over choices share a structure: the answer for the whole input assembles from answers for smaller inputs, and plain recursion ends up revisiting those smaller answers repeatedly. The question worth asking out loud in the room is whether the answer for n can be phrased in terms of answers for smaller n; if it can, memoization or a table follows naturally. Canonical problem: Climbing Stairs for the counting flavor, with Coin Change as the minimize-over-choices sibling.

Connectivity and grouping: union-find or DFS

Questions about how many groups exist, or whether two things belong to the same one, reduce to connected components almost every time. DFS floods a component from any starting cell and is usually the quicker one to write under pressure; union-find justifies itself when connections arrive incrementally or when the merging is the actual point of the problem. Canonical problem: Number of Islands for the DFS version, and Accounts Merge if you want a case where union-find genuinely pulls ahead.

Parentheses, nesting, and the most recent open thing: stack

Nesting is inherently last-in-first-out. Whatever needs resolving next is always the thing opened most recently, and a stack is that observation made concrete. Canonical problem: Valid Parentheses. The adjacent trigger worth its own entry is "next greater element" (or warmer, or taller), which points at the monotonic stack, with Daily Temperatures as the standard rep.

How to drill triggers

1. Say the trigger before you code, out loud, on every practice rep, even alone. The reflex you want on interview day only forms through repetition of the actual sentence, and it will feel a little theatrical for the first week or so, which is normal.
2. Make flashcards of the smells rather than the solutions. The front holds the statement phrase ("longest substring such that..."), the back holds the pattern and one sentence on the why. Recognition does emerge eventually from grinding volume, but the flashcards train the exact step you'll be graded on, in minutes a day.
3. Run recognition-only sessions. Take ten statements, name the pattern and the reason for each in one sentence, check against the tags, and deliberately solve nothing. This slots neatly into the daily coding block of a structured prep plan without displacing your full-solution reps.
4. Treat every trigger as a prior rather than a verdict. Interviewers sometimes select problems specifically because the surface smell misleads, and the strong response is to name the trigger and then verify it ("sorted input suggests binary search, so let me confirm the condition is monotonic before committing"). A misnamed trigger said aloud gets corrected within a minute; a silent wrong turn surfaces ten minutes later, with the clock mostly gone.

If nothing lights up yet when you read a statement, don't be too hard on yourself. This is a trained sense, the same way reading terrain is, and it responds quickly to deliberate recognition reps in a way that raw problem volume responds only slowly.

None of this requires anything paid. A deck of smell cards, ten recognition-only minutes a day, and a friend willing to read you problem statements cold will build the sense within a few weeks. If you want reps where something reads you the problem, listens for the trigger, and pushes back when the smell is a decoy, that's the kind of practice we built Preppable around. Either way, make a habit of saying the trigger before you write code, because it takes a few seconds and it's some of the strongest signal you can hand the person grading you.