Teams are composed of three students, at most one can be a grad student. Each team gets one terminal. Teams are given a packet of 6 problems. They try to solve as many problems as they can in 5 hours.
Contestants are allowed to bring whatever printed material they want: books, printouts, magazines, manuals, etc. Teams may use any on-line documentation that is on their machine. Teams may not bring their own computers or calculators.
Team members may talk to each other, but not to anyone else. You may not send email, use a web browser, or FTP. You may leave the room to go to the bathroom or work in your team-room, but you may not call anyone or go to the campus library to look up information.
Teams submit their solutions via a submit command that emails it to the judges. Judges test your submission with their own test data that you never see. The judges test data is normally much more difficult to handle than the sample input on the problem specification. They send you a reply email with one of the following codes:
You only get the result code. You never get any details of which test case failed or why. In the case of a run-time error you are not given any information about what the error was (they might give you the one-line unix error message, e.g., segmentation violation, or bus error).
The team that solves the most problems wins. In the case of a tie (which always happens), the team with the lowest score wins. Scoring is done as the sum of the number of mintues from the start of the contest until each problem is solved. So solving the easiest problems first gives you a much better score.
In a nut-shell here are words of advice that can help you win the contest. The rest of the handbook presents them in more detail.
Key: Practice makes perfect. You will find that you can solve problems much faster after practicing with similiar problems.
Key: Choose problems carefully. Each problem packet has a range of easy and to problems. Working on easy problems first is key to winning. Being able to read problems and decide if they are easy or hard is a key skill.
Key: Only complete programs count. Don't spread your team too thin by trying to solve too many problems. Don't start new problems if you are not confident that you can solve the ones you team has already started.
Key: Only correct programs count. Read the problems carefully. Underline explicit requirements that you see. If you think of an implied requirement make a note of it on the problem sheet.
Key: Stay calm and relaxed. Don't panic or get burned out or frustrated. Practicing for 4 or 5 hours helps. If you get too frustrated, ask your team members for help or let them take a try at it. If you hit a bug, don't stay on the terminal, make a printout and let someone else use the terminal for a while.
Strategy: Dont bother solving the warm up problem. Instead use that time to configure your workstation and enter some library code. Make sure that every team member gets a chance to use the keyboard for a while. Try to print out some source code. Make sure you can use the compiler and submit something, e.g., "hello world". Try the debugger. Basically make sure that your account is properly set up.
Strategy: Check the scoreboard mid-way through the contest. Look to see what problem other teams are successfully solving first. Maybe that problem is easier than you thought. Likewise, if no one has solved the problem that you are working on, maybe it is harder than you thought.
Tip: Bring some off-color (not white) paper for scratch paper, e.g., a legal pad. That makes it much easier to find your notes in a pile of printouts. Engineering paper is good.
Tip: Write your contest password on the inside cover of one of the books you brought. That way there is less chance that it will be lost. Don't change your password.
Tip: Get a good night's sleep before the contest. And try to do work 2pm until 7pm for several days before the contest.
Tip: Dont eat too much at lunch on the contest day, it will make you sleepy. Also, stay away from sugar until the last hour of the contest. Try to walk and stretch occasionally.
Tip: You might want to bring a wrist rest.
Tip: Dress confortably. Make sure you have a light jacket that you can take off or put on, just in case you under the air conditioner.
Tip: Try to get a terminal that has some extra space near it. That gives you more room to spread out books and papers and for everyone to gather around the screen.
Trick: If your code has some cases that you think should never be reachable, try putting code there that will cause a run-time error with an unusual unix error message. For example, if you expect to find a certain string in a look up table, but it is not found, purposely do a divide-by-zero instead of printing out "impossible case, the code should never get here". That way you will get RUN-TIME ERROR instead of WRONG ANSWER. That can give you a clue about what requirement you are missing. Don't do this unless you have already had one WRONG ANSWER and spent a lot of time with at least two people looking for overlooked requirements. If you do this trick too soon you may find that you cause an error on a run that might have worked.
Trick: The contest organizers sometime say that they will delete all files in the contest accounts during lunch, but they usually cannot actually do that, so any library code you enter during the warmup problem period will still be there. If they do actually delete it, at least you got to practice with the keyboard.
+ You don't need to write beautiful code, but you should write code that you and people on your team can understand. If you name all your variables a, b, c, d, e, ... you will get confused. Choose short names that mean something and that will not get confused with other things in the program and in the problem statement.
+ DO NOT use variable and function names that are defined in the standard C library. For example, if you write a C program and name a function readline, it will never be called because there is a standard library function with the same name. If in doubt, try using the unix man command, e.g. "man readline".
+ Place opening braces on the same line as a control structure. This avoids the common error of using a semi-colon and an opening brace. For example, what is wrong here? for (int i = 0; i < N; ++i); { Array[i] = 0; }
+ Try to avoid using pointers and dynamic memory allocation because that can be error prone and hard to debug. Most contest problems can be solved using only fixed sized arrays. If one object in an array needs to refer to another, use the array index instead of a pointer.
+ Use C++ as a better C. You don't need to use classes.
Here is an outline of a step by step process for what you should do during the contest.
+ As soon as you get the problems start reading them quickly. Discuss with your team members which problem is the easiest one. The fastest programmer should start on the easiest problem within the first 30 minutes of the contest. Spend a few extra minutes to make sure you have the easiest one, that is more important to than getting started as soon as possible. Usually the easiest problem needs no written design, but the fastest programmer should be able to say what they plan to do and the others should agree that it will work.
+ One person takes responsibility for each problem, other people help him check the design against the spec, test the program, and submit it properly.
+ Before submitting a solution, always do the following: check any questions that have been asked and answered about that problem; reread the spec; test you program with harder test data than what is specified in the sample input; have someone watch you type the submit commands.
+ Try to solve exactly 4 problems. Don't even think about trying to solve 5 problems unless you already have 4 problems basically done and there is time left in the contest.
+ Remember that you cannot solve 4 problems until you have solved 3 problems. Don't start the 4th problem unless you have 2 problems done and accepted and 3rd problem is well on its way to being solved and there is at least 2 hours left in the contest. Many teams end up with only 2 correct solutions and 2 half-done solutions because they never FINISH their 3rd problem.
+ Timeline, If things go very well and we can get 4.
[Hour 1] [Hour 2] [Hour 3] [Hour 4] [Hour 5]
person1 RR1111 111122 224444 444444 444444
person2 RRRRR2 222122 223333 333333 444444
person3 RRRRR3 333333 333333 333333 444444
+ Timeline, If the easiest problem is not solved in under two hours and the second easiest is not solved before the end of the third hour, we can still get 3 if we focus.
[Hour 1] [Hour 2] [Hour 3] [Hour 4] [Hour 5]
person1 RR1111 111111 111222 222222 333333
person2 RRRRR2 222222 111222 222233 333333
person3 RRRRR3 333333 333333 333333 333333
+ Timeline, This is how well things have to go to finish 5. This is why I recommend you don't try to do 5 unless you have 4 in the bag.
[Hour 1] [Hour 2] [Hour 3] [Hour 4] [Hour 5]
person1 RR1111 112222 444444 444444 555555
person2 RRRRR2 222122 333344 444444 555555
person3 RRRRR3 333333 333344 555555 555555
+ It can be hard to tell which is the second easiest and which is the third easiest. Whoever feels more ready when the fastest programmer is done can consider their problem the second easiest.
+ Remember to check the scoreboard to see which problems other people are solving.
+ Make sure you know all the right I/O functions: scanf, sscanf, getline, printf, sprintf. And the cin and cout options.
+ Using while loops to read and putback individual characters can work, but it is very tedius and error prone. Higher lever I/O and string functions are much better.
+ Make sure you know all the right string functions: strcmp, strncmp, strcpy, strncpy, strtok, strstr.