Why You Forget LeetCode Solutions (and a Review System That Fixes It)
You grind a hard problem for 40 minutes, finally get the green checkmark, and feel like you've learned it. Three weeks later the same problem shows up in a mock interview and your mind is blank. You're not lazy and you're not bad at this — you're running into the forgetting curve, and almost everyone doing LeetCode by volume hits it.
Here's what's actually happening, and a concrete review system that makes solutions stick without re-grinding hundreds of problems.
Why solved problems fade
Solving a problem once creates a weak memory trace. Without reinforcement, most of what you "learned" decays within days — the classic forgetting curve. Three things make LeetCode especially forgettable:
- Recognition ≠ recall. When you read an editorial or peek at a hint, the solution feels obvious. That's recognition. In an interview you need recall — pulling the approach out of an empty page. They're different skills, and only recall is tested.
- You memorized the "how," not the "why." If you remember the code but not why a heap was the right structure or why two pointers works on a sorted array, you have nothing to reconstruct from when the details slip.
- No second exposure. You solve problem #217, move to #218, and never see #217 again. One exposure is not enough for durable memory — for anything.
The fix: spaced retrieval, not re-reading
The two ideas that actually beat the forgetting curve are well-established in learning science:
- Active recall — test yourself by re-deriving the solution from scratch, instead of re-reading it. The effort of retrieval is what strengthens the memory.
- Spaced repetition — review at increasing intervals (e.g. a couple of days, then a week, then two weeks, then monthly). Each successful recall pushes the next review further out.
Put together: don't re-read your old solutions — re-solve them, on a schedule tuned to how well you remembered.
A practical review loop
For every problem you solve, do this instead of moving straight on:
- Write down the pattern and the "why," not the code. One or two lines: "Sliding window; expand right, shrink left when the window breaks the constraint." This is what you'll rebuild from later.
- Schedule a re-solve. A simple ladder that works:
- First review in ~2 days.
- If you re-solve it cleanly, push to ~1 week, then ~2 weeks, then monthly.
- If you struggle or blank, reset to ~2 days and climb again.
- On review day, re-derive from the blank page. No editorial, no old code. Rate how it went honestly — that rating drives the next interval.
The magic isn't any single interval; it's that you're retrieving under increasing difficulty, which is exactly what an interview demands.
Why "just do more problems" doesn't fix forgetting
More volume adds more weakly-encoded traces that all decay. Two people with 150 solved problems can be worlds apart: one grinded and moved on; the other reviewed mistakes, re-derived hard ones, and wrote down why each pattern worked. The second person walks into the interview with recall; the first with a number.
Depth and review beat raw count. (More on that in Solved 500 problems and still failing interviews.)
Make the system automatic
The reason most people don't do spaced review isn't that they disagree with it — it's that tracking "which problem is due, at what interval, based on how I did last time" by hand is tedious, so it never happens.
That's exactly what CodingPartner automates. You log an attempt, write a short structured reflection (the "why," your traps, your takeaways), and it puts the problem into a spaced review queue that resurfaces it right before you'd forget — sooner if you struggled, later as you master it. Instead of a pile of green checkmarks, you get problems that actually stay solved.
If forgetting is your bottleneck, that's the loop to build. It's free, sign in with Google, no credit card.