TL;DR: LeetCode feels brutally hard because it's designed around hidden insights, and most people train the wrong skill for it. They memorize solutions to individual problems when they should be training pattern recognition: the ability to look at a problem they've never seen and map it to one they have. This article explains why the grind fails, what pattern recognition actually looks like, and how to build it deliberately.
I spent years as a hiring manager at Meta and Microsoft, and I watched a pattern repeat in interview after interview. A candidate with a strong resume and real engineering skill would read the problem, go quiet, and start guessing. Not because they were weak engineers. Because the problem didn't look like anything in the mental library they'd built, even after months of grinding.
Then I'd see another candidate, sometimes with half the preparation time, glance at the same problem and say: "This looks like a sliding window problem, because we're optimizing something over a contiguous range." Ninety seconds in, they were already on the right road.
The difference between those two candidates is the subject of this article. But first, let's be honest about why LeetCode feels so hard, because the reasons matter for the fix.
Why LeetCode actually feels impossible
1. The problems are riddles, not exercises
Most of what you did in school and at work is procedural: apply a known method to a known type of task. LeetCode problems are deliberately not that. Almost every medium and hard problem hides a key insight, and until you find it, no amount of coding skill helps.
Take the classic "find two numbers in an array that sum to a target." The brute force is obvious. The insight (trade memory for speed with a hash map, or sort and walk two pointers inward) is not something you derive from effort. You either see it or you don't. That's why you can stare at a problem for an hour, peek at the solution, and think "I never would have gotten that." You're not wrong. You wouldn't have. Insights aren't generated by staring; they're recognized from experience with similar structures.
2. You're comparing yourself to the wrong people
The discussion tab and the runtime leaderboards are full of competitive programmers who have solved thousands of problems over many years. When your honest 40-line solution sits next to a 6-line one-liner exploiting a trick you've never heard of, the natural conclusion is "I'm not smart enough." The correct conclusion is "that person has seen this exact structure 50 times." You're watching recognition and mistaking it for genius.
3. Solving 500 problems doesn't mean learning 500 problems
This is the one nobody wants to hear. I've interviewed candidates who told me proudly they'd solved 400+ problems, and then couldn't handle a variation of a problem they had definitely solved before. Here's why: if you solve problems in random order, look at the solution when stuck, nod along ("that makes sense"), and move to the next one, you are training reading comprehension, not problem solving. Understanding a solution and being able to produce one are different skills, the same way understanding a chess grandmaster's move is different from finding it yourself.
4. The interview adds a layer LeetCode never trains
Even people who get comfortable on the site get wrecked in interviews, because the interview isn't a LeetCode session. There's a person watching. You have 35 minutes, not an afternoon. You're expected to think out loud, handle hints gracefully, and test your own code. LeetCode difficulty and interview difficulty overlap maybe 70%. The rest is performance under observation, which needs its own practice.
The missing skill: pattern recognition
Here's the thing that changed how I prepare candidates, and it comes from an old finding in cognitive science. Studies of chess masters found they don't calculate more moves than amateurs. They recognize board positions as instances of patterns they've seen before, and the right move suggests itself. Their advantage is a library of chunks, not raw processing power.
Coding interviews work exactly the same way. There are thousands of problems on LeetCode, but there are only about 27 underlying patterns that generate nearly all of them. Sliding window. Two pointers. Fast and slow pointers. Merge intervals. Top-K elements via a heap. BFS and DFS on trees and graphs. Subsets via backtracking. A handful of dynamic programming shapes. That's the whole secret. The people who make interviews look easy aren't solving new problems. They're recognizing old ones wearing costumes.
One pattern, three "different" problems
Look at these three problems, which seem unrelated on the surface:
- Find the longest substring with no repeating characters.
- Given an array of integers, find the maximum sum of any contiguous subarray of size k.
- You have baskets that hold only two types of fruit; walking down a row of trees, what's the longest stretch you can pick?
Different stories: strings, sums, fruit. But all three are asking the identical question: optimize something over a contiguous range of a sequence, where extending the range is cheap and shrinking it has a clear trigger. That's the sliding window pattern, and one mental template solves all three:
window_start = 0
for window_end in range(len(items)):
# 1. absorb items[window_end] into the window
# 2. while the window violates the constraint,
# shrink it from the left
# 3. update the best answer seen so far
Once you own this template and, crucially, can articulate the tell ("contiguous range" + "longest/shortest/max/min"), you don't experience these as three problems. You experience them as one problem, three times. Multiply that effect across 27 patterns and you've compressed thousands of problems into a learnable curriculum.
This is exactly how Grokking the Coding Interview is built: every chapter is one pattern, taught from its tell to its template to its variations, with practice problems grouped so the recognition sinks in. It's rated 4.6/5 by 62,000+ learners for precisely this reason.
How to actually build pattern recognition
Knowing patterns exist isn't enough; you have to train recognition deliberately. Here's the loop I recommend, refined from coaching hundreds of engineers:
1. Study one pattern at a time, in a block. Solve 5 to 8 problems that all share a pattern, consecutively. Yes, this feels artificial ("I already know it's sliding window!"). That's fine. Early repetition in a block is how the template gets into memory in the first place.
2. Write down the tell, in your own words. After each pattern block, force yourself to answer: "What features of a problem statement should make me suspect this pattern?" For two pointers: sorted input, pair-finding, in-place requirements. For top-K: the literal words "k largest," "k closest," "k most frequent." If you can't state the tell, you don't own the pattern yet, you've just visited it.
3. Then mix, and diagnose before solving. Recognition only develops against variety. After several pattern blocks, solve mixed problem sets, and make the first step of every problem an explicit diagnosis: read the statement and spend two minutes deciding which pattern and why before writing any code. This diagnosis step is the actual skill being tested in interviews, and it's the step the random-grind approach never isolates.
4. Struggle for 30 minutes, then study the solution like a post-mortem. Peeking early trains nothing; struggling for three hours wastes your life. Around 30 minutes is the useful maximum. When you do read the solution, the question to answer isn't "how does this work?" It's "what clue in the problem statement should have led me here?" That question is where recognition grows.
5. Re-solve failures a week later, from scratch. Spaced repetition works for problem solving the way it works for vocabulary. A problem you failed, then understood, then reproduced cold a week later, is a problem you own. A problem you failed and merely read about is a problem you'll fail again with different numbers.
6. Simulate the interview layer separately. Once or twice a week, solve one problem in 35 minutes, out loud, in a plain editor without autocomplete or a run button. Explain your approach before coding, narrate as you go, and test by tracing an example by hand. This feels ridiculous alone in a room. It is also the single cheapest way to close the gap between "good at LeetCode" and "good at interviews."
So how many problems do you really need?
Far fewer than you think, if they're organized by pattern: 100 to 150 problems, chosen to cover the 27 patterns with a few variations each, beats 500 random ones by a wide margin. The 500-problem grinder has seen more problems; the 150-problem pattern learner has learned more problems. In interviews I ran, I could tell within ten minutes which kind of preparation was in front of me.
And a note of reassurance: some LeetCode hards are genuinely hard, built on obscure algorithms (think segment trees or bit-manipulation DP) that almost never appear in real interviews at product companies. If a problem's solution requires an algorithm you've never heard of, skipping it is not weakness, it's prioritization.
The takeaway
LeetCode is hard because it tests insight, and insight can't be brute-forced; it has to be recognized. Recognition comes from a library of patterns, built deliberately: one pattern at a time, tells written down, mixed practice with explicit diagnosis, failures revisited. The engineers who walk into a FAANG interview calm aren't smarter than you. They've compressed the problem space from "thousands of problems" to "27 patterns," and that compression is entirely learnable.
Ready to stop grinding and start recognizing? Grokking the Coding Interview: Patterns for Coding Questions teaches all 27 patterns with hundreds of problems grouped for recognition, in Python, Java, JavaScript, C++, C#, and Go. It's the original patterns course, created by ex-FAANG hiring managers.
FAQs
Why is LeetCode so much harder than my actual job? Because they train opposite skills. Real engineering is mostly integrating known tools over days with full context. LeetCode compresses an insight-finding puzzle into 35 minutes with zero context. Being bad at LeetCode says nothing about your engineering ability; it says you haven't trained this specific skill yet.
Is it normal to be unable to solve LeetCode mediums? Completely. Most engineers can't solve unfamiliar mediums cold, because mediums are built around a hidden pattern insight. After studying that pattern deliberately, the same problems typically fall in 15 to 20 minutes.
How long does it take to get good at LeetCode? With random grinding, often 6+ months and it may never click. With pattern-based study (blocks, tells, mixed diagnosis, spaced review), most engineers are interview-ready in 8 to 12 weeks at 1 to 2 hours a day.
Should I memorize LeetCode solutions? Memorize templates and tells, never solutions. A memorized solution breaks the moment the interviewer changes one constraint. A pattern template plus the skill of recognizing when it applies survives every variation.
How many LeetCode problems are enough for FAANG interviews? Around 100 to 150, if they systematically cover the common patterns. Coverage and recognition matter; raw count doesn't.