Strategy

Post date: Oct 17, 2011 2:57:54 PM

The strategy link in Educational Materials provides some useful information. Here are some things I got out of it...

Preparation

A basic way to decrease overall time is to type up all the sample input and I/O code beforehand. One person can do this while the others analyze the problem set. Note that preparing the I/O code can be difficult if the team is using multiple programming languages. Nevertheless, this gives the other team members free time to think.

Combining strengths

This is not as much about combining strengths as it is about making up for weaknesses. Since all teams will practice, they will have in common all the strengths required to succeed. However, the difference between one team and another is how they make up for their weaknesses. Things to consider: specialized roles vs. multipurpose, early vs. late contest...

For example, I write code fairly slowly, and I don't know very many algorithms very well (come to think of it, I am quite useless) but I can read quickly. My place on a team could be to analyze the problem set and type out the test cases.

Starting early

Theoretically, the problem set is made to be completely solvable within the time limit, so the total coding time required should be well under the contest time limit, probably 3-4 hours. However, the total solving time may be something like 6-8 hours, well over the time limit. Since concurrent coding is not allowed, start coding the problems as early as possible. Every little stub function and utility method helps. This gets more of the coding out of the way earlier, and allows for more solving time later.

Some remarks

About the scoreboard... resist the temptation to look at it! First, note that a top-notch team has no need to use it to figure out which problems are easy to solve - if it has been solved by another team, it has been solved by us. On the other hand, if a team is low on the scoreboard, it will only demoralize them. If it influences the decisions of a team, it can waste time, because it can wreck the train of thought.

Any information that can be gained from the scoreboard can be gained from the problem set more efficiently.

Using one programming language within a team would make it easier to write preparation code. (Not that using multiple languages has stopped teams from getting to World Finals.)

IMPORTANT: practice writing actual, compilable code on paper.