Hourly DSABlog

How to Review DSA Mistakes Without Copying Solutions

By Hourly DSA · · 4 min read

A useful DSA review captures the reason an answer failed and gives you a small way to test that reason again. You don't need to copy an entire solution. Record the missed condition, a counterexample, and a question you can answer later without the explanation open.

This works for both a wrong multiple-choice answer and a bug in a full implementation. In either case, the goal is to make the correction specific enough to reuse.

Start with what you believed

Imagine answering: “DFS finds the shortest path in an unweighted graph.”

The useful review starts by identifying the mistaken belief: “I assumed the first path found was the shortest one.” That's more precise than “I don't understand graphs.”

A specific belief is testable. You can construct a graph where DFS explores a longer route first and see exactly why the statement fails.

For the full distinction, read BFS vs. DFS.

Make a counterexample small enough to remember

Use two routes from A to a destination:

A → B → C → D
A → D

A depth-first traversal that follows B first can find D after three edges even though a direct edge exists. The first discovered route isn't necessarily the shortest.

The corrected idea is: “BFS explores vertices in increasing edge distance, so first discovery gives a shortest route in an unweighted graph.”

The condition “unweighted” belongs in the correction. Leaving it out creates the next misconception: fewest edges doesn't necessarily mean lowest cost when weights differ.

Keep a three-line review note

A compact note might look like this:

Mistake: treated the first DFS path as shortest
Counterexample: A-B-C-D plus a direct A-D edge
Question: why does BFS's exploration order fix this?

The question forces you to explain the property that matters. A note that only says “use BFS” makes it easier to memorize a label without understanding when it applies.

If the mistake was in code, record the smallest input that exposed it. “One-element input reused the same position” is often more useful than saving the entire failing test suite.

Separate different kinds of mistakes

Different errors call for different follow-up work:

What went wrongUseful next task
Didn't know a definitionExplain it with a tiny example
Chose a pattern without its required conditionFind a counterexample where that condition is absent
Had the right idea but wrong boundaryTrace an empty or one-element case
Could explain it but couldn't implement itWrite the implementation from the explanation
Claimed the wrong complexityCount how often the costly operation occurs

This keeps review from becoming “do another random problem.” A boundary bug in binary search may need a careful trace, not a new graph lesson.

Revisit the question before the explanation

At your next review, hide the correction and answer the question first. Then compare your reasoning with the note.

If you immediately remember the conclusion but can't explain it, try changing the example. For the graph case, ask what changes when one edge costs ten and the others cost one. That variation checks the condition behind the rule.

You can revisit a difficult idea in a later session and again after a few days. Treat the spacing as a practical starting point rather than a fixed schedule you must follow. If the concept is still unclear, spend time understanding it instead of repeatedly guessing the answer.

Know when to return to code

A conceptual correction should eventually survive an implementation where implementation is relevant. If you misunderstood binary-search boundaries, trace the corrected loop and then write it without copying.

Try a new case, not just the one that originally failed. A patch can make one input pass while preserving the underlying bug.

For example, after fixing a lower-bound search on duplicates, test a target larger than every value. The returned position may be the array length; your code must check that before reading an element.

Our binary search boundary guide walks through that exact distinction.

Make the review easy to return to

Keep notes short enough that you will read them. Delete redundant copies of the same lesson and spend your attention on the ideas you still struggle to explain.

Hourly DSA makes room for quick reasoning practice during the day. After a wrong answer, use the explanation to name one missed idea. Then ask yourself a question that would reveal whether you understand it next time.

If you want a simple place for review in your schedule, try the final few minutes of this 20-minute DSA routine. Leave the session with a precise next step instead of a growing pile of solutions.

Use small examples and explicit assumptions during your next attempt, before reading a solution.

Stuck on a Coding Interview Problem? Try These Steps →