“I knew what to do, I just ran out of time” is usually true, and it is the wrong diagnosis. Knowing the approach and being able to produce a correct 60-line implementation from cold, under a clock, with one sample test, are two separate skills. The second one is trainable, measurable, and almost nobody trains it deliberately. Here is how.
Two different failures that look identical on the scoreboard
A contest gives you typically three or four problems in a self-chosen contiguous block of about four to five hours, scored out of 1000 points. Two students both end on a low score. On the results page they look the same. In the room they were doing completely different things:
- Student A spent 80 minutes not seeing what the problem wanted. Once she saw it, the code took 15 minutes and worked. Her bottleneck is recognition.
- Student B saw within 5 minutes that it was a graph traversal. He then spent 90 minutes producing a traversal with an off-by-one in the visited check, discovered it at minute 100, and had no time left for problem three. His bottleneck is implementation.
These need opposite training. Student A should be reading many statements and classifying them without coding. Student B should be doing the thing this article is about: writing the same small set of routines over and over, from memory, against a clock, until producing them is boring.
The reason implementation gets neglected is that it feels like it does not need practice. You have written a BFS. You understand a BFS. The trap is that understanding a routine and being able to emit it correctly at minute 180 of a long contest, on three hours’ sleep, with a queue of your own anxiety running in the background, are not the same state. Under contest conditions your effective skill is not what you know; it is what you can do without thinking.
Measuring it: the cold reimplementation test
You cannot train what you do not measure, and “I feel slow” is not a measurement. The test is simple and slightly uncomfortable:
- Close every reference. No template file, no previous solution, no editor autocomplete on your own snippets, no search.
- Start a timer.
- Write a named routine from scratch, including reading input and printing output, as a complete program.
- Run it against test cases you wrote yourself, not just the sample.
- Stop the timer when it passes. Record the time and the number of bugs you had to fix.
The second number matters more than the first. A student who writes a correct union-find in nine minutes with zero fixes is in a completely different place from one who gets there in nine minutes after three compile errors and a wrong-answer round-trip — because in a contest every one of those round-trips is spent out of the same fixed clock.
Below are the benchmarks we use with students. These are our coaching team’s targets from working with China-based cohorts, not a USACO standard and not published by anyone official. Treat them as a yardstick you can argue with.
| Routine | Relevant from | Fluent looks like | Bug budget |
|---|---|---|---|
| Read n, then n integers, sort, print | Bronze | under 4 minutes | 0 |
| Grid flood fill / connected components | Bronze–Silver | under 12 minutes | 0–1 |
| BFS on an explicit adjacency list | Silver | under 12 minutes | 0–1 |
| Prefix sums, including 2-D | Silver | under 8 minutes | 0–1 |
| Binary search on the answer | Silver | under 10 minutes | 0–1 |
| Union-find with path compression | Silver–Gold | under 10 minutes | 0 |
| Dijkstra with a priority queue | Gold | under 18 minutes | 0–1 |
If a routine that your division assumes takes you 35 minutes and four bug cycles, you do not have a Silver problem. You have a typing problem wearing a Silver problem as a costume. The scoreboard cannot tell the difference; you can.
Your template, and the thing people get wrong about it
A personal template is the single cheapest speed gain available, and most students build the wrong one. A useful template contains only what you would otherwise retype identically in every single solution: language boilerplate, fast input reading, and perhaps a couple of type aliases. That is it.
What should not be in it is a library of pre-written algorithms you paste in. Two reasons. First, a pasted routine you have not written recently is a routine you cannot debug when it turns out this problem needed a small variation — and it always needs a small variation. Second, drilling is the point: every time you paste, you skip the rep.
The detail that catches people out is input and output. USACO accepts C, C++, Java and Python, and how a given contest reads input is stated in the problem itself. Do not carry an assumption from last season, from a training site, or from a friend’s template — open the statement, read the I/O section first, and confirm the current convention on usaco.org before contest day. A solution that is algorithmically perfect and reads from the wrong place scores nothing, and it is a completely avoidable zero.
One more template rule: whatever is in yours, you must be able to reproduce it from memory. If your template is so elaborate that losing the file would end your contest, it has stopped being a tool and become a dependency.
Three drills, and the week they fit into
These are short. That is deliberate — fluency comes from frequency, not from long sessions.
- Drill 1: the blind write (15 min, three times a week). Pick one routine from the table. Close everything. Write it as a complete program, test it, clock it. Log the time and the bug count in a file. That log is your progress evidence, and it will be more honest than your feelings about how the season is going.
- Drill 2: the 48-hour rewrite (once a week). Take a routine you wrote two days ago. Do not look at it. Write it again from cold, then diff the two versions. The differences are where your memory is reconstructing rather than recalling — and those exact spots are where your contest bugs will appear.
- Drill 3: bug injection (once a week, with a partner). Give a working solution to a club-mate (practice code only, never a live contest problem while its window is open); they change one character somewhere — a bound, a sign, an index, a comparison direction — and hand it back. You find it with a clock running. This trains the skill that actually decides contests: locating a defect in code you believe is correct.
A realistic week for a Silver-bound student in term time: three blind writes of 15 minutes, one 48-hour rewrite, one bug-injection round, and one longer session on actual past problems from our past contests archive. That is under two hours of drilling, and in our coaching team’s experience it moves a contest score more than an extra two hours of reading editorials would.
Debugging economics inside the four hours
Fluency also changes how you should behave when something goes wrong, because you now have a reliable prior about yourself. Three rules we teach:
- Reread the statement before you reread the code. In a contest with one sample test and a long statement in your second language, a meaningful share of “bugs” are misreadings. Thirty seconds on the statement is cheaper than ten minutes in a debugger.
- Ten minutes, then rewrite. If you have been hunting one defect for ten minutes in a routine you can write from cold in twelve, delete it and write it again. Students resist this because the existing code feels like sunk value. It is not; it is a haystack you already searched.
- Bisect with output, not with staring. Print intermediate state at the halfway point of the pipeline. Half your uncertainty disappears per print. Staring at code scales badly under adrenaline; bisection does not.
Note the shape of rule two: it is only available to you if you are fluent. A student who needs 35 minutes for a BFS can never afford to throw one away. Fluency does not just make you faster — it unlocks a recovery strategy that slow students are structurally denied.
What fluency does not fix
Being honest about the limits matters, because drilling is seductive: it is measurable, it feels productive, and it can quietly become a way of avoiding harder work.
Fast typing will not tell you that an approach is too slow for the constraint bound — that is complexity budgeting, and it is decided before you write anything. It will not tell you which of the three problems to open first. It will not teach you an algorithm you have never met, which is what actually separates the divisions; the algorithm families you need are listed by division in our division guide. And it will not, by itself, clear a promotion cutoff — recent seasons have sat somewhere in the region of 650 to 750 out of 1000, but that number is set per contest by USACO and moves, so check the current figures on usaco.org and on our cutoff page rather than planning against a remembered value.
What fluency does is stop you losing points you had already earned in your head. For most students stuck one division below where they think they should be, that is the entire gap.
Frequently asked questions
Q: Are the times in your table official USACO benchmarks?
No. They are our coaching team’s targets from working with China-based students. USACO publishes no such standard; treat them as a yardstick.
Q: Should I memorise a template with algorithms already in it?
Keep boilerplate and fast I/O only. Pasted algorithms skip the rep and are hard to debug when the problem needs a variation.
Q: How do I know whether input comes from a file or standard input?
The problem statement says. Read it every contest and confirm the current convention on usaco.org — never carry an assumption over.
Q: How often should I drill?
Short and frequent: about fifteen minutes, three times a week, beats one long weekend session for this particular skill.
Independent guide operated by Hanlin Education for China-based international-school students. Not affiliated with, endorsed by, or sponsored by USACO (the USA Computing Olympiad), the IOI or EGOI. Registration, contest rules, dates and promotion cutoffs live on usaco.org — confirm current details there before planning around anything on this page. Errors reported to our editorial desk are corrected within 7 working days.