I solved Two Sum, Valid Parentheses and Merge Intervals at least three times each before my first real interview loop. Not because I enjoyed them. Because every time I came back to LeetCode after a few weeks off, they felt brand new. I'd stare at the problem, get a vague "I've seen this" feeling, and still write the brute force.
If you've searched "how to remember LeetCode patterns" after failing a medium you swear you solved last month, this is for you. Grinding more problems didn't fix it for me. Changing what I did after each problem did.
Problem count is a bad scoreboard
The number on your profile feels like progress. 150 solved. 300 solved. But interviews don't ask whether you've seen a problem. They ask whether you can spot the shape of a new one in the first five minutes.
That's a recall problem, not a volume problem. If you solve 400 problems and can't retrieve the idea behind any of them under pressure, you've mostly practiced reading solutions.
I'd rather someone solve 120 problems and be able to explain, from memory, why each one is a sliding window or a monotonic stack.
Learn patterns, then file problems under them
Most interview problems fall into a smallish set of patterns: two pointers, sliding window, binary search on the answer, BFS and DFS on grids, topological sort, heaps for top-k, intervals, monotonic stack, union-find, and the usual DP families like knapsack and longest common subsequence.
When I finish a problem now, I don't just mark it done. I write one line that says which pattern it is and what gave it away. Something like:
Longest Substring Without Repeating Characters: sliding window. Clue: "longest contiguous" plus a constraint I can track with a set.
That second half is the useful bit. The clue is what you'll need in the interview, because the new problem won't have the same name.
Write the "why", skip the code
My old notes were pasted solutions. I never reread them, and when I did, I'd nod along without learning anything. Reading code you already understand is about the lowest-effort review there is.
Now each problem gets three short things in my own words:
- The pattern and the clue.
- The one insight that made it click. For Trapping Rain Water, that's "water at each index depends on the smaller of the max to its left and the max to its right."
- The mistake I made first. Off-by-one in the window shrink, forgot the empty input, whatever it was.
That's maybe 40 words. The code lives on LeetCode anyway.
Re-solve, don't reread
Here's the part that actually moved my numbers. A few days after solving a problem, I try it again from a blank editor. No peeking at my old submission.
Sometimes I fly through it. Sometimes I get stuck in exactly the same place as before, which tells me I memorized the answer instead of the idea. Either way I learn something, and it costs ten minutes instead of the forty the first attempt took.
This is just active recall applied to code. Pulling something out of memory is what makes it stay there. Looking at it again doesn't do much.
Space the reviews out
The other half is timing. If you re-solve everything the next morning, it's too easy and you're wasting time. If you wait two months, you're starting from scratch.
Spaced repetition handles this. Review a day later, then a few days after that, then a week, then a couple of weeks, then a month. Each successful review pushes the next one further out. Problems you keep fumbling come back sooner. I wrote up how the SM-2 spaced repetition algorithm works in JavaScript if you want to see the scheduling logic or roll your own.
A plain spreadsheet with "last reviewed" and "next review" columns works fine for this. So does Anki with one card per pattern clue. The tool matters less than actually showing up for the reviews.
Don't forget the explanations you watched
A lot of my pattern knowledge didn't come from LeetCode at all. It came from a NeetCode video on why binary search works on a sorted answer space, a 12-minute YouTube breakdown of union-find with path compression, a blog post that finally made bottom-up DP make sense.
I saved all of those. Then I never opened them again. That's the gap I built Recl to fill.
You share a video, reel, podcast or article to Recl from your phone or the Chrome extension. It writes a summary of the key ideas (with timestamps for videos), files it under a topic, and brings those ideas back to you 1, 3, 7, 14, 30 and 60 days after you saved them. So that union-find explanation shows up again a week later instead of rotting in a playlist.
The part I lean on most during interview prep is Ask. You can question your own saves, so "what did I save about monotonic stacks?" pulls up the specific videos and posts I watched, with sources, instead of me searching YouTube history for the one with the good diagram.
Recl won't solve problems for you, and it's not a LeetCode tracker. I still re-solve problems in a blank editor. It just keeps the explanations I learned from in rotation alongside them.
A week that works
Here's roughly what my prep looked like once I stopped grinding blindly:
- Two or three new problems a day, picked by pattern, not at random.
- One-line pattern note plus insight plus first mistake for each.
- Ten to fifteen minutes re-solving whatever was due for review.
- Any good explanation video or article saved somewhere that'll bring it back.
It's fewer new problems than I used to do. My solve count grew slower. But the next time I saw a problem about the longest window with at most k distinct characters, I knew what it was before I finished reading it, and that's the only number that showed up in the interview.
I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.
Top comments (0)