How to Revise DSA Problems You Have Already Solved
Learn a practical, research-backed routine to revise solved DSA problems so the core approach sticks for coding interviews.
Two new problems a day is a good default, and one is fine. What matters more than the count is whether you finish the day with a solved problem you could explain again next week. A daily number you can hold for ninety days beats a number you hold for nine.
Most people pick their number from a screenshot of someone else's streak. The better way is to work backwards from the calendar.
Say your first campus round is in twelve weeks. That is roughly eighty working days if you allow some off days. At two new problems a day you cover a hundred and sixty problems,. At five a day you would cover four hundred, and you will not, because nobody sustains five hard problems a day next to classes and assignments.
So the honest question is not "how many can I do on my best day." It is "how many can I do on a bad Tuesday." Set the number there, and treat good days as a bonus.
A problem you solved once and never touched again decays fast. You remember that a solution existed, not how it went. Three weeks later the same pattern shows up in a slightly different costume and you start from zero.
That is why a plan with one new problem and one revision each day often outperforms a plan with three new problems and no revision. The revision is not extra work. It is the step that turns a solved problem into a usable one. Redo an old problem from a blank editor, without reading your own solution first, and note where you got stuck.
Suppose your number is two. A workable day: one new problem from the topic you are studying this week, and one older problem from a topic you finished earlier. Time-box the new one. If you have made no progress after about thirty minutes, read a hint, not the full solution, and finish it yourself. If you still cannot, read the solution, close it, and rewrite it from memory. Then mark it for revision instead of counting it as solved.
Compare that with a day that says "five problems" and ends with three solved by reading the editorial. Three problems you read are worth less than one you struggled through and wrote yourself.
Raise the number when your new problems in a known topic are taking under fifteen minutes and you are getting them right first time. That means the topic is done and the time is better spent on a new one.
Lower it when you are copying solutions to hit the count, or when you skip revision because there is no time. Both are signs the number is too high for your real schedule.
Daily plans also break on the first missed day, so decide in advance what a missed day means. A good rule: never miss two in a row, and never try to double up to catch up. Doubling up is how a two-a-day plan turns into a burnout week. DSA Tracker's own daily plan caps at three problems for exactly this reason, a day you can finish keeps you coming back.
Next step: open your calendar, count the working days until your first interview, and multiply by a number you could hit on your worst weekday. That product is your target, and the division gives you your daily count.
Learn a practical, research-backed routine to revise solved DSA problems so the core approach sticks for coding interviews.
Bubble sort is rarely the answer in a coding interview. See which sorting algorithms to learn, their time complexity, and the problems where each one shows up.