How to Revise DSA in the Final Week Before an Interview
You can't re-solve 370 problems in seven days, and you shouldn't try. Here's a spaced-repetition revision system that targets only your weak patterns — fast.
7 min read
Spaced Repetition for DSA: The Revision Schedule That Stops You Forgetting Solved Problems
By Riya Kushwaha7 min read
Every placement season produces the same story: a student who solved 250 problems freezes on Two Sum variants in the interview. They did not fail to learn. They learned, and then forgot, because nothing in their process brought the problem back at the moment it was about to slip.
Spaced repetition is the fix. It is a hundred-year-old finding from memory research, it is how every serious language learner uses flashcards, and it maps onto coding problems almost perfectly.
The forgetting curve, in one paragraph
After you learn something, recall decays fast at first and then slowly. If you review it just before it drops below the point where you could reproduce it, the curve resets and decays more slowly the next time. Review too early and you waste time; too late and you are relearning from scratch. The intervals that work in practice are roughly 1, 3, 7, 14 and 30 days, doubling each time you succeed.
For coding problems, "recall" means writing a working solution from a blank editor, not recognising the approach when you read it.
The schedule
When you solve a problem, rate it honestly on three levels:
| Rating | What it means | See it again in |
|---|---|---|
| Struggled | Needed the editorial or more than 30 minutes | 1 day |
| Got it | Solved it, but slowly or with a hint | 3 days |
| Nailed it | Clean solution in one go, could explain it | 7 days |
On the revision day, re-solve it with a 15-minute time box and rate again. A good rating roughly doubles the previous gap (7 becomes 14, 14 becomes 30). A "Struggled" resets the gap to 1 day regardless of history. Three "Nailed it" ratings in a row and the problem retires.
This is exactly what the Revise button on every problem in DSA Tracker records, and what the Review page surfaces each morning as "due today", so you do not have to keep the schedule in a spreadsheet. But the system works on paper too.
What to revise, and what not to
Revise problems that represent a pattern. Longest Substring Without Repeating Characters stands in for every variable sliding window. Coin Change stands in for unbounded knapsack. If a due problem is a near-duplicate of another due problem, revise one and skip the other.
Do not revise problems you solved by memorising the code. Rate those "Struggled" even if the code came out, because the interview version will have a twist and memorised code does not bend.
Weight by your target role. A frontend engineer does not need Dijkstra in rotation; a backend engineer does. If your tracker knows your role, the due list is already ordered by how much the topic matters for it.
How it fits with new problems
A common mistake is to stop solving new problems while revising, or to skip revision because new problems feel like progress. The balance that works:
- New problems: 2 to 4 a day, in your role's priority order.
- Revision: whatever is due, capped at about 6. If more than that is due, the earlier ratings were too generous; be stricter for a week.
- One day a week with no new problems, only revision. This is when the patterns consolidate.
The 7-day pre-interview plan is the compressed version of this for the final week: it stops adding new problems entirely and clears the due list in pattern order.
A worked month
Say you solve 3 new problems a day for 30 days: 90 problems. Roughly a third get "Struggled", a third "Got it", a third "Nailed it". By day 10 you have about 5 due a day; by day 20 it peaks near 8; by day 30 the early problems are retiring and it settles back to 5 or 6. Total revision time is around 60 to 90 minutes a day on top of new problems, and at the end of the month you can actually solve the 90 problems, not just recognise them.
Compare that with solving 4 new problems a day and never revising: 120 problems on the counter, and by an interview three weeks later, perhaps 40 of them are still solvable. The counter is not the skill.
The honest rating is the whole system
Everything above depends on rating yourself accurately at the moment you finish. The temptation is to mark "Nailed it" because you got the right answer. The question is not whether the answer was right; it is whether you would have got it in an interview, under time pressure, without the hint you took. If the answer is "probably not", it is a "Got it" at best. Being harsh costs you a few extra revisions. Being generous costs you the interview.
Frequently asked questions
How often should I revise a solved DSA problem?
Rate it when you solve it. If you struggled, see it again in 1 day; if you got it with effort, in 3 days; if you nailed it, in 7 days. Each time you rate it well again, roughly double the gap: 7, 14, 30 days. A problem you nail three times in a row is done.
Should I re-solve the problem or just re-read the solution?
Re-solve it from a blank editor with a time box of 15 minutes. Re-reading feels productive and teaches almost nothing, because recognition is not recall. The point of the revision is to force recall.
How many problems should be in revision at once?
Aim for 3 to 6 due problems a day on top of new ones. If the due list grows past 10, stop adding new problems for a few days and clear it; a large backlog means the earlier ratings were too generous.
Practice what you just read
Keep reading
How to Crack DSA for Placements in 90 Days: A Realistic Day-by-Day Plan
Ninety days is enough — if you don't waste the first sixty on arrays. A realistic, phase-by-phase plan with daily targets and a revision cadence that actually sticks.
7 min read