For a team based competition such as the ACM ICPC Programming Contest, team work is an important part of the contest. The following are some of the strategies that we have used and found to be useful.
Since the penalty for each correct submission is time taken since the beginning of the contest, its important to solve easier problems first. This gives you a lower overall time penalty and having solved a problem sucessfully will improve the team's confidence. Hence it is important to first read all the problems and estimate the level of difficulty of each problem, taking into account the complexity of the algorithm, implementation difficulties and possible special/boundary/tricky cases in the input.
Even though there is a time penalty for each problem solved, you should avoid rushing. This is to avoid careless mistakes or misinterpreting the problem. Read the problem description carefully, sometimes problem setters like to hide important pieces of information in a long problem description. Furthermore each wrong submission incurs a penalty of 20mins plus additional time to debug the solution. Therefore it pays to implement carefully and have fewer bugs rather then to spend time debugging.
For problems with long descriptions, it might be useful to highlight the important pieces of information such as the size of the input parameters, special contraints/rules in the problem etc.
Use a piece of paper to record down for each problem in the contest the following pieces of information
The purpose of the record sheet is to keep track of the status of the 9 to 10 problems in the contest and to ensure that eventually everyone has looked at all the unsolved problems. Estimating the amount of time allows us to solve the problems starting with the one which takes the least time.
Send a copy of the source code to the printer immediately after you submit and let the next person implement his solution. If the problem is not accepted, debug using the printed copy. As far as possible try to do all debugging offline.
It is better for a team member to create the test cases for the problem that another team member is currently solving. The test cases should be annotated with comments about what conditions the test cases are for. This will help the member who is solving the problem to realise if he/she has missed out considering some conditions in his/her solution.
Save all the test data you have created to test your program in a file. Before submitting the program ask another team member to check whether you have included all the boundard conditions in your test cases. This is to reduce the number of wrong submissions due to an error in the program. Usually the person implmenting the solution will tend to overlook some critical test data.
If you are unsure of the problem description or you are stuck with some parts of the algorithm for your problem, ask your team mates for assistance. Remember that this is a team effort and most of the time there will be someone with the right expertise for the problem at hand. If after consulting with your team mates there are still questions about the problem description, send a clarification request.
At the start of the contest, the focus should be on understanding all the problems. If there is a trivial problem, it should be solved first. In the mean time the rest of the team should continue to read all the problems. Decide the problems to be tackled based on the estimated amount of time to implement it and assign one team member to one problem.
The team will then take turns using the computer to implement their solution. The other members should either be thinking of solutions for this assigned problem/writing out the code on paper/debugging the source code. Towards the end of the contest with 1.5 - 2 hours remaining, the priority should be on trying to debug the problems which were implemented but were not accepted instead of starting a new problem. If need be assign two members to work on the same problem.
Sometimes you might find that for certain input parameters in the problem, no limits are given for the range of allowed values. Usually when this happens it is save to assume that the values are typically quite small. If you are still unsure, just send a clarification request.
Do not throw away problem which looks very difficult to solve. You may want to come out with a simple solution (brute force) and if you really can't do anything else, just submit this simple solution. You never know, the test data might be very simple when the problem is difficult.
Similarly, when the problem looks trivial, dont think that you must come out with a very efficient program to solve it and therefore dont attempt to do it. Unless you have a better solution, just provide a simple one.
This is especially true when you are stuck during the last 1 - 1.5 hours of the contest. Just submit the simple solution that you have.