Why review a coding problem you already solved and got accepted?
answer
- acceptance answers only one question
- a green result can hide a slower approach
- compare approaches, not outputs
- look for the idea you did not have
- wrong pattern chosen is its own class
basics
~20 sAn accepted solution proves your approach worked, not that it was the best one available. Reviewing it surfaces the idea you never had - a better pattern, a lower complexity class - which is what practice is meant to add.
solid answer
~40 sAcceptance answers one narrow question: did this approach produce correct output within the limits. It says nothing about whether a better approach existed, how long you flailed before the idea arrived, or which examples you never tested. So after a pass I still compare my solution against a reference one - not to check correctness, which is already settled, but to find the idea I did not have. If mine sorted and scanned in `O(n log n)` and the reference does one pass in `O(n)`, the gap is an approach gap, and I log it as its own error class: *wrong pattern chosen*, kept separate from mechanical slips like a bad boundary. Those two classes need completely different remedies, so conflating them wastes the next month of practice.
go deeper
Be ready to say what you write down after a problem passes: the approach and its cost, the better approach if one exists, and what went wrong on the way. Knowing that acceptance is not the end of the exercise is the point here.
Explain why an approach gap and a mechanical slip are different findings with different remedies, and how you extract an idea from a reference solution by naming the input property it exploits rather than by reading its code.
Show the judgment about which attempts deserve a review at all: a slow, shaky or out-classed attempt earns one, a clean match to the best approach earns a timing line. Demonstrate that you use review time deliberately rather than ritually.
Own the argument that measured error classes, not counts of problems finished, are the evidence worth trusting about someone's readiness - including your own - and be able to say what that evidence can and cannot support.
## What acceptance actually proves A green result from a judge is a single bit of information: *this code produced correct output on the test data inside the time and memory limits*. It is silent about everything a practice session is supposed to improve. It does not say whether a fundamentally better approach existed. It does not say whether you found your approach in three minutes or after twenty-five minutes of thrashing. It does not say which edge cases you never thought to test and simply got lucky on. Treating the green result as the end of the exercise means you keep only the one bit and throw away everything else the attempt generated. That is why the review is a *step*, not an optional flourish. The attempt produces evidence; the review is where you read it. ## Three things a review extracts **1. The idea you did not have.** This is the highest-value item and the one people skip because the problem is already "done". Read a reference solution for its *approach*, and ask a single question: is there an idea here that I did not consider? Common shapes of that gap: you sorted to expose structure where a counting structure would have exposed it in one pass; you recomputed a quantity per element where a running aggregate carried it forward; you searched a space exhaustively where a monotone property let you discard half of it. Each of those is a transferable idea. None of them show up in a correctness check, because your solution was correct. **2. Mechanical defects.** Anything that made the attempt slower or shakier without being an approach problem: a boundary you got wrong on the first submission, an initial value you had to fix, a case you only found because the judge rejected you. These are worth recording separately and precisely - not "bug", but *which* boundary, in *which* shape of problem. **3. Process data.** How long the phases took: clarifying, choosing the approach, writing, testing. Where you stalled. Whether you tested before submitting or used the judge as your test suite. Over a few dozen attempts this is the data that tells you what is actually limiting you, and it exists only if you write it down at the moment, because a week later you will not remember. ## Why "wrong pattern chosen" deserves its own class It is tempting to file everything under "mistakes". But the remedies are unrelated. A boundary slip is a care-and-checklist problem: you fix it by testing the smallest and largest inputs before submitting, every time, until it is automatic. Choosing the wrong pattern is a recognition problem: you fix it by building the association between a problem's surface features and the technique that fits, which means seeing many instances and naming the trigger out loud. Drilling more careful coding will never close a recognition gap, and drilling recognition will never stop you writing an inclusive bound where you meant exclusive. If your log lumps them together, its tally cannot point at either remedy. There is a third class worth separating: *no gap at all*. Sometimes your approach matches the best known one, you found it quickly, and the only note is the timing. That entry is not a failure to explain away - it is the entry that lets you trust the tally when a real cluster appears. ## How to compare without reading passively The risk in opening a reference solution is that reading a finished, elegant solution feels like insight while leaving nothing behind. Two habits keep the comparison honest. First, read the *approach*, not the code - one paragraph, the idea, then stop. Second, force yourself to state, in your own words, the property of the input that the better approach exploits and yours did not: "the values are bounded, so they can be counted directly instead of sorted"; "the window only ever grows on one end, so the aggregate can be maintained instead of recomputed". If you cannot articulate that property, you have not extracted the idea; you have admired it. ## A five-minute version You do not need a ritual. After the green result: write the approach you used and its cost; skim the reference approach and write its cost; if they differ, write one sentence naming the idea you missed and file the attempt as *wrong pattern chosen*; note the phase timings and anything you got wrong on the way. Five minutes, four lines, and the attempt has produced something reusable rather than a checkmark. ## When to skip it Review time is real time. If your approach matches the best known one, nothing stalled, and you tested before submitting, the honest entry is one line of timing data and you move on. The review earns its place on attempts that were slow, shaky, or beaten by a better idea - which, early on, is most of them.
- You compared, and the reference approach is asymptotically better. What do you actually do today?Extract the idea in one sentence - the input property it exploits that yours ignored - then rebuild that solution yourself from scratch rather than copying it, and queue a cold re-attempt of the problem for a few days later. Reading the better approach is the cheap half; reproducing it without the page open is what makes it available under pressure.
- What do you record when your solution and the reference agree?Process data: how long you took to settle on the approach, where you stalled, whether you tested the extreme inputs before submitting or let the judge find them. Matching the reference is a real result, and logging the timing gives you a baseline. Without those neutral entries your log only contains failures, so any cluster in it looks alarming and none of them are comparable.
- Isn't a faster measured runtime proof that your solution was the better one?No. Measured runtime on one test set reflects constant factors, input size and machine noise as much as it reflects the algorithm. An approach with a worse complexity class can easily measure faster on small judge inputs and then collapse at ten times the size. Compare the asymptotic cost and the idea; treat the reported milliseconds as weak, noisy evidence.
saying these in an interview costs you the question
- Accepted means the problem is finished
- Review is only for problems you failed
- A faster reported runtime means a better approach
- Every mistake is just a careless slip
- Only the final complexity matters, not where you stalled