Why LeetCode is So Hard — and Why Grinding More Problems Won't Help

Alex Mateo — Tue, 21 Apr 2026 08:23:18 +0000

Here's why grinding leads to memorization, not understanding, and what to do instead.

You've solved 150 problems. You read the editorial. You watched the NeetCode video.

And then a slightly different problem appears in the interview and you blank.

It's not you. It's what you've been practicing.

The real reason LeetCode feels impossible

When developers say LeetCode is hard, they usually mean the problems are tricky or
they can't figure out the right approach. But there's a third reason nobody talks
about — LeetCode only shows you the answer, not the thinking.

Submit a solution. Green checkmark. Move on.

What the platform doesn't show you is what happened inside the algorithm: which
variable changed, why a pointer moved, what the data structure looked like at step 3.
You only ever see the output.

This matters because coding interviews don't test if you know the answer.
They test if you can explain the reasoning.

When an interviewer asks "why did you use a hashmap here?", the correct answer
isn't the solution — it's the thought process behind it. LeetCode trains you to
produce solutions. It doesn't train you to understand them.

What LeetCode shows you	What you actually need
✗ Input and output	✓ What the algorithm does at each step
✗ Runtime and memory stats	✓ Why a specific data structure was chosen
✗ Green or red checkmark	✓ How the state changes with each decision
✗ The accepted solution (after you fail)	✓ The intuition that transfers to new problems

That gap between "submitting a solution" and "understanding an algorithm" is why
LeetCode feels hard even after hundreds of problems.

What grinding actually does to your brain

The conventional advice is: do more problems. Grind 75, then 150, then 300.
The theory is that pattern recognition emerges from volume.

Here's the problem: pattern recognition requires understanding, not repetition.

You can't recognize that a problem needs a sliding window if you only know that a
previous problem that looked similar used a sliding window. That's memorization.

It breaks the moment the problem is phrased differently.

The grinding trap: You solve problem #47 and feel like you understand
two pointers. Three weeks later, a different two-pointer problem appears and
you can't start it. You go back and re-solve problem #47. The cycle repeats.
You're not building understanding — you're fighting the Ebbinghaus forgetting
curve with repetition instead of comprehension.

The developers who pass FAANG interviews typically haven't solved more problems
than the ones who fail. They've understood fewer problems more deeply.

The difference between memorizing and understanding

Here's a concrete example. Most developers who have done LeetCode know Two Sum.

Ask them to solve it: they'll write a hashmap solution in two minutes.

Now ask them: "If the input array is sorted, which approach is better?"

Many will still reach for the hashmap — because that's what they practiced.
They memorized the solution, not the reasoning behind choosing it.

Understanding means being able to trace through the algorithm at each step:

nums = [2, 7, 11, 15], target = 9

Step 1: L=0, R=3 → sum = 2+15 = 17 > 9
        → Too large. Move R left.
        → WHY: sorted array, moving R left always decreases sum.

Step 2: L=0, R=2 → sum = 2+11 = 13 > 9
        → Still too large. Move R left again.

Step 3: L=0, R=1 → sum = 2+7 = 9 ✓
        → Found it.

Key insight: sorted input makes two pointers strictly better than hashmap.
O(n) time, O(1) space vs O(n) space. The code is almost identical —
the understanding is completely different.

The difference isn't the code. It's being able to explain why the approach
changes when the input is sorted.

Understanding an algorithm means answering 3 questions at any step

What is the current state? Where are the pointers, what's in the queue,
what does the data structure look like right now?
Why did the last step happen? What condition triggered this move,
this push, this comparison?
What will happen next? Given the current state, can you predict the
algorithm's next decision before it happens?

You can't answer any of these by reading the accepted solution. You need to
see the algorithm run.

What to do instead of grinding

1. Learn patterns, not solutions

Most coding interview problems are variations of 7-10 core patterns: Sliding Window,
Two Pointers, BFS, DFS, Binary Search, DP, and Dijkstra. Learn them at the
pattern level — not the problem level. When you recognize the pattern, the
solution follows.

2. See execution, not just code

Before writing anything, trace through the algorithm manually. Watch the state
change. Understand why each step happens. Only then write the code.

3. Solve fewer problems, more deeply

One deeply understood problem — where you can explain every step, every decision,
every tradeoff — is worth more than 10 memorized solutions.

4. Practice explaining out loud

After solving, close the editor and explain the solution as if talking to an
interviewer. If you can't explain why each line exists, you memorized it.

FAQ

Is LeetCode worth it?

LeetCode is worth it if you use it to build understanding, not just to accumulate
solved problems. Used correctly — slowly, with deliberate tracing — it's a useful
problem bank. Used as a grinding machine, it builds recall that breaks under
interview pressure.

How many LeetCode problems do I need for Google or Meta?

There's no magic number. Being able to trace 50 algorithms step by step and explain
every decision beats having memorized 300 solutions. Interviewers evaluate your
reasoning, not your problem count.

What is grinding LeetCode?

Grinding LeetCode means solving a high volume of problems (150-300+) with the goal
that pattern recognition emerges from volume. It's the dominant prep approach, but
it fails when problems are phrased differently or when interviewers ask you to
explain your reasoning.

I built Expora specifically because I was that developer —
I had Grokking Algorithms, the algorithm bible, three courses, and 200 LeetCode
problems solved. I still froze in interviews because I was memorizing, not
understanding.

Expora's visual debuggers let you step through algorithms one operation at a time —
watching the graph update, the queue fill, the dp table populate — with your own
code. It's the difference between reading about an algorithm and watching it think.

If you've ever felt like grinding isn't working, you're probably right.
The problem isn't your intelligence — it's the feedback loop you're practicing in.

Originally published at tryexpora.com/blog/why-leetcode-is-hard