Somewhere around problem 200 on my LeetCode grind, I noticed I was solving the same problem with different variable names and calling it progress. A recruiter screen for a mid-level backend role asked me to find the longest substring without repeating characters, and I froze for a solid twenty seconds before my brain connected it to a sliding window problem I'd done three weeks earlier under a completely different title. I got there, but slower than someone who'd actually understood the pattern would have. That was the moment I stopped counting solved problems and started counting patterns understood, which turned out to be a much smaller and more useful number.
There are maybe a dozen patterns that cover the overwhelming majority of what gets asked in a 45-minute technical screen. Here's what I actually track when I'm prepping someone for interviews now, roughly in the order they show up.
Two pointers. Anything involving a sorted array, a palindrome check, or "find a pair that sums to X" is reaching for two pointers before it's reaching for a nested loop. The tell in an interview is when someone starts writing an O(n²) brute force and the interviewer asks "can we do better than that" — that's your cue the sorted-array assumption matters. A weak candidate brute-forces it and stops there. A strong one says out loud "since it's sorted, I can move pointers from both ends" before writing a line of code.
Sliding window. This is the one I froze on. Any "longest/shortest substring or subarray that satisfies some condition" problem — no repeating characters, sum equals K, at most two distinct characters — is sliding window. The pattern is: expand the right pointer until the window breaks the condition, then shrink from the left until it's valid again. People who've only memorized the code for one specific sliding window problem get stuck the moment the condition changes shape, because they never internalized that the window's job is just "track the largest valid range as you scan once."
Fast and slow pointers (Floyd's cycle detection). Linked list cycle problems, finding the middle of a list in one pass, detecting a repeated number in an array treated as an implicit linked list. This one's less common than the first two but it's a great filter question because there's basically no way to stumble into the right answer without having seen the trick before — either you know slow moves one step and fast moves two, or you don't.
Merge intervals. Meeting room scheduling, overlapping intervals, inserting a new interval into a sorted list. The wrong answer people give is trying to handle overlaps with a bunch of if/else branches instead of the actual insight, which is: sort by start time first, then a single pass where you either extend the current interval or start a new one. I've watched candidates write forty lines of conditional logic to avoid a five-line loop because they didn't sort first.
BFS/DFS on trees and graphs. Level-order traversal, number of islands, course schedule (topological sort in disguise). The distinction that separates people who've internalized this from people who've memorized a template: can they explain why BFS is the right call for "shortest path in an unweighted graph" and DFS is the right call for "does a path exist at all" — not just recite that both exist.
Binary search on the answer, not just on a sorted array. This is the pattern that trips up otherwise-strong candidates the most, because it doesn't look like binary search at first. "Minimum days to make M bouquets," "capacity to ship packages within D days" — these aren't searching an array, they're binary-searching a range of possible answers and checking feasibility at each midpoint. If someone can explain "the answer space is monotonic, so I can binary search it" without prompting, that's a strong signal regardless of whether they nail the exact implementation.
Backtracking. Permutations, combinations, subsets, N-Queens. The interview differentiator here isn't whether someone can write the recursive skeleton — most people who've prepped at all can. It's whether they can identify pruning opportunities out loud, because an unpruned backtracking solution that technically works but explores way more of the search space than necessary is a common way to lose points even on a "correct" answer.
Dynamic programming, but specifically: can you find the recurrence. This is the one I'll push back on common advice for. Most prep guides tell you to memorize the top twenty DP problems. I think that's close to useless, because DP problems don't repeat verbatim in interviews the way two-pointer problems sort of do — what transfers is the skill of writing out the recurrence relation in plain English before touching code. "The answer at position i depends on the answer at i-1 and i-2" is a sentence, not a LeetCode problem, and once you can write that sentence for a new problem you've never seen, you've actually learned DP instead of memorized nine specific solutions.
Top-K / heap problems. Kth largest element, top K frequent elements, merge K sorted lists. The pattern-recognition trigger is any phrase with "top K" or "Kth" in it — that's a heap of size K, full stop, and the only real decision left is min-heap or max-heap depending on which end you're filtering from.
Union-Find (disjoint set). Number of connected components, redundant connection, accounts merge. Less common than the others but worth having ready because it's a clean, fast answer to a class of graph-connectivity problems that would otherwise take a much messier DFS-based solution, and using it unprompted signals real breadth.
What actually changed my hit rate wasn't grinding more problems — it was, for each new problem, writing one sentence before coding: "this is [pattern] because [specific reason]." If I couldn't fill in the reason, I hadn't understood the problem yet, I'd just pattern-matched the surface shape of it, which falls apart the second an interviewer tweaks the constraints. That single habit did more for me than the difference between 150 problems solved and 400.
One thing I'd push back on from most interview prep advice: doing untimed practice at home doesn't prepare you for the actual experience of explaining your thinking out loud while someone watches you type, which is a genuinely different skill from just solving the problem correctly on your own. I started running mock sessions with LastRound AI's live interview copilot specifically to practice narrating my pattern-recognition process under the same time pressure and social pressure as a real screen — https://lastroundai.com/products/ai-interview-copilot — because silently solving a sliding window problem on your couch and explaining your reasoning to a stranger who's grading you in real time are not the same skill, and the second one is the one that actually gets you the offer.
The honest caveat: none of this replaces actually understanding the underlying data structures. Pattern recognition gets you to the right approach faster, but if you don't know how a heap or a hash map actually works under the hood, you'll pattern-match correctly and then fumble the implementation, which is its own kind of frustrating to watch as an interviewer.
Top comments (0)