After a contest, the easiest discussion is also the least useful: list the problems the team solved, glance at the ones it missed, and promise to practice more. The scoreboard is a valuable index, but it is not a diagnosis. Two teams can finish with the same score while needing completely different training.
I want a review to answer a more demanding question: what should this team notice or do differently the next time an unfamiliar contest begins? That requires reconstructing the contest before turning to editorials.
Start with individual reconstruction
Each teammate should first write a short account independently. Which problems did they read? What did they believe the difficulty order was? Where did they spend time? Which idea almost worked? When did they ask for help, hand off a problem, or abandon an approach?
Independent accounts matter because a team’s shared story forms quickly and can erase useful disagreement. One person may remember a problem as conceptually hard while another remembers that the idea was available but never communicated. Both observations can be true, and they imply different remedies.
Classify the failure before prescribing practice
I separate failures into a small set of categories: missing knowledge, failed recognition, an incomplete proof, implementation trouble, poor testing, time allocation, and team coordination. “We could not solve problem F” is not yet actionable. “We knew the technique but did not recognize the invariant” is.
The classification does not need to be perfect. Its purpose is to prevent generic treatment. Reading an editorial can address missing knowledge. It does little for a team that found the right idea and lost forty minutes to an untested assumption or an unclear handoff.
Reconstruct the pivotal moments
Most contests contain a few decisions with disproportionate consequences: choosing between two approachable problems, continuing a nearly working implementation, switching typists, or deciding that a proof is solid enough to code. Review those moments using the information available at the time—not with the certainty supplied by the final standings.
The goal is not to punish a bad outcome. It is to improve the decision rule. What evidence should trigger another ten minutes of work? What evidence should trigger a second reader, a handoff, or a full reset? Teams become more reliable when these choices stop depending entirely on mood.
Upsolve in layers
For each important unsolved problem, I prefer three layers. First, explain the idea and proof without code. Second, implement it cleanly and test the cases that threaten the proof. Third, solve a different problem that requires the same idea without announcing the connection.
The third layer is essential. Reproducing an editorial shows that the explanation was understood. Recognizing the technique under a new surface form shows that something transferable was learned.
End with a small training contract
A review should finish with a few observable commitments, not a long inventory of mistakes. One teammate might own a topic gap. The team might adopt a clearer handoff protocol, schedule a timed set focused on triage, or require a verbal proof before implementation on certain problem types.
At the next review, return to those commitments. Improvement becomes visible when the team can connect a changed habit to a changed decision. That feedback loop turns contests from isolated performances into a coherent training process.