How to Practice
How to practice and when to read editorials (analyses) according to various USACO competitors.
Reaching a high level in competitive programming requires dedication and motivation. For many people, their practice is inefficient because they do problems that are too easy, too hard, or simply of the wrong type.
In the lower divisions, most problems use relatively elementary algorithms; the main challenge is deciding which algorithm to use, and implementing it correctly. In a contest, you should spend the bulk of your time thinking about the problem and coming up with the algorithm, rather than typing code. Thus, you should practice your implementation skills, so that during the contest, you can implement the algorithm quickly and correctly, without resorting to debugging.
Problems that you practice with should be of the appropriate difficulty. You don't necessarily need to complete all the exercises at the end of each module, just do what you think is right for you. A problem at the right level of difficulty should be one of two types: either you struggle with the problem for a while before coming up with a working solution, or you miss it slightly and need to consult the solution for some small part. If you instantly come up with the solution, a problem is likely too easy, and if you're missing multiple steps, it might be too hard.
This and this are two blog posts by Evan Chen that I find quite insightful. They discuss such things as time management, the problem-solving process, and other tips that you may find useful. See my FAQ for more information.
Knowing when to "give up" on a problem and start reading its solution (editorial or analysis) is challenging. Note that "give up" is in quotes, because one still learns when they "give up" and read the solution! Below are the opinions of various individuals.
In general, I think it’s fine to read the solution relatively early on, as long as you’re made several different attempts at it and you can learn effectively from the solution.
- On a bronze problem, read the solution after 15-20 minutes of no meaningful progress, after you’ve exhausted every idea you can think of.
- On a silver problem, read the solution after 30-40 minutes of no meaningful progress.
- I think that when you get stuck and consult the solution, you should not read the entire solution at once, and you certainly shouldn’t look at the solution code right away. Instead, it’s better to read the solution step by step until you get unstuck, at which point you should go back and finish the problem, and implement it yourself. Reading the full solution or its code should be seen as a last resort.
My personal opinion is that it is okay to give up early when solving CP problems. Sometimes I spend as little as 15-20 minutes on a problem before reading the editorial or at least glancing at solution code. Other times I may spend significantly longer.
CP editorials generally aren't the best (with the exception of USACO editorials, which are pretty good) so I often spend a lot of time trying to understand the solution even after "giving up" and reading the editorial. I think it's good enough to implement the code without having the editorial open.
My justification for why I think it's okay to give up so early is as follows:
- Getting frustrated and quitting CP for a week is worse than giving up
- Whenever I feel like I'm really frustrated with a problem, I read the editorial
- CP editorials are usually difficult to understand, so you will still have to spend a lot of time reading and understanding them
- You learn a lot by reading editorials
- If you can solve a problem without reading the editorial, that means you probably could have solved the problem in-contest too, so you didn't actually learn that much. However, if you didn't know how to solve a problem and you read the editorial so now you do, then you've learned a lot more.
- In other words, reading editorials is a good thing, not a bad thing!
Overall, I would just say to "give up" when you feel like giving up, whether that's in five hours or in 15 minutes :)
If you're still coming up with new ideas, keep thinking. Otherwise, you have several options:
- Look at [part of] the solution. (If CodeForces, look at the tags.)
- Leave it for a while and do something else if you actually want to solve it on your own.
- Get a hint from someone else.
I'm impatient, so usually I go with the first option. Sometimes I end up reading an editorial before reading the statement, but idk if this is a good strategy. :/
In any case, if you thought about a problem a lot during a contest but didn't end up solving it, then I don't see any reason not to read the editorial when it comes out (vs. continuing to think about it on your own). Also, you should always implement the solution afterwards!
There are two ways to grow from solving a problem:
You learn ideas from problems you cannot solve. This means that you need to read an editorial or someone else's accepted solution. Always start by trying to understand the editorial; it's an important skill to have. A sufficiently difficult concept/idea requires multiple re-readings and drawing various examples. If this doesn't work, then you will need to either read solutions or reach out.
Although reading others' solutions is difficult, I find it to be an incredibly useful skill. If your code is barely timing out, maybe try looking to a faster accepted solution for optimizations. Additionally, there have been rare cases where the editorial solution outclassed by another faster, shorter solution. The primary way I have identified this is by reading accepted submissions.
When asking for help, be sure to point out the specific idea that is confusing. General questions end up being answered by summarizing the editorial - not particularly useful.
Finally, hints are overrated in my opinion. Just read the whole solution. You don't gain anything from reading part of a solution then finishing it out yourself. As long as you implement it in the end, you are still learning the same thing.
The best way to do this is to solve a bunch of easy or moderate difficulty problems. Try to solve them as fast as possible, as if you were in a contest. Perhaps take virtuals or time yourself when solving problems. Whichever you choose, the more problems you solve, the better you will become.
Read the editorial when you feel like you've stopped making progress; that could be from 1 to 5 hours. However, the most important part about reading the editorial is that you understand the topic and try to think about what similar problems look like. Being generally curious is a good way to practice algorithmic thinking.
I follow three guidelines (from most important to least important)
- Having fun, just doing whatever you feel like doing.
- Spend about the same amount of time that you would be able to during a real contest.
- Whether you are making progress or not.
I think the most important thing regarding practicing is to try to get something out of every problem, whether it's a new algorithm or idea, an implementation trick that can help in the future, or just a bug you hopefully won't mess up in the future. That being said, editorials are more useful once you've been stuck for a while; I think the exploration that happens from being a little stuck is often instructive (and good practice for contests, when it's your only option). But at some point the problem's more frustrating than helpful, and sometime before this is probably the right time to take a hint or read the editorial.
Do hard problems, and try to learn something from them. If you read the editorial, think about how you would arrive at the solution if you were to solve it again. Also, it's important to implement every problem you read the editorial of. Most importantly, don't burn yourself out, or you'll just be worse off in the end because your practice isn't efficent.
Join the USACO Forum!
Stuck on a problem, or don't understand a module? Join the USACO Forum and get help from other competitive programmers!
Give Us Feedback on How to Practice!
Leave suggestions for us by making a post on the USACO Forum! Ex: Unclear sections, mislabeled problems, etc.