When Should You Look at the Solution? A Rule for Getting Unstuck in DSA Practice

Every DSA learner hits the same wall: twenty minutes into a problem, no idea is working, and the solution is one click away. Open it too early and you learn nothing. Refuse to open it and you can lose an entire evening to one problem. Neither extreme builds the skill interviews test, which is finding an approach on your own.

The fix is a rule you decide before you start, so the choice is not made when you are tired and frustrated.

Set a time box before you read the problem

Give yourself a fixed window for the first attempt. A common starting point is 20 minutes for an Easy problem and 30 to 40 for a Medium. The exact numbers matter less than deciding them in advance.

Inside that window, the goal is not a perfect answer. The goal is any honest attempt: a brute force, a half-working idea, even a written guess about which data structure fits. A brute force that runs in O(n^2) is progress. A blank screen after 30 minutes is a signal that you are missing a concept, not that you need 30 more minutes.

Stuck is not one state

Before you open anything, name which kind of stuck you are:

• You do not understand the question. Work a small example by hand. If the output still makes no sense, reread the constraints.
• You understand it but have no approach. You are missing a pattern. This is where a hint helps most.
• You have an approach but the code fails. You are missing a bug, not an idea. Trace your code on the smallest failing input before looking at anyone else's.

Only the second kind needs outside help. The first and third you can finish yourself, and finishing them is where debugging skill comes from.

Take the smallest hint first

A full solution answers every question at once, including the ones you could have answered yourself. A graded hint answers one. Ask for the least help that gets you moving: first the pattern name, then the key observation, and only then the full approach.

For Longest Substring Without Repeating Characters, the first hint is "sliding window". Many people can finish from that alone. If not, the second hint is "shrink the window from the left whenever a character repeats". The full code is the third step, and often it is never needed.

The editor on this site works this way: its Think it through tab opens a nudge first, then approaches from slowest to fastest, then the common pitfalls, each one only when you click it.

After you read it, close it

Reading a solution feels like understanding. It usually is not. The test is whether you can write it yourself.

So after reading, close the tab and write the solution from memory. You will get stuck at one or two points, and those points are exactly what you did not understand. Go back, read only that part, close it again, and finish.

Then write one line in your notes: what the key idea was, in your own words. For Coin Change that line might be "try every coin as the last coin; the answer for amount builds on the answers for smaller amounts". A one-line note is easier to revise than a page of code.

Come back in a few days

A problem you needed the solution for is not solved yet. It is scheduled. Mark it and try it again from a blank editor after 3 days, and again after a week or two. If you can write it cleanly the second time, it has moved from "read" to "known".

If you keep failing the same problem, the gap is usually an easier problem you skipped. A learner stuck on House Robber often has not yet done Climbing Stairs, which is the same idea in its simplest form.

A rule you can use today

Write your rule down before your next session. For example: 25 minutes of honest attempt, then one hint, 10 more minutes, then the next hint, and if you read the full solution, re-code it from memory and schedule a retry in 3 days. The rule will not make hard problems easy. It will make sure that every problem, solved or not, leaves you with something you can do next time without help.