I've sketched out some hints for working in groups of three. Remember, each group gets must share one workstation and you can use the printer. The practice isn't over go home until your team solves five problems or until at least two of the other teams have solved five problems.

Team Work Suggestions

. Bring a pad of paper and writing utensils of choice for paper work. Most of your coding work will be done off-line.

. Read each problem carefully. Consider what the difficult input may be and write it down for sample input if possible. Consider alternative solutions if you can.

. Plan your debugging in key places of your code.

        #define D
        ...
        #ifdef D
            cout << "I is now " << i << endl;
        # endif

. Enter the sample input given on the problem into a standard file called `input' or some such. If you have time, help figure out the challenging test input cases and add them.

. Don't hog the terminal.

      Get in,
      get your code and sample input entered,
      run your program,
      if it works on the test input
        submit it
      else
        print the program and the output
      give up the terminal

. If you find an easy problem, have someone start coding that one right away. The others can work on understanding and solving other problems on paper.

. Work on one problem at a time. Get it solved completely before wasting your time trying another.

. Have each team member working on a separate problem in parallel. You may want to read and analyze the problems together as a group before you start coding.

. Once you submit a solution, start working on another (off-line) right away.

. Be sure you have a system for letting each other know which problems you are working on and which are solved. Don't lose any of the problems (this only applies to paper versions).

. After you enter your program, test it on the sample input. If it works correctly, submit it right away. Otherwise, print the source and the sample run and give up the terminal (unless you know immedeately how to fix it).

. At some point, it may be helpful for you to get help from another team mate. Beware that it will take them a while to spin-up (understand the problem, understand your code, etc). It is best if you can solve your problem without any help.

. If you finish a problem on paper, but don't yet have access to the terminal, select another problem and solve it. You should be next in line for the workstation.

. Favor array implementations over dynamic memory implementations.

. Know Dynamic Programming, TSP solutions, language parsing, input and output formatting, etc.