A USACO contest hands you one self-chosen block of four to five hours, roughly three problems and 1,000 points. Most of the points students lose are not lost to missing algorithms. They are lost to clock decisions: reading in printed order, chasing one problem far too long, and overwriting a solution that was already scoring. This is how to spend the window.
Three rules that quietly decide your whole strategy
Before you plan a single minute, three details of the grading system need to be sitting in your head. All three are set out on our contest rules summary, and you should confirm the current wording on usaco.org before your first contest, because format details are reviewed from season to season.
- Only the last submission per problem is graded. Not your best submission. Not your highest-scoring submission. The last one. This single rule is responsible for more heartbreak than any algorithm.
- There is no penalty for resubmitting before your timer expires, though USACO does ask you to keep your resubmission rate reasonable to reduce load on its server. You are not fined for wrong attempts the way you are on some competitive-programming platforms.
- Feedback is immediate and per test case. You see, case by case, what passed and what did not, while the clock is still running.
Put those together and the strategy writes itself. Because there is no resubmission penalty, you should submit early and often — a partially working program sitting on the server is worth more than a perfect program sitting in your editor. Because feedback is per test case, the grader is a diagnostic tool you can use mid-contest, not just a verdict at the end. And because only the last submission counts, every late submission is a risk you are taking with points you have already banked.
Students who understand rule two but forget rule three are the ones who finish a contest with 620 points and a working solution they submitted at minute 180 and then destroyed at minute 235.
The first twenty-five minutes belong to reading, not typing
The instinct is to open problem one and start coding. Resist it. The first block of the contest is a survey, and it pays for itself several times over.
Read every problem. For each one, write down three things on paper: the largest value the input can take, one sentence describing what you would actually do, and a confidence rating out of five. That is it — three lines per problem, maybe eight minutes each.
The input limits matter more than beginners expect, because they are effectively the problem setter telling you which family of solutions is intended. A limit in the thousands and a limit in the hundreds of thousands point at very different approaches, and the published technical limits — roughly 256 MB of memory and a per-test-case time limit measured in a small number of seconds — are the budget you are being asked to fit inside. Reading a limit as 100,000 when it says 1,000 will cost you an hour of unnecessary sophistication; reading it the other way around costs you the problem.
By minute twenty-five you should not have written any contest code. You should have a ranked list.
Solve in confidence order, not printed order
USACO problems within a division are broadly ordered by difficulty, but that ordering is about the average contestant, not about you. If you have drilled graph traversal and never touched interval logic, your personal problem two may be the field's problem three. Start with the one you rated highest, regardless of where it sits on the page.
Here is a worked plan for a four-hour timer with three problems. Treat the clock times as checkpoints, not as a script — the value is in the "failure signal" column, which tells you when to change course.
| Clock | What you are doing | What should be true at the end | Failure signal |
|---|---|---|---|
| 0:00 – 0:25 | Read all problems. Record input limits, a one-sentence plan and a confidence score for each. | A ranked list. Zero lines of code written. | You are already coding at minute 10. |
| 0:25 – 1:30 | Your highest-confidence problem. Code it, test the sample, submit. | One problem submitted with most or all cases passing. | 1:30 arrives with nothing submitted at all. |
| 1:30 – 2:40 | Second problem. Full solution if you see one; otherwise a correct brute force. | Two problems have something on the server. | You have gone 40 minutes without a new idea. |
| 2:40 – 3:35 | Third problem, or upgrade the partial answers from the first two. | Every problem has been attempted; no blank submissions. | You are rewriting a scoring solution from scratch. |
| 3:35 – 4:00 | Verification only. Edge cases, output format, final submission check. | The last submission on every problem is the one you want graded. | You submit brand-new untested logic after 3:50. |
Partial credit is the currency, and most students underspend it
USACO scores you per test case. Points are divided roughly equally between problems, and each problem is split across a set of test cases whose number varies from problem to problem, so a single test case is typically worth tens of points — check the case count on the problem you are actually sitting. That arithmetic changes how you should think about an unfinished problem.
A brute-force program that is obviously too slow for the largest inputs is not a failure. It is a correct program with a narrow range, and the smaller test cases are inside that range. Written in twenty minutes, it converts a blank problem into a real score. Compare that with the alternative many students choose — spending the same twenty minutes half-designing an elegant solution that never compiles — and the choice is not close.
Promotion works by clearing a cutoff on a given contest, and recent cutoffs have tended to sit somewhere in the region of 650 to 750 out of 1,000, though the number is set per contest and moves around; our cutoff score history shows how much it varies, and usaco.org is the authority on any specific contest. The practical point is that this is not a "solve everything" threshold. One clean full solve plus meaningful partial credit on the rest is a realistic shape for a promoting score, and it is a shape you can plan for. Chasing three perfect solutions and finishing one is not.
So: write the slow version first when you are unsure. Submit it. Then improve it. You will occasionally discover that the "slow" version passes everything, which is a pleasant way to learn that you misjudged the limits.
The abandon rule: how to know when to walk away
Sunk cost is the most expensive habit in contest programming. You have spent fifty minutes on a problem, so you keep going, because leaving feels like wasting the fifty minutes. In fact the fifty minutes are gone either way; the only live question is what the next fifty are worth.
Use a mechanical rule so you do not have to make the judgement while emotionally invested:
- Twenty minutes with no working idea → write the brute force, submit it, then move on.
- Forty minutes of debugging with no progress → leave it. Move to another problem and come back later; returning cold is astonishingly effective at exposing an obvious bug.
- Any point where you catch yourself re-reading your own code for the third time → stop reading it and re-read the problem statement instead. A large share of "my algorithm is wrong" turns out to be "I solved a slightly different problem."
The last thirty minutes: protect what you already have
The end of the window is not extra solving time. It is insurance time, and it is where the "last submission is graded" rule collects its victims.
Three things belong in the final block. First, run your solutions against the nasty inputs you can construct by hand: the smallest legal input, an input where every value is identical, an input at the maximum size, and anything the statement hints is a special case. Second, re-read the required output format — trailing detail, ordering, and what to print when the answer does not exist. Third, and most important, open each problem and confirm that the submission currently sitting there is the one you want graded.
The rule for the last twenty minutes is blunt: do not make an untested submission your final action on a problem that is already scoring. If you have a speculative improvement and you cannot test it properly, either test it properly or let it go. A working 700 beats an ambitious zero every single time, and the students who learn this the hard way tend to learn it exactly once.
One more habit worth building: practise this whole routine before it matters. Sitting a full past contest under a real timer, with the phone in another room, is the only way to find out that your plan collapses at minute 150. Our past contest archive exists for exactly that purpose, and a rehearsal that goes badly in September is worth far more than one that goes badly in December.
Frequently asked questions
Can I pause my USACO timer once I have started?
No. You choose when to start within the contest window, but the personal timer then runs continuously. Plan for an uninterrupted block.
Does a wrong submission cost me points?
No penalty applies for resubmitting before your timer expires. But only your final submission on each problem is graded, so late untested changes are the real risk.
Should I submit a solution I know is too slow?
Yes. Scoring is per test case, so a correct brute force banks the smaller cases. An unfinished elegant solution scores nothing at all.
Which problem should I start with?
The one you rated most confidently during your reading block, not problem one. Printed order reflects average difficulty, not your own strengths.
This is an independent guide operated by Hanlin Education for China-based international-school students. It is not affiliated with, endorsed by, or sponsored by USACO (the USA Computing Olympiad). Contest format, scoring, timing and rules are set by USACO and are reviewed from season to season — always confirm current details on usaco.org, where registration and participation take place. Any factual error brought to our attention is corrected within 7 working days.