I’ve talked to engineers who solved 300 LeetCode problems and failed every major tech interview, and engineers who solved 70 and got offers at Amazon and Stripe in the same month. The difference isn’t the number. It’s whether they were building transferable pattern recognition or just collecting solved problems.
That distinction is obvious in retrospect. It’s not obvious when you’re three months into a job search and the internet keeps telling you to grind more problems.
Why random problem volume doesn’t transfer
When you solve a problem you’ve seen before, you’re testing recall. When you solve a problem you haven’t seen before by recognizing which pattern it belongs to, you’re testing judgment. Interviewers are testing judgment. They have been for a while, and the trend has gotten more pronounced as it’s become common knowledge that LeetCode-easy problems were being memorized en masse.
The pattern-based approach has been documented in technical interview circles for years. The Stack Overflow Developer Survey 2024 found that algorithmic problem-solving is still the most common interview format at large tech companies, which means the underlying skill stays relevant even as specific platforms and preparation approaches shift.
There are roughly 15 patterns that cover the large majority of problems you’ll encounter in a typical interview loop. I’ll go through them in the order I think you should study them.
The patterns, in a sensible study order
1. Two Pointers. Start here. Two pointers are used for sorted arrays and linked list problems. The pattern: two indices moving toward each other (or in the same direction at different speeds). It solves “pair sum”, “remove duplicates”, “container with most water”, and about 47 other problems you’ll encounter. Once you see the mechanics, you recognize it in new problems fast.
2. Sliding Window. For problems involving contiguous subarrays or substrings. The window expands and contracts based on a condition. “Longest substring without repeating characters” is the canonical example. The key skill is knowing when to shrink the window, which is usually defined by the constraint in the problem.
3. Fast and Slow Pointers. Specifically for cycle detection in linked lists. Floyd’s cycle detection algorithm is the underlying concept. “Does this linked list have a cycle?” and “Find the start of the cycle” are both solvable with two pointers moving at different speeds. It shows up less frequently than Two Pointers but when it shows up, it’s often the whole problem.
4. BFS and DFS. These need to be in your hands simultaneously. BFS uses a queue and is right for shortest-path problems and level-order tree traversal. DFS uses a stack (or recursion) and is right for path-existence, connected components, and tree problems where you need to explore depth first. The mistake is learning one and treating the other as an afterthought.
5. Binary Search (modified). Not just “find an element in a sorted array.” Modified binary search applies to problems like “find the first true in a boolean array” or “search in a rotated sorted array.” The key is understanding that binary search works on any monotonic condition, not just sorted arrays with a literal target.
6. Merge Intervals. Sort intervals by start time, then merge overlapping ones. Appears in calendar scheduling problems, meeting room problems, insert interval. The pattern is simple once you internalize it, and the problems in this category tend to be medium difficulty with predictable structure.
7. Dynamic Programming. Put this later in your prep, not first, even though it feels important. Most DP problems are either memoized recursion (top-down) or tabulation (bottom-up). The hard part isn’t the code, it’s identifying the subproblem structure. Start with 1D DP (Fibonacci, climbing stairs, house robber), then move to 2D. The common mistake is trying to learn all DP variants simultaneously.
8. Two Heaps. For problems involving a “median” or “k-th largest” element in a stream. You maintain a max-heap for the lower half and a min-heap for the upper half. Rebalancing the two heaps gives you O(log n) median. This pattern comes up in maybe 3-4% of interviews but when it does, it’s often a medium-hard problem that separates candidates.
9. Topological Sort. For directed acyclic graphs where you need task ordering. “Course schedule” and any “dependencies before tasks” problem. The underlying algorithm (BFS-based Kahn’s algorithm or DFS-based postorder) is worth knowing both ways. Cycle detection falls out naturally from the topological sort algorithm, which is a bonus.
The remaining patterns (Cyclic Sort, In-Place Linked List Reversal, Subsets and Permutations, K-Way Merge, Top K Elements) are worth studying but have diminishing returns compared to the nine above. If you’re running short on prep time, the first seven carry most of the weight.
How to actually study this
For each pattern: learn the mechanics with two or three simple problems, then deliberately try a medium problem you haven’t seen. The goal is pattern recognition on the unseen problem, not just being able to execute the code. If you can’t look at a new problem and say “that’s a sliding window” within the first two minutes, you haven’t internalized the pattern yet.
6 weeks is a reasonable timeline if you’re doing 1-2 hours per day. Less time than that and you’re cramming, which doesn’t build recognition. More time than that with no real practice loops (timed, on a whiteboard or shared document with someone watching) and you’re building theory without interview-condition skill.
Real interview conditions are different from Leetcode practice in one specific way: you have to explain your thinking while you work. This is harder than it sounds. A lot of engineers can solve a problem in 20 minutes alone but go blank when asked to talk through their approach. Tools like Craqly can run mock technical rounds where you verbalize your approach as you work, which is the specific skill that collapses under pressure if you haven’t practiced it.
The thing everyone gets wrong about hard problems
Hard LeetCode problems in interviews are almost always combinations of two patterns, not one. “Design a data structure that supports O(1) insert, O(1) delete, and O(1) getRandom.” That’s a hash map combined with an array. “Find the kth largest element in a stream.” That’s modified binary search or a heap, depending on the constraints. Recognizing combinations is what makes a candidate look strong on hard problems.
If you’ve been grinding and not making progress, I’d genuinely bet the problem isn’t the number of problems you’ve solved. It’s whether your mental index of patterns is deep enough to match new problems to familiar structures. LinkedIn’s 2024 Jobs on the Rise data shows software engineering roles still list algorithmic problem-solving as a core screening criterion at most FAANG-adjacent companies. The pattern-based approach isn’t a shortcut. It’s just a more accurate model of what the interview is actually testing.
Stop grinding. Start recognizing.