Team strategy

This article discusses the team strategy for ACM ICPC style contest where you are 3 people in a team and compete for 5 hours. There are other team contests with different rules but I only focus on ICPC.

These are the three most important facts you should bear in mind during the ACM ICPC contest:

It is a team competition and each team has 3 members.
Computer time is very expensive.
The beginning of the competition is the most important part of the contest.

General strategy

From the 3 facts above you can derive a very good strategy. At the beginning of the contest, the quickest typist writes a code template and perhaps a script for compiling. Due to ICPC scoring it’s optimal to solve easier problems first, so the two others skim through the problem set in search for an easy problem (one person going from the back, one from the front). As soon as a sufficiently easy problem is located (one that can be solved within, say, 10-15 minutes), it is given to the quickest typist along with a quick description.

The other two non-coding teammates continue skimming through the problem set. If something easier than the first problem is located (solvable in 5 minutes), it takes priority. After at least one member of the team has read each problem statement, the two non-coding teammates should discuss all the problems they have just read.

What should not happen in the beginning: After reading the first problem I see that I am able solve it. I ignore other problems and continue solving this problem for the next 2 hours without success, while there were were 2 other easier tasks that I didn’t read. That’s one of the reasons why reading all problems and discussion between members in the beginning are so important.

The team continues with solving problems. If someone knows how to solve a problem and nobody uses computer, he/she should code it. If the computer is not available, prepare the code on the paper.

The precise team strategy should be further adapted to the skills of the team. For example, someone who is very good at problem solving but not so good programmer should work mostly on paper and explain solutions to others who then implement them. Teams should train together often to get to know each other’s strengths and weaknesses and then apply the knowledge to find the best strategy for the team. It is therefore useful to train even if one person is not present and only 2 of you train together. Also ask your coach to watch you and give you tips.

Other tips

You are now familiar with the overall strategy. Let us discuss other tips.

If you are not sure about your solution, discuss it with your teammates. If stuck, explain problem to a teammate. Use good judgement if it is worth the interruption of him/her.
If you have time, write code on paper before you go the computer. It will save a lot of computer time for the whole team. You do not have to write all the details, but try to focus on the most important parts of the program. For example, if you are writing binary search, make sure you do not have +-1 errors.
Do not debug code on the computer. Print your code together with some debugging output and debug on paper.
If you are stuck on a problem, take a walk or go to the toilet. The best ideas come to mind here.
If you keep getting WA on a problem, let it be for a while and try to solve another problem. Maybe you will get an idea how to solve it afterwards. Do not hesitate to do a complete rewrite of a solution. For most of the problems it can be done in 15 minutes.
Is it easy to generate some large inputs, or inputs where you know the answer? If yes, it may be worth doing so to test a bit more before submitting.
When you are done with a problem, throw all papers concerning that problem onto the floor (problem set page, printouts, handwritten stuff). Saves some time searching for paper, and feels good.
Look at the scoreboard every now and then. If there is a problem that many other teams solved, it should be easy.
Keep track of all submissions on a sheet of paper, and keep track of who is working on what problem.
Print early, print often. Print every time you submit.
Do not forget the endgame strategy. When time is starting to run out you do not want all three people working on separate problems, but focus on one problem. Try to make sure that all people are still doing something useful (e.g. one person looking over the back of the coder, and another person trying to come up with tricky test cases). Knowing when to enter this mode can be difficult and in particular it takes some willpower to give up on those additional problems that one knows how to solve but just have to code up…
In some cases you want to assign one person to work on a hard problem 2-3 hours before the end, because you want to avoid the following situation. Suppose everything goes well and you take turns using the computer, solving the 8th problem after 4 hours. There are two hard problems left but to solve each one you need one hour of thinking and 45 minutes of programming. Theoretically you have 3 × 1 hours split among three people which is more than 1:45 hours, but the one thinking hour cannot be split between three people and you need to wait for the solution before you start writing it.
So called free submit mode is to be used with caution. If it is not clear, its meaning is roughly “at this point, solving another problem is more important than any time penalty it can possibly cost us so let’s just submit as soon as we have something that has a non-zero probability of getting accepted”. Usually it is not entered until the last 30 minutes or so, but if you have a bad start with many incorrect submissions so that you already have a large penalty, it can sometimes be entered very early (and sometimes exited if the outlook improves).
ICPC contests last for 5 hours, but training for 5 hours can block your whole day. You can do 3.5 to 4-hour trainings instead and the effect might be equally good. Even marathon runners run only 30 kilometers a day before the marathon while the actual race is 42 kilometers.