Competitive programming: the path that works

Competitive programming is the purest deliberate-practice environment in software: immediate, unambiguous feedback at a precisely calibrated difficulty. Here is the path I’d recommend, having watched many people (myself included) waste months on the wrong parts.

The core resources

• Competitive Programmer’s Handbook — Antti Laaksonen. Free PDF, ~300 pages, zero fluff: the entire standard toolkit from complexity through segment trees, graphs, DP, and string algorithms. This is the book to work through, not merely read.
• CSES Problem Set — the companion problem set: ~400 problems in curated topic order. Finishing the first ~200 honestly (no editorial until a real attempt) is the single best foundation-builder that exists.
• USACO Guide — the best-structured free curriculum: Bronze through Platinum with explanations, curated problems per module, and progress tracking. Even outside USACO, it is the clearest topic ordering available.
• Codeforces — where the actual practice happens: live contests every week, the problem archive, and editorial + hacks culture. The ITMO Academy courses (binary search, segment trees, string algorithms) are quietly excellent and free.
• AtCoder — cleaner problem statements than anywhere else; ABC rounds are the best-calibrated beginner/intermediate ladder. The AtCoder DP contest is the canonical DP bootcamp — all 26 problems.
• cp-algorithms.com — the reference wiki (translated e-maxx): when you need Dinic’s, suffix automata, or CHT explained with working code, it’s here.

The practice loop that actually works

Everything above is inert without the right loop. The consensus of every strong competitor who has written advice (see Errichto’s FAQ and Um_nik’s “how to practice”):

1. Solve problems slightly above your level — rated ~100–200 above your rating. Too easy is typing practice; too hard is reading practice.
2. Struggle honestly before the editorial — 30–60 minutes minimum. The struggle is the training signal; the editorial is the answer key.
3. After reading an editorial, implement it yourself from memory, then solve two similar problems. Understanding without implementation evaporates in a week.
4. Do live contests and upsolve the first problem you couldn’t crack. Contests train the part practice can’t: performing under time.
5. Keep an error log — WA because of overflow, off-by-one in binary search, unhandled n=1. Your bugs are far more repetitive than you think.

Why bother, outside contests

Beyond interviews: CP is where I built the reflex of asking “what’s the invariant?” and the habit of testing edge cases before running. Both show up directly in the fuzz-tested and property-tested projects on this site. The transfer is real, but only from problems you fought for — not from editorial tourism.