Putnam Warmups: Training Guide
Putnam-style problems are different beasts. This guide is a playbook for starting, especially when you have no idea what to do.
First 5 minutes: make the problem talk
- Restate it in your own words. Identify what is given and what must be shown.
- Try tiny cases: plug in small numbers, small sets, small sizes. Write down what happens. If the problem involves a sequence, compute the first terms. If it's about sets, try sets of size If it's a functional equation, plug in
- Look for unchanging quantities (parity, mod, monotonicity, number of inversions, sign changes).
- Try to break it: what would make the statement false? Often that reveals the hidden structure. For example, if the problem says "for all ," try to find which n makes the statement barely true, or which would make it false if the condition were slightly weaker.
Mini-example: experimenting
If an operation is repeated, your first move is usually to compute what happens after step, steps, steps. Don’t “search for the solution” yet. Just collect facts.
You’re trying to produce something like: “After each move, this quantity stays the same” or “This value keeps increasing” or “Only these residues are possible.”
Micro-example: an invariant you can actually compute
Suppose you have a process where, at each step, you may replace a number by either
- , or
- .
A good “first experiment” is to track the value of modulo a small number. Let’s try modulo .
- If , then so the residue class mod does not change.
- If , then which just permutes the residues.
Starting from , repeated doubling cycles the residues:
So the “mod view” quickly tells you which residue classes you can keep hitting, and which ones you might never see. This is exactly the kind of cheap computation that often reveals the invariant you need.
A practical rule: thinking happens on paper
Many beginners get stuck because they try to “think harder” while staring at the problem.
That almost never works.
Mathematical progress usually begins when you start writing things down — even random attempts.
- compute a few values
- draw a picture
- rewrite the expression
- try to break the statement
- test extreme cases
The goal is not to be correct.
The goal is to generate information.
Once something appears on paper, you can react to it.
Before that, your brain has nothing concrete to work with.
In practice, most problems start solving themselves only after you stop waiting for an idea and start interacting with the problem.
The most common winning moves
Invariants
Ask: is there something that the allowed operation cannot change?
Typical invariants: parity, residue mod , gcd, sign, number of odd terms, “sum mod ”, and sometimes a cleverly defined quantity.
Extremes
If objects can’t get smaller forever, try choosing a smallest counterexample. Or track an “energy” that always decreases. This kills many process/game problems.
Rewriting
Rewrite expressions until the structure appears. For example: factor, complete the square, rewrite differences, or convert a condition into modular arithmetic.
When you're stuck: cycle through these lenses
When you hit a wall, don't just stare — shift your perspective. Try looking at the problem through different lenses:
- Compute three concrete examples and one extreme example (very large, very small, or a boundary case).
- Try a different viewpoint: mod 2, mod 3, mod 4… or parity/gcd.
- Ask: “If I had to prove this, what would I want to be true?” Sometimes working backwards reveals the path forward.
- Use one hint. Then try again for 5 minutes before looking at another.
The goal is to keep the problem moving. Each lens might reveal something the others missed.
After you solve it (or see the solution)
Once you have a solution — yours or someone else's — don't just move on. Take 2 minutes to ask:
-
What was the key idea? (An invariant? An extremal argument? A clever rewrite?)
-
Could I have found it faster? What did I miss in my first attempts?
-
What pattern does this fit? Is this a "track parity" problem? A "smallest counterexample" problem?
This is how you build instincts. The goal isn't just solving problems — it's recognizing types of problems faster next time.
A good attempt is not a full solution
Your goal is to develop instincts. A good attempt can be:
- a few examples and a pattern
- a candidate invariant
- a useful rewrite
- a partial lemma
When you want, go back to the track and start Problem 1.