I would divide the skills required for programming competitions as follows:
- The ability to think abstractly.
- The ability to employ well-known algorithms and algorithmic techniques.
- Knowledge of previous competitions tasks.
- Flexibility of point of view which allows to find easy implementations.
- General problem solving techniques.
Skill (5) consists of ideas such as "backward reasoning" and "reversing a task" (these are not even specific to exact sciences).
Skill (4) is an art which is gained mostly by experience and also by looking at work done by other contestants.
Skill (3) is obviously a matter of experience.
Skill (2) is attained by thorough preparation including both solving problems and reading algorithms books.
Skill (1) is again an art, but this time it is an art which has much in common with other branches of mathematics.
Let me give you some examples from the latest International Olympiad in Informatics (IOI2011, http://www.ioi2011.or.th/tasks):
Task RICEHUB (relatively easy) requires an insight similar to task POST from IOI2000, which is an example of skill (3).
Task RACE (relatively hard) is mostly a matter of applying a known technique. The easiest way to solve this one is to try known techniques one after the other until you realize which one gives an efficient algorithm. I think it's very hard to solve this if you approach it any other way (I'm not giving details of the solution to avoid ruining it for you. There's a solution on the website). So this is an example of skill (2).
Task PARROT (relatively easy, but conceptually new in IOI) can be used as an example of skill (4). The "mathematical" solution is not too hard, but there are implementation issues. Again, in order not to spoil the question, I would just suggest considering task MAGIC SQUARES from IOI1996 and task TWOFIVE from IOI2001 which involve implementation details similar to the ones in PARROT (MAGIC SQUARES is easier than PARROT and TWOFIVE is harder in respect to those implementation issues).
As for skill (1), task CROCODILE from IOI2011 can serve as an example, but I'd rather give you a cleaner one which also serves as an example for skill (5):
Consider the well known egg-droping problem (see http://www.ocf.berkeley.edu/~wwu/riddles/hard.shtml).
To solve this problem one should first reverse it and ask "what's the highest building I can solve with up to $t$ throws?". To solve the reversed problem, one should employ backward reasoning (reversing and backward reasoning are examples of skill (5) ) and say: Let's try to sketch a solution strategy: The first throw would be from... well.. I don't know where from. So let's denote the floor of the first throw by "t_1" and continue from there. I will not continue describing the solution, but note that "let's denote the floor by a variable and continue" is an example of abstraction. Instead of a number of a formula, we just accept the fact that we don't know what this floor is yet, make up a variable to denote it, and continue.
(you may find tasks from IOI up to IOI2008 in http://ioinformatics.org/history.shtml).
From my experience with students participating in IOI, I would say that the ones who also participate in IMO (or otherwise very oriented toward mathematics and not just computer science) are:
- Always on top in regard to skill (1)
- Tend to be better than others at skill (5)
- Have a potential to become exceptionally good at skill (4) after some hard training
EDIT:
As a final advice: Try solving many tasks. Code any task you solve to make sure you understand all the details. After solving (or trying long enough), always read an official solution or discuss the solution with someone else. In a more advanced stage of your training, read tutorials you can find on the web especially about data structures. You can find some of these on TopCoder's website.
As topics which are traditionally considered as mathematics and not computer science:
- Mathematical games can be relevant to programming competitions.
- In many computational geometry tasks it may be worthwhile to feel comfortable with convex sets as mathematicians think of them (maybe this is a bit advanced).
- General mathematical experience and rigor can help you avoid wrong solutions which intuitively seem correct.
Overall, I'd say that the best way to become better in programming competitions is to train specifically for them while getting general mathematical education.
There are not many "traditional math" topics which can help you directly with those competitions.
(probably the best and most relevant way to get general basic math education is to take "Linear Algebra" in university or to learn the same material elsewhere. Again, this is not directly relevant, but eventually your problem solving skills would benefit from the rigor you will learn at such a course).
Best Answer
I definitely think the Putnam exam tests mathematical "maturity" just as much as talent or raw knowledge. By maturity, I mean the somewhat less tangible things we pick up like gauging a problem's difficulty, anticipating the necessary techniques, knowing how to construct an intelligible argument, and knowing when to move on. Ego can be a huge issue as well - I know it was for me. I missed a lot of points on my second try because I tried to solve too many of the problems and ended up with many incomplete solutions instead of a couple complete ones.
I took the exam twice - once as a sophomore barely out of multivariable calculus, and again as a senior. While I had certainly learned more "math" in those two years, I think the real difference was that I had learned how to make a valid mathematical argument. So my 300-level intro to proof writing and analysis class was much more important than my 400-level differential equations and probability classes. I think the only thing that prevented me from doing extremely well was my ego (and a bit of experience).
As far as practicing/studying/preparing, my department offered a "prep" class which was taught by a former IMO medalist. We worked problems, mostly, but he was able to offer a lot of good strategies and tricks as well. The biggest takeaway message seemed to be that preparing to solve a problem is just as important as actually solving it! I.e. taking time to decompose the problem into its core pieces, look for tricks or "dimension reductions," try to figure out what the question is "really" about (i.e. maybe its not a linear algebra problem, but a counting problem). While you can sometimes make progress by jumping in the deep end, a little big-picture can go a long way. This is in stark contrast to the math GRE!
I also can't recommend enough cross-training in the form of reading about problem solving. Books like "How to Solve It", "Proofs from The Book", and blog posts by Terry Tao, etc. are a great resource. Books in a similar vein from the "other" sciences, like Feynman, can be surprisingly helpful as well - the techniques of discovery.