How Champions Think

Competition mathematics looks like a test of raw cleverness. It is mostly a test of trained recognition. What separates an IMO medalist from a strong classroom student is not processor speed; it is a library of perhaps two hundred recognition–action pairs — "this problem smells like parity," "these constraints scream binary search" — compiled from thousands of solved and, crucially, failed problems. Nobody is born knowing that "minimize the maximum" is a sentence about binary search. Someone drilled it, missed it, journaled the miss, and met it again.

The psychology behind this is old and solid. Adriaan de Groot's chess studies of the 1940s, extended by Chase and Simon's "Perception in Chess" (1973), showed that grandmasters do not search deeper than club players in most positions. They see better. In the classic experiment, a real position flashed for a few seconds is rebuilt almost perfectly by a master and haltingly by a novice — but scramble the pieces into a random arrangement and the master's advantage nearly vanishes. Years of study have chunked the board into meaningful patterns, and expertise converts search into lookup. Chase and Simon put the master's vocabulary at tens of thousands of chunks — the size of a reading vocabulary, which is the right comparison: strong players read positions rather than compute them. A heuristic is compressed experience: it prunes an exponential tree of possibilities down to a handful of candidate moves.

This chapter is about the mind that carries such a library: the frame it thinks in, the flaw in the frame, the culture that builds the library, and the craft of reading a problem's author like a dossier. It ends with the machines that started winning the same medals in 2024–25, and with the reason the training culture did not thereby become a museum. The next three chapters are the library itself — sixteen tools, each with its recognition signal and a worked pair. This chapter is the operating manual for the librarian.

The four phases

George Pólya, a Hungarian mathematician at Stanford, published How to Solve It in 1945. It has sold over a million copies and is the founding document of heuristics-as-curriculum — the first sustained argument that problem-solving is teachable technique rather than temperament. Everything in Part III hangs on his frame, so it is worth seeing whole before the tools arrive.

Phase 1 — Understand the problem. Pólya's questions: What is the unknown? What are the data? What is the condition? Is the condition even sufficient to determine the unknown? Draw a figure. Introduce suitable notation. The competition translation: restate the problem in your own formalism before touching it. Most wrong solutions die here — they solve a neighboring problem, often perfectly. ICPC teams ritualize this phase: one member re-reads the statement hunting for the sentence everyone skimmed.

Phase 2 — Devise a plan. Have you seen it before? Do you know a related problem? Can you restate it? Can you solve a simpler or analogous problem first? Have you used all the data? This phase is the arsenal of Chapters 9 through 11. "Devising a plan" means running your recognition signals over the problem until one fires.

Phase 3 — Carry out the plan. Check each step; can you see clearly that the step is correct — can you prove it? Translation: execution discipline. Casework bookkeeping, algebra hygiene, off-by-one vigilance, and, in programming contests, the test-before-submit ritual. Plans are cheap. Flawless execution under a clock is a separately trained muscle, and contests are lost in this phase at least as often as in the previous one. ICPC teams debug printed code on paper while a teammate types the next solution — execution discipline made spatial.

Phase 4 — Look back. Can you check the result? Derive it differently? Use the method somewhere else? This is the phase amateurs skip and champions industrialize. The upsolving culture described below is Phase 4 turned into a lifestyle.

Two notes before the caveat. The phases loop rather than march: a failed plan sends you back to understanding, and looking back at a solved sub-problem often is the plan for the main one. And Phase 2 is where the next three chapters live — Chapter 9's kill shots, Chapter 10's builders, and Chapter 11's lenses are the plan-devising phase unpacked into sixteen named reflexes.

The missing dial

The caveat that keeps the frame honest comes from Alan Schoenfeld's Mathematical Problem Solving (1985). Schoenfeld watched students who had been taught Pólya's heuristics fail anyway — not for lack of tools but for lack of control. His timeline charts of student sessions are famous in the field: read the problem, pick the first idea that offers itself, chase it in a flat line until the bell. An expert's chart oscillates — analyze, plan, try, check, back out, replan. The students owned tools; they lacked the timer in the head that periodically interrupts with is this approach earning its keep? Schoenfeld's classroom fix was almost comically simple: he interrupted working students, again and again, with three questions — What exactly are you doing? Why are you doing it? How does it help you? — until the interruption installed itself and students began asking unprompted.

Call metacognitive monitoring the invisible seventeenth heuristic. Tools choose moves; control decides when to abandon them. Two minutes of algebra with no simplification — reconsider. A case split that has bred seven sub-cases — back out and hunt for an invariant instead. Control is also the skill the clock trains hardest: under contest pressure, sunk cost whispers five more minutes precisely when the dial says switch. Everything in the next three chapters assumes that loop is running, because a library without a librarian is just a pile.

Where the library comes from

The public imagines prodigies. The community runs a training industry, with unusually honest feedback loops.

