51 lines
No EOL
3.4 KiB
Text
51 lines
No EOL
3.4 KiB
Text
---
|
|
id: contest-strategy
|
|
title: Contest Strategy
|
|
author: Nathan Chen
|
|
description: General ideas on how to strategize during a USACO contest.
|
|
---
|
|
|
|
(pdf?)
|
|
|
|
The best contest strategy is to go in knowing everything. However, only few people can do this, see [BenQ](https://codeforces.com/profile/benq) or [TMW](https://codeforces.com/profile/tmwilliamlin168). (I kid).
|
|
|
|
Once the timer starts, there's no more studying you can do, and managing your time wisely is the best thing you can do to maximize your score.
|
|
|
|
## Strategy
|
|
|
|
Strategy is flexible and all advice should be taken with a grain of salt. Strategy should be personal to *you* specifically.
|
|
|
|
### The beginning of a contest
|
|
|
|
You should read *all* the problems first (don't give up on any problems prematurely). Generally, a lot of thinking should happen before any coding. Depending on the difficulty of a contest, you can spend anywhere from 5 minutes to 2 hours with a pencil and paper before touching the keyboard.
|
|
|
|
Problem difficulties can be out of order, so keep that in mind before focusing down 3 hours on problem 1 and not getting anywhere. Do a good amount of thinking on each problem before deciding which ones to focus on and which to put aside.
|
|
|
|
### Time allocation
|
|
|
|
It's the worst feeling in the world to sink 4 hours into a problem and not get it, only for another problem to have an easier solution. You have to use your own judgement in deciding what is likely solvable and what should be quit. Generally, don't spend "too long" on one problem, and stay away from problems that look like they test something you don't know well.
|
|
|
|
### When you see a solution
|
|
|
|
If you immediately get the solution to a problem while reading it, it might be a good idea to code it up quickly and get it out of the way.
|
|
|
|
It also might be a good idea to make some progress on other problems before coding the one you know how to do. When you come back and start coding, you can make sure your solution still makes sense and then you have ideas from the other problems bouncing around in your head while you're coding.
|
|
|
|
### When there are partials
|
|
|
|
If you can get points from partially solving a problem (e.g. in USACO), then it's a good idea to keep those subtasks in mind. There are two main approaches to partially solving problems.
|
|
|
|
- Use most of your time to think about the full problem, then code the partials if you haven't found the solution and your time will soon run out.
|
|
- If you find the full solution, be certain your solution is correct, lest you waste an hour coding something completely wrong.
|
|
- Judge the difficulty of the partials carefully! It could take anywhere from 30 seconds to 30 minutes to code a partial, or maybe a partial wasn't as trivial as you thought!
|
|
- Work up from the partials, coding the easiest and then going to the hardest. The partial subtasks may help you think of the full solution, and will also help you stay on track.
|
|
|
|
## Personal Commentaries
|
|
|
|
### Nathan Chen
|
|
|
|
At the Platinum level, I first read everything and then I usually spend the first hour thinking about the easiest two problems (the hardest problem is usually VERY hard). I continue thinking for the rest of the contest window and I code them if I think I have the solution. I'm also the type to save partials for last, when time is running out and I still have nothing.
|
|
|
|
### Benjamin Qi
|
|
|
|
Do the partials you can; hopefully by then you've figured out the full solution. :D |