programming contests at tertiary level: ACM International Collegiate Programming Contest: http://www.sppcontest.org/ New Zealand Programming Contest: http://www.nzpc.otago.ac.nz/ Contestants enter as teams of three. Solve as many problems as possible in five hours.
Our team was: Bradley, Edward, and me. We entered both contests in 1997–1999. Nationally, we got in the top three places for all NZPC contests, and ACM for all but one. So you can win. But it won’t happen willy-nilly. Two types of strategies are essential: Programming strategies Teamwork strategies
programming language. The specific language is unimportant as long as all members are fluent in the one chosen. More important to understand the problems and the methods required to solve them. Thus, it’s important to know a good range of solution methods, and for all team members to become familiar with them.
extreme cases. Contest submissions have performance and size requirements. This method provides a space-time trade-off. Textual parsing using state machines. Excellent flexibility for most parsing work. Many programmers fear this method. My solution: practice, practice, practice!
couldn’t solve, we review the problem at a later date. We usually end up writing code to solve the problem. If it’s really good, we print it to use for future contests. Bringing good, tested code to contests has saved us a lot of time. If nothing else, make a compact yet fast bignum library, if your platform lacks one.
the sum of its parts. Choice of team members is very important. They need to work well together: Understand each other’s approaches Share a common jargon Agree on acceptable practices Have a common vision Choice of team captain is equally important.
make all the essential decisions about the team: When and what to practise What to bring to the contest How long to spend on which problems How members need to perform to stay in Need to be highly respected (both technically and socially) by all team members.
previous problems to become familiar with required solution methods Develop scheduling strategies: how long to spend on which types of problems Resources are essential too: Sort out which books to take to the contest Prepare all required code libraries Decide on transportation arrangements
only five hours, so computing time has to be rationed. The team captain must be prepared to be despotic about enforcing this. Our team has a strict 30-minute policy. If you don’t complete your problem by then, you get off the computer. No exceptions. There isn’t enough time to solve all the problems. Decide which ones to attempt, in which order, and who to try which.
need to have your design drafted to a stage where you can just key it in with little thinking. Usually this means pseudocode is required. In the name of expediency, be prepared to throw all the “structured” coding rules to the wind. Your code is likely to be the ugliest (yet still debuggable) piece of turd in the world.
the computer, you don’t twiddle your thumbs. You either work with the other offline person to draft out the design for the next problem, or help the online person debug their code. It is thus important for every team member to understand everyone else’s designs. No member works on a problem alone, except for extremely trivial ones.
for our team. They may work for you too. Part of our team’s success comes from our attitude: we’re there to win, not just to have fun. We worked hard to achieve this. If the team has an effective captain with clear direction, and its members are competent and work together well, the chances of winning are excellent.
cky
schroneko
kishida
kentaroutakeda
ivargrimstad
bkuhlmann
kangnux
unvalley
yoppie
syumai
satoshi7190
yosuke_furukawa
jaguar_imo
mojombo
keavy
eileencodes
bermonpainter
erikaheidi
hatefulcrawdad
paigeccino
colly
shpigford
thoeni
nonsquared
tammyeverts
