Over the last decade, the ACM Collegiate Programming Contest has become a truly serious competition. In the 2003 contest, 3,850 teams from 1,329 universities in 68 countries competed in regional contests to select 70 teams for the final round. The winning Warsaw University team solved 9 out of the 10 programming problems in 5 hours, under conditions that allowed only one team member at a time to use the computer and that forbade the use of any pre-packaged electronic source code. Participation is still growing: in 2004, 3,150 teams from 1,411 universities in 75 countries competed to select 73 finalists.
There is more than personal or school pride involved. The United States has been effectively squeezed out of this contest. The number of US teams in the top 10 dropped from 5 in 1995 to none in 2003. Consider this fact in light of recent news stories about out-sourcing of programming jobs and you begin to see the stakes. On the other hand, there is good news: in 2004, 4 US teams placed in the top 10: Penn State (!) was 4th, MIT 5th, CIT 7th, and Harvard 9th. However, we ought to be among them, don't you think?
In the fall, we'll be holding a local programming contest to select competing teams for the next ACM regional contests. But it should be clear from the preceding remarks that anyone who hopes to compete successfully in such a hotly contested match must practice! To this end, this page provides pointers to some useful resourses.
For some years now, the Universidad de Valladolid has run a robot judge that will compile and run programs submitted by e-mail or through an on-line interface, check the output, and mail back the results. Although it claims to handle programs written in C, C++, Pascal, and Java, I have found that Java support is a little flaky at the moment (perhaps this would be a good time to learn C++). Go to their web site for all the information. First, you'll be asked to register, after which you will be able to submit programs. This site contains information about how to write programs for judging and contains links to the problems themselves.
You should be prepared for frustration. The feedback provided to you is similar to what you get in ACM contests: very little. You'll be told, for example, that your program produces wrong answers, or that it segfaults, but you'll get no information about what inputs caused these problems, or what outputs it produced. Likewise, you can expect the judge to be fussy about output format. On the other hand, I suspect that developing the sort of discipline needed to function under these conditions is likely to be useful to you in "real life" as well.