So you made up your mind and are now competing in the ICPC. What does that entail?

Everything starts with good preparation. At most contests, you are allowed to bring a cheat sheet with your favorite algorithms. Make sure your cheat sheet contains all algorithms that you think will likely appear on these problems. It makes your life a whole lot easier if you can just take a fast algorithm for maximum flow from your cheat sheet instead of trying to remember how you did it last time.

Get an overview of the skills of your team. Oftentimes there are some things that one of the team members is good at that you can use. For example, if you know that a problem needs C++, let it be implemented by the one who can use C++ best. Also, it may prove useful to have dedicated experts for certain types of problems. Have, for example, one specialist for algorithms on graphs that can focus on solving all problems using graphs in a set. In this way you can focus on different areas when you train to solve problems.

You and your team arrived at the contest site, sat down at your single assigned computer, and got handed a problem set. The clock starts and you are now in direct competition with every other team in the room to see who is able to solve the most problems. Here we have compiled some tips our participants have accumulated over the years to make sure you are well prepared for that situation.

Right at the beginning of the contest, everybody is shooting for the low-hanging fruit. Almost always there are one or two very simple problems that can be solved in a few lines of code. You just have to find them. For that, it has proven helpful to divide he problem set into parts s.t. at the start everybody reads his assigned segment of the problem set.

To give your teammates an idea of what you read, you could create an overview sheet that contains the following (or more) information per problem:

- Topic (for example: Shortest Paths, Number Theory, etc.)
- Estimated difficulty of solving the problem (on a scale of 1-10, how hard is coming up with a solution)
- Estimated difficulty of implementing the solution (on a scale of 1-10, how hard is coding the solution)

You could also include a column that contains a flag if you solved that problem to document your progress. (Also the feeling to check off a program of that you worked hard on is just great.)

Always try to solve the easiest problem that you have not solved yet. Also, have a look at the public scoreboard. Oftentimes, there is a problem that many other people have already solved. Especially if teams with a lower rank than your team have already solved a problem, there is a high chance that you are also able to solve it.

At most competitions, you will only have access to a single computer and you have to carefully choose who gets to use it at any given time.

So before you start to implement anything, make up a clear plan of what you are trying to implement.
If you think you can solve a problem within a few minutes, just let one of you grab the computer and implement it, while the others start thinking about other, more difficult problems.
For harder problems it might make sense to write down pseudocode and work out the algorithm from there or even do pair programming.

If you have an almost working solution that seems to have a bug, print your source code. According to our experience, debugging using pen and paper is a valid technique and saves valuable time at the computer. If you still cannot find the bug, try to explain your code to someone. This can be either a teammember or even the wall. Just try to put your algorithm into words. (Of course a teammate is even better - time has shown that teammates find more bugs, on average, than walls.) This has proven a massive help when there is a logical flaw in your algorithm.

Shortly before the end, you will probably end up with some problems that did not work. From our experience it is better to try to get these working instead of beginning a totally new problem and ending up with a half-finished implementation when the contest ends. In the end, just try to submit different versions that you believe could work.

Lastly, even though this is an adrenaline-packed contest situation, don't forget to have fun. Get up from your desk, have some pizza. Sometimes this change is enough to give you that "Heureka"-moment that lets you finally solve a problem. Also, don't get stuck on something too hard. Sometimes your solution just does not work and that's okay. So take a step back and either try a different problem or free your mind and take a fresh approach.

(c) ICPC@TUM, Contact/Imprint