Why does understanding an editorial solution not count as having learned it?

## Recognition and recall are different abilities When you read a finished solution, you are performing recognition: each step is presented, each follows from the last, and your job is only to verify that it makes sense. That is an easy task and it produces a strong feeling of understanding. An interview asks for something else entirely - generation from an empty page, under time pressure, with no confirming next line waiting. The two abilities come apart badly. Plenty of people can follow every line of an approach they could not have produced and could not reproduce a day later. This is the fluency illusion: material that is easy to process feels well learned. Re-reading maximises fluency and minimises learning; attempting to produce the thing yourself feels harder and leaves far more behind. The whole design of a good upsolve is to move the work from the first mode to the second. ## The upsolve protocol **Read the approach, not the code.** Take one paragraph - the idea. "Maintain a running aggregate instead of recomputing per element." "Process in order of a derived key so the constraint becomes local." "Cache the state you keep re-deriving." Then close the page. Reading the finished implementation gives you the code and skips the part you failed at, which was choosing the idea. **Restate your brute force and its cost.** Say explicitly what the naive approach does and what it costs. This anchors the rebuild in something you already own. **Name the waste.** Between the brute force and the optimal there is always a specific inefficiency: the same subrange summed repeatedly; the same subproblem re-solved along different paths; a full scan repeated for every element when a maintained structure could answer in constant time. Naming the waste out loud is the step that converts a memorised trick into a reusable move, because next time you will notice the same waste before you know the trick's name. **Rebuild until it passes, unaided.** Reconstruct the solution from the idea. Every detail you have to re-derive - the exact invariant, the update order, the initial state - is a detail that was never yours when you were merely reading. If you reopen the page, the attempt is no longer evidence of anything; finish it, then re-queue the problem for a cold attempt later. **Write the trigger.** One sentence in your own words describing the input property that makes this technique apply. This is what generalises. A remembered solution helps with exactly one problem; a trigger phrased as "when X is true about the input, consider Y" is what fires on the next problem you have never seen. ## The failure mode: memorising the answer The most common way an upsolve goes wrong is that it succeeds too smoothly. You reconstruct the solution twenty minutes after reading it, everything falls into place, and what you have actually demonstrated is short-term recall of a specific artifact. Two guards against this. First, delay: schedule a cold re-attempt days later, when the specifics have faded and only the idea can carry you. Second, transfer: attempt a *different* problem with the same trigger. If the technique only fires when the surface details match the one you studied, you memorised a solution rather than learning a pattern - and the fix is more varied instances, not more re-reading of that one. ## Why not just read more solutions? Because reading is cheap and reading feels productive, and the volume of solutions you can read in an hour is far greater than the number you can rebuild. That asymmetry is exactly the trap: the cheap activity produces the fluency signal without the capability, so it crowds out the expensive activity that produces the capability. Reading has one legitimate role - supplying the idea you did not have, once, in a paragraph. Everything after that paragraph has to be produced by you. ## What a good upsolve leaves behind After the rebuild you should have: a passing solution you constructed, a one-line statement of the waste the technique removes, a trigger phrased generically, and a date for the cold re-attempt. Notice that only the first of those exists if you simply read the editorial and moved on - and it is the least useful of the four, because a solution you did not generate is a solution you cannot regenerate. ## The honest self-check At the end of an upsolve, ask: if this problem appeared tomorrow with the numbers changed and the story rewritten, would I find the idea myself? Not "would I recognise it" - recognition is guaranteed and worthless here - but would I *find* it. If the answer is no, the upsolve is not finished, whatever the judge says.