The arenas. Each major arena drills a different muscle, and serious competitors cross-train. The International Mathematical Olympiad, held since 1959 and now drawing over a hundred countries: two days, three problems per day, four and a half hours a day, seven points per problem, 42 the perfect score. Roughly, problems 1 and 4 are entry, 2 and 5 middle, 3 and 6 brutal. The International Olympiad in Informatics is its high-school programming twin — partial scoring, two five-hour days. ICPC, the university team championship, seats three students at one shared computer for five hours and ten-to-thirteen problems; the engineered scarcity forces role specialization — reader, coder, prover — and paper-debugging, which trains something subtle: the verbalization of half-formed thought. The Putnam, running since 1938, offers twelve problems for 120 points and a median score that in many years is 0 or 1 — a calibration that normalizes failure as the default state of problem solving. The calibration is deliberate and pedagogically load-bearing: a sport where the median entrant scores 1 out of 120 cannot be about feeling clever, so it becomes about the long game of getting less wrong. Codeforces, founded in 2010 by Mike Mirzayanov in Saratov, is the sport's daily gym: rated two-hour rounds and a ladder of colors from gray newbie through cyan, blue, purple, and orange to red grandmaster, with a black-and-red "legendary" tier past 3000. Gennady Korotkevich — "tourist," the sport's Federer — became the first to cross rating 4000 in 2024. On the mathematical side, Art of Problem Solving, founded in 2003 by Richard Rusczyk, is forum, textbook press, and nursery; most recent US IMO team members grew up on it.

Upsolving, the core loop. The single most agreed-upon practice in the culture: after every contest, solve the problems you failed — that day, before the sting fades. Rating measures the past; upsolving builds the future. A missed problem marks the precise boundary of your ability, and converting it from failure into owned pattern moves the boundary — the contest already found your weakest spot for free, and upsolving is refusing to waste the diagnosis. Competitors speak of a problem "entering the hands" only once it has been re-solved from scratch. Understood-from-the-editorial does not count: reading a solution feels like understanding, but only reproduction from a blank page proves the pattern is installed rather than admired.

The mistake journal. The stronger version, kept by many high-rated competitors: every wrong submission classified — misread statement, wrong algorithm, off-by-one, unproven greedy, overflow — and every failed problem logged, then revisited on a schedule and re-solved cold. This is spaced repetition applied to reasoning patterns instead of vocabulary; the deck is your personal error distribution. The classification step matters as much as the review. "I lose most of my rating to unproven greedys" is an actionable diagnosis, and Chapter 10 prescribes for exactly that disease. The journal's power is the denominator: after fifty entries you know your base rates, and base rates turn vague resolve into a targeted drill.

Ladders and the +200 rule. Practice slightly above your level — the folk prescription is about 200 rating points up: hard enough to hurt, close enough to finish. Ahmed Aly's A2OJ "ladders" formalized the idea as ordered problem lists; per-problem difficulty ratings and curricula like the USACO Guide carry it today. The logic is deliberate practice in Ericsson's textbook sense — maximal time at the edge of competence, minimal time in comfort. Below the edge nothing is learned; too far above it nothing is finished, and finishing is where the pattern sets.

Struggle before editorial. A community norm with real disagreement about the number and none about the principle: fight a problem genuinely — thirty to sixty minutes of motion, not stall — before reading its editorial; then read one hint's worth and try again. Reading solutions too early trains recognition of solutions, not production of them. The struggle is not the price of the learning. It is the learning: the recognition signals of the coming chapters get wired during the fight.

Stress testing. The competitive programmer's version of the scientific method: when a solution is suspect, write a five-line brute force, a random test generator, and a loop that diffs the two until a minimal counterexample falls out. Strong competitors do this during contests; it converts "I believe my greedy" into evidence within a minute. Note the shape of the habit — mechanical, adversarial, aimed at yourself. It transfers directly to auditing the output of machines, a point Part V will insist on.

Virtual contests. Re-run old contests under a real clock, full rules. This trains the meta-skills no problem list teaches: reading all the problems first, ordering them by expected value, deciding when to abandon an approach — Schoenfeld's dial, drilled deliberately — and managing the panic of minute 100. ICPC teams rehearse the logistics of who touches the keyboard when, like a pit crew. None of it is glamorous, and that is the point: the community treats reasoning as a trainable motor skill — with a gym, a technique, and a log book.

The canon. Pólya (1945). Engel's Problem-Solving Strategies (1998), with hundreds of drills per tool. Zeitz's The Art and Craft of Problem Solving. The AoPS book series, and the IMO Shortlists, published a year after each olympiad — the community's graded problem bank and every national team's training set. For programming: Laaksonen's Competitive Programmer's Handbook, Halim's Competitive Programming, and cp-algorithms.com as the working reference.

The setter's mind

Problems are not found. They are manufactured — and knowing the factory's methods is itself a solving tool, the way a locksmith picks locks faster for knowing how locks are cut.

