SOF IMO common mistakes
SOF IMO · Understand the traps and how to avoid them.
Reading only the first few words of a question and answering the 'obvious' version instead of the one actually asked (e.g., solving for x when the question asks for 2x+1, or counting total items when asked for the number remaining).
Under time pressure the brain pattern-matches to a familiar problem type and skips the qualifier ('not', 'at least', 'in terms of', 'how many more'). Competition questions are deliberately worded to punish this shortcut.
What to do instead
Before computing, underline the exact quantity requested and rewrite the question in your own words as a one-line target (e.g., 'find remainder, not quotient'). At the end, re-read the final sentence and confirm the number you boxed matches the target, not an intermediate value.
Treating a diagram or described figure as if it were drawn to scale, assuming lines are parallel, angles are right angles, or segments equal when nothing states this.
Geometry figures on olympiad-style papers are schematic and often intentionally misleading; visual intuition is fast and feels reliable, so it overrides stated conditions.
What to do instead
List the given conditions explicitly and only use those. Before any angle-chasing or similarity claim, write the justification (given, definition, or proven theorem) next to it. If the answer depends on a property not in the givens, re-derive it or test a distorted sketch.
Counting outcomes without checking whether they are equally likely, or double-counting cases in a combinatorial count (e.g., counting ordered pairs when unordered are wanted, or forgetting to subtract overcounted arrangements).
The formulas for permutations and combinations look interchangeable, and case-splitting feels complete when it is not; there is no feedback signal that a count is wrong.
What to do instead
State whether order matters and whether repetition is allowed before choosing a method. Verify small cases by brute-force listing (n=2,3), and cross-check with a second method (complement counting or a symmetry argument) so an overcount shows up as a mismatch.
Skipping the proof or justification step and writing only the final answer, or asserting a step ('clearly it is divisible', 'by symmetry') that is not actually established.
School habits reward the answer only, and full proofs are time-expensive; candidates also mistake a plausible pattern from a few cases for a proof.
What to do instead
Treat the justification as part of the answer: for each nontrivial claim write the theorem or identity used. When a pattern is suspected, prove it by induction or by a general argument, and reserve 'by symmetry' for cases where the symmetry is explicitly described.
Testing a few values, seeing a pattern, and assuming it holds for all n without proof; or conversely rejecting a valid general result because it fails for a careless test case.
Inductive pattern-spotting is fast and often correct on easy items, so it becomes a habit; the counterexample that breaks the pattern usually appears only at larger n or edge values.
What to do instead
Use test values only to generate a conjecture, then prove it. Deliberately test boundary and unusual values (n=1, 0, negative, large, non-integer where allowed) and check whether the pattern's formula still matches before trusting it.
Mishandling parity, divisibility, or modular reasoning: forgetting that squares are 0 or 1 mod 4, that a sum of two odd numbers is even, or that dividing an inequality or congruence by a quantity requires it to be nonzero/invertible.
Modular arithmetic and parity arguments are taught briefly and applied loosely; the invertibility condition is invisible when working with ordinary integers.
What to do instead
Before dividing or cancelling in a congruence or inequality, write the condition (modulus coprime to divisor, quantity nonzero/positive). Memorize the small residue facts (n² mod 4, mod 8; cubes mod 9) and use them as the first tool on integer equations.
Misreading or ignoring constraints such as 'distinct', 'positive integers', 'at most', 'exactly', or units, then solving an easier unconstrained problem.
Constraints are short words embedded in long sentences and are easy to skim; the unconstrained version often has a clean answer, which creates false confidence.
What to do instead
Copy every constraint into a checklist beside the working and tick each one against the final answer. If the answer violates even one ('x=0' when positive is required), discard and re-solve rather than patching.
Spending too long on one hard problem, or conversely rushing the early easy problems and making arithmetic slips that cost more marks than the hard problem would gain.
Olympiad scoring rewards depth, so candidates over-invest in a single problem; early items feel trivial and get done at speed without checking.
What to do instead
Adopt an explicit time budget per problem and a rule to move on after a set interval, marking the problem for return. Do a fast independent re-check of early answers (recompute by a different route) before touching the hard ones.
Making sign, order-of-operations, and algebraic-expansion errors when substituting or simplifying under time pressure (e.g., (a+b)² written as a²+b², or dropping a negative sign when moving terms).
Working memory is loaded by the logical structure of the problem, so routine algebra runs on autopilot and small slips pass unnoticed.
What to do instead
Write each algebraic step on its own line and substitute numerical values back into the original equation to verify. Slow down specifically at expansion, sign changes, and division, and keep a running check by plugging the candidate answer into the original statement.
Leaving an answer in an unfinished or non-matching form (unsimplified fraction, expression instead of a number, wrong units, or a value outside the feasible range) and not sanity-checking magnitude.
The reasoning feels complete once a value is reached, so the final normalization step is skipped; answer-format rules are easy to overlook.
What to do instead
Before submitting, simplify fully, confirm the requested form, and run a magnitude check (is the answer plausible given the constraints?). If the result is a fraction where an integer is expected, or negative where positivity is required, treat it as a signal to re-examine the work.