Recall Coding: Redo Your Hardest Problems From Memory

The idea, in one line

Recognising an answer is not the same as being able to produce one. In the room you get a blank editor, so practise from a blank editor.

The drill, step by step

1. Pick the 10 hardest problems you've solved in the last six months — the ones that made you sweat.
2. Don't reopen your old code.
3. Set a 30–40 minute timer and rebuild each solution from a blank file, out loud, as if someone were watching.
4. Only when the timer ends do you compare against your saved answer.

Grade yourself honestly

• Green — solved cleanly.
• Yellow — solved, but slow or buggy.
• Red — got stuck.

Anything that isn't green goes back in the pile and gets repeated a few days later. That gap between tries is the whole trick — it's what moves a solution into long-term memory instead of short-term.

Advanced — keep it warm during application season

The habit doesn't stop when you start applying. One recall problem a day keeps your syntax and pattern-spotting warm, so a busy two-week gap never resets you back to square one. A simple log keeps you honest:

problem,pattern,date,grade,min,note
two-sum-variant,hashmap,2026-07-13,green,12,clean
lru-cache,linked+dict,2026-07-13,red,40,forgot eviction order
word-ladder,BFS,2026-07-14,yellow,33,off-by-one on visited
merge-k-lists,heap,2026-07-14,green,18,ok

# Rule: any red or yellow is re-queued 3 days later.
# green = clean | yellow = slow/buggy | red = stuck

Grounded in the Tech Interview Handbook (coding-interview-prep) and spaced-recall practice principles