How the sausage is made. Three patterns dominate. Kernel-first: the setter starts from a phenomenon — an invariant that surprises, a greedy that works for a non-obvious reason, a bijection between unlike objects — then wraps a story around it and tunes constraints until the intended idea is both necessary and sufficient. The story, whether knights or factories or chocolate bars, is deliberately load-free costume. Backwards-first: the setter fixes the shape of the answer — "the extremal configuration should be the golden-ratio pair" — and constructs a rule set for which that is the solution. Problem design as inverse problem solving. Kill the unintended: the drafting loop is adversarial. Testers attack with naive greedys, brute force, and pattern-guessing, and every successful cheap attack gets patched — a constraint raised to kill the brute force, a test added to break the plausible-but-wrong greedy, sample cases curated not to reveal the trick. If a plausible greedy survives testing, the setter builds the case where it fails — remember that when the {1, 3, 4} coins ambush you in Chapter 10. Codeforces problems pass through Polygon, a preparation system of validators, checkers, generators, and stress tests: industrial QA for puzzles. At the IMO, countries submit proposals, a Problem Selection Committee distills a shortlist of around thirty across algebra, combinatorics, geometry, and number theory, and an international Jury picks and polishes the final six.

The three factory patterns matter because each leaves fingerprints on the finished problem — and fingerprints can be read. Therefore read every problem as a message from its maker.

• Constraints leak the intended complexity. In a programming contest, n ≤ 20 whispers bitmask; n ≤ 40 shouts meet-in-the-middle; n ≤ 200,000 with sums says n log n. The full decoder table waits in Chapter 11 — read in reverse, it is a decoder of authorial intent.
• Every hypothesis is used. Olympiad statements are minimal by editing pressure. If it says distinct integers, distinctness is load-bearing; if the graph is connected, the proof will need it. A condition you have not used is either the key you are missing or the door you have not found — and, contrapositively, a "solution" that never used the strange condition is almost surely wrong.
• Strange exactness is a signpost. "Exactly 2n − 1 numbers"; "n² + 1 terms." Sharp-looking counts mean the bound is tight, and the example showing tightness is part of the intended understanding. Find it and you have usually found the mechanism. Both of those particular counts will detonate in the coming chapters.
• Position is prior. Problem 1 of an IMO day has a short, honest solution — if yours is a monster, restart. A mid-division contest problem wants one idea plus clean execution, not a research program. The setter's calibration is free Bayesian evidence, and strong solvers consciously condition on it. The conditioning works in reverse too: a trivial-looking Problem 6 is a warning, not a gift.
• Cultural fingerprints. A modulus of 998244353 — a prime p with 2²³ dividing p − 1 — announces number-theoretic-transform convolution to the initiated, the way 10⁹ + 7 announces "just avoid overflow." These tells are not trivia; they are the strongest single hint on the page, because they encode what the author expects the solution to be. Sample outputs that hide the interesting case are telling you the interesting case exists.

The deeper point, for a book about thinking: expert solvers run a theory of mind on the adversary-author. Why would a sane designer include this clause? is not mathematics at all — it is hermeneutics. And it is precisely the skill that transfers out of the arena, to contracts, regulations, benchmarks, and AI evaluations. Artifacts built by intent are decoded fastest by modeling the intent.

The machines arrive

An honest chapter about olympiad minds has to end with the news. In July 2024, DeepMind's AlphaProof and AlphaGeometry 2 reached silver-medal level on that year's IMO problems — 28 of 42 points, one point below the gold cutoff — with an asterisk: the geometry problem fell in seconds, but some of the rest took days, well beyond contest conditions. A year later the asterisk was gone. In July 2025, Gemini Deep Think was officially graded gold-medal standard at IMO 2025 — 35 of 42, inside the four-and-a-half-hour limits, working in natural language — and OpenAI announced a comparable experimental result the same week. As of mid-2026, frontier models also perform at grandmaster-plus level on competitive-programming benchmarks. Every claim in this paragraph is dated on purpose; in this genre, undated claims are already wrong.

So a fair question now hangs over everything this chapter described: why train a human to do what a data center medals in?

Hold the question; it belongs to Part IV, where it gets dates, numbers, and the occasional surprise rather than a shrug. But two things can be said already, because they follow from this chapter alone. First, the culture was never really about the medals. It is the most refined curriculum humanity has built for installing recognition primitives in a human head, and the primitives, not the trophies, are what transfer. Second, look back at which habits the culture drills hardest: stress-testing your own solution, journaling your own errors, struggling before reading answers, decoding a hidden author's intent. A mind trained this way is not merely a generator of solutions. It is an auditor of them — anyone's, including a machine's.

The arsenal itself comes next: five kill shots, five building tools, six ways of seeing — each with its definition, its recognition signal, a worked pair of problems, and an honest line on what machines can and cannot yet do with it. What you have just read is how to hold them.