Background: I’m not entirely a CS educator, but I did run into a debate on whether programming contests are good for students.

A lot of people around me have fun in programming contests. Usually, those contests require participants to “solve” several problems (like 7 to 8) within certain time (2 to 3 hours). Students are ranked by their scores, calculated from the number of problems they are capable of solving, and then the time spent. There are test cases on the submission system to which students have to submit their source files, and the submission “passes” when it compiles to a program which passes all the test cases.

Given all these, while students are (probably?) good at problem solving skills, there are several problems:

1. Students focus too much on the time spent on writing their programs. Therefore, they employ a lot of poor practices. For example, they always use short variable names, universal headers (#include <bits/stdc++.h>), using namespace std; etc in order to speed up their typing. They claim that iostream is implemented on top of C’s stdio and so they use printf even in C++.

2. They always put extra assumptions. For example, while they know how to find the “unpaired” integer in an integer array (by taking the XOR sum), they won’t think of how to check whether the array has only one unpaired item. Also, they usually allocate large arrays in advance and skip bounds checking (they believe the array is large enough), which create concerns in both program stability and security.

3. They don’t understand how to maintain a large project. Since OOP (usually) requires them to type more, they, for example, manipulate raw arrays with a part of custom heapsort algorithm, instead of creating a struct representing a heap, when they are writing in C. While sometimes OOP is unnecessary, for them code reuse is either impossible or require a lot of copy-and-paste.

Background: I’m not entirely a CS educator, but I did run into a debate on whether programming contests are good for students.

A lot of people around me have fun in programming contests. Usually, those contests require participants to “solve” several problems (like 7 to 8) within certain time (2 to 3 hours). Students are ranked by their scores, calculated from the number of problems they are capable of solving, and then the time spent. There are test cases on the submission system to which students have to submit their source files, and the submission “passes” when it compiles to a program which passes all the test cases.

Given all these, while students are (probably?) good at problem solving skills, there are several problems:

1. Students focus too much on the time spent on writing their programs. Therefore, they employ a lot of poor practices. For example, they always use short variable names, universal headers (#include <bits/stdc++.h>), using namespace std; etc in order to speed up their typing. They claim that iostream is implemented on top of C’s stdio and so they use printf even in C++.

2. They always put extra assumptions. For example, while they know how to find the “unpaired” integer in an integer array (by taking the XOR sum), they won’t think of how to check whether the array has only one unpaired item. Also, they usually allocate large arrays in advance and skip bounds checking (they believe the array is large enough), which create concerns in both program stability and security.

3. They don’t understand how to maintain a large project. Since OOP (usually) requires them to type more, they, for example, manipulate raw arrays with a part of custom heapsort algorithm, instead of creating a struct representing a heap, when they are writing in C. While sometimes OOP is unnecessary, for them code reuse is either impossible or requiring a lot of copy-and-paste.