Getting ready for the Canadian Computing Competition

The Canadian Computing Competition is coming up in just a couple of weeks — February 26^th, to be exact. Whether you just started programming last month or you are a coding prodigy, you should seriously consider writing the CCC if you are eligible (full-time Canadian high school student).

There are a few good reasons to write the CCC:

1. See how you rank among your peers across the country.
2. Get practice for local competitions — You may find that universities in your area run local competitions for recruiting prospective students. The CCC will give you some experience competing.
3. From what I’ve heard, the University of Waterloo likes applicants who have written their contests. This is especially important if you are applying for CS or Software Engineering, as they specifically ask about it on the AIF. Other universities will like it too, even if it is marginally relevant to your program.
4. Rumor has it, that a big company south-of-the-border is spamming contacting students with employment opportunities based on their CCC scores.

Here is what to expect:

1. There are two tests, one is Junior and the other Senior. The difficulty of the tests is fairly consistent from year to year, so you can look over past tests to decide which test to write.
2. Each test has five questions. The last few questions are generally harder than the first few.
3. For the first stage, the languages you can use are up to your school to decide — it depends what they are capable of testing.

If you decide to write the Canadian Computing Competition, here are some tips to get the most out of it. I don’t claim to be any sort of expert on the CCC, but there are a few things that either I wish I knew, or things I did know that helped. Keep in mind that, although it is a competition, having fun and learning from the experience is more important than winning. It’s fine to be competitive if that’s what you enjoy, but unless you actually enjoy doing the things I am suggesting, there is no harm in spending your free time at something you enjoy more.

1. Practice helps a lot. Start by taking your time and then move to practice competitions where you take a past contest and go for three hours, and then test your results.
2. The book Programming Challenges is good, and it is not watered-down for High School students. The book is a valuable resource for competitive programming.
3. Learn to break all your good habits. Don’t comment needlessly, and even consider naming your variables alphabetically. Not because it is shorter to type them, but because it is less time you have to think about naming your variables. Of course, if your algorithm is going to have too many variables to remember at one time, you will be shooting yourself in the foot to be naming them after letters. All I am saying is that you should keep in mind that the lifespan of the code is 30 minutes, not years or decades. Some would say that if you can’t quickly think of a name for a variable you don’t understand what it does well enough, but I find that I often waste time when I understand exactly what a variable does trying to find the English word that describes that. If you find yourself in this situation, remember that no one is going to be offended if your code includes int n = 1;
4. Consider learning to work without an IDE. You should at least be able to write a Hello World in your language of choice without an IDE. If your IDE underlines errors before you compile, turn that feature off while you practice. You can enable it for the competition if it makes you feel more comfortable.
5. The debugger and other development tools are generally too costly (in terms of time) to use on a contest, however they might come in handy so you should at least learn the basics.
6. Make sure you are comfortable reading and writing to files from your language of choice. The ability to parse strings and numbers out of files is crucial, as well as output formatting (printf or the equivalent in your language).
7. If you are in the habit of spitting out code and shaping it until it does what you want, get out of it. Ideally you want to be able to write a program with no bugs the first time. Not that you should expect to ever get to that level, but that’s what you should aim for.
8. Use a pen and paper. Visualize the problem before you start coding. Try the sample input on paper and see if you understand exactly why the output is the way it is.
9. Pay a lot of attention to the input specification. The test data will test the limits of your program. Don’t even think about what your program should do if you get data that does not fit the specifications; no one is judging you for your error handling. However, you will have cases with lots of input and you will have to put a lot of thought into solving the problem in an efficient way. If the problem specifications say the input graph will have n < 50,000 nodes, you should expect a graph with 49,999 nodes to show up in the test data.
10. When given a problem I would first make several test cases and try them on paper, then type them in and save them. This way I had some extra test cases, and I have ensured that I have a thorough understanding of the question. You will need extra test cases, the tests they give you usually only cover trivial cases. Even if you don’t follow this method exactly, it will pay off to think before you start typing.
11. Get to know the string and array functions for your language well; they will come in handy.
12. If you are using an object-oriented programming language, don’t bother defining extra classes unless you have a good reason to. Don’t even think about using getters and setters if public properties will do the trick.Tony’s note:
    

    Here Paul is referring to setting up (or rather not) proper classes, structures, constructors, accessors, and all the other object-oriented terminology. Higher level object oriented languages such as Ruby or Python tend to perform incredibly well in programming competitions.

13. I made a class called CCC which contained all the code I wanted to reuse for each question (mainly opening the input and output file streams, with a switch so I could read and write from the console instead). I would suggest doing that in advance, so that you can code it again from memory — not that you should memorize it, but you should know the language well enough that you can re-code it without thinking.
14. Arrays, iteration, and dynamic programming tend to be over-represented (so learn them), data structures, recursion and sorting tend to be underrepresented (but still learn them).
15. Compsci.ca member klopyrev, who did much better on the last CCC than myself, has recommended USACO Training as the best way to practice for the CCC. Another good place for practice is compsci.ca’s own DWITE programming contest — it is a great way to improve your skills, throughout the year.
16. Keep in mind that programming competitions test you on a certain area of programming and thinking skills. The questions are generally trivial to implement, but the challenge is coming up with a good algorithm.

Good luck, and have fun.

More programming competition tips on compsci.ca forums and more practice problems on dwite.org contest website.

Read more