How to remember DSA problems
You forget DSA problems because you solve each one once and never have to produce it again. It doesn't matter whether you practice on LeetCode, GeeksforGeeks or from a DSA sheet. The fix is spaced repetition: re-solve each problem from scratch at growing intervals (a day, a few days, a week, a month), each timed for just before you would forget it.
By Abhay ·
Why you forget solutions you understood
Memory fades on a curve: sharply at first, then more slowly. A DSA problem you solved last week feels familiar, but familiarity is recognition, and an interview asks for recall: producing the approach on a blank screen, under time pressure. Reading the editorial again rebuilds recognition. Only retrieving the idea yourself strengthens recall.
Each successful retrieval also slows the next round of forgetting. That's why the gaps between reviews can keep growing, and why a problem you've re-solved three or four times tends to stay with you for months.
A DSA revision method in five steps
- Solve it with a time box. Around 20 minutes for an easy, 40 for a medium and 60 for a hard is a reasonable starting point. Past that, read a hint and note that you needed one.
- Write down the core idea. One or two sentences on the insight that unlocks the problem, not the code. Add what went wrong.
- Rate it honestly. Solved cold, solved with a hint, or couldn't solve it. This one rating decides when you see it again.
- Re-solve it when it's due. From a blank editor, without looking at your old code. Check your notes afterwards, not before.
- Let the gaps grow. Each clean re-solve pushes the next review further out. A failure brings it back soon, which is exactly where it should be.
How often should you revise a DSA problem?
It depends on how the last attempt went. A typical progression looks like this; a scheduler adjusts the exact days per problem from your own history.
| Last attempt | Next review | If it goes well after that |
|---|---|---|
| Couldn't solve it | Tomorrow | A few days, then about a week |
| Solved with a hint | In 2–3 days | About a week, then a few weeks |
| Solved cold | In about a week | A few weeks, then a couple of months |
Illustrative intervals. Actual gaps vary per problem and per person.
What to write in your notes
Your DSA log only needs two notes per problem, short enough to check in under a minute. For LRU Cache (LeetCode 146), for example:
get.Quick recall vs. full re-solve
Not every review needs code. For a problem you've solved cleanly several times, a quick recall check is enough: read the title, say the approach out loud, then compare with your notes. That takes a few minutes. Save full re-solves, about 25 minutes each, for problems you struggled with or haven't coded in a long time.
Where DSA sheets fit in
DSA sheets, and LeetCode lists like NeetCode 150, Blind 75 and Grind 75, answer what to solve first. Spaced repetition answers what to solve again. Use a sheet to choose new problems, and let the revision schedule decide when each one you've done comes back.
One DSA log across every platform
Most people practice in more than one place: LeetCode for interview problems, GeeksforGeeks for concepts, a course or a DSA sheet on the side. Keep one DSA log across all of them, so a single schedule decides what to revise each day instead of one tracker per platform.
Why a spreadsheet isn't enough
A DSA tracking spreadsheet records what you've done, but it can't tell you what you're about to forget. Working out due dates by hand for a few hundred problems is where most tracking sheets get abandoned. A scheduler does that part for you.
Doing this with Hash-It
Hash-It is a DSA tracker built around this method. Press ⌘K after solving a problem to log the time, core idea and mistakes. It schedules each review with FSRS and builds a daily queue split into quick recalls and full re-solves. Already solved a lot? Upload your DSA sheet as a CSV or Excel file, or import your history from a screenshot of your LeetCode progress page.
Frequently asked questions
Redo it just before you would forget it. In practice that means a short gap after a struggle (a day or two), then longer gaps each time you solve it cleanly: about a week, then a few weeks, then a couple of months. A spaced-repetition scheduler such as FSRS works out these gaps for each problem from your own results.
Re-solve it from a blank editor. Re-reading feels productive because the solution looks familiar, but recognizing an answer is much easier than producing one, and interviews test producing it. For problems you already know well, a quick recall check (state the approach in a sentence or two, then check your notes) is a good lighter review.
Keep it small enough to do every day: one or two full re-solves plus a few quick recall checks is sustainable for most people alongside new problems. Consistency matters more than volume, because the schedule only works if due reviews actually get done.
Keep a single DSA log of every problem you solve, from any platform, with the date, how it went, the core idea and your mistakes, and let a spaced-repetition schedule decide what to revise each day. A plain list shows how much you have done; a schedule also shows what you are about to forget.
Two things: the core idea in one or two sentences (the insight that unlocks the problem, not the code), and the mistakes you made. Those notes are what you check against during a review, and the mistake log is what stops you repeating the same bug.
Import them and spread the first revisions over several weeks rather than all at once. Hash-It does this automatically: whether you import a DSA sheet or your LeetCode history, first revisions are spread over 60 days.