Our contests have become famous for the challenges, the problems that our participants solve by coding a solution. We seem to have the right touch to identify interesting challenges and to present them in a motivating way.
The typical response from a participant sounds like:
“Wow, that was an interesting example. It looked so difficult at the beginning, but I managed to finish more levels than I had expected.”
Where do we get the inspiration for our challenges from?
Some of our team members regularly browse through riddle magazines. So one source of inspiration are those riddles. Actually, the very first example in 2007 was to correct a false equation by moving one match.
Another source of inspiration are our projects with our clients. One project was to develop software for grainfield harvesters. The task was to find the path and to determine which cells of the field were mowed in which order, from serpentines with regular harvesters to circular patterns with split harvesters (with two harvesting units).
In circles with 2 units (blue + green):
How to to fit those examples into a 4 hours contest?
Naturally, all challenges have a different level of inherent complexity. To adapt them for our contests, we break them down into levels of increasing difficulty: almost everybody should be able to finish the first level; many should be able to finish the second, fewer the third level, etc. The following diagram visualizes the percentage of participants who finished which level.
The light blue curve depicts a challenge that was quite tough (nobody finished level 5) while the red curve shows a challenge where much more people were able to solve the levels 4, 5, and 6.
When preparing a challenge, we usually have internal test runs to check how well a new example fits into that set of curves. If it’s too difficult, we split levels apart or add some hints. If it’s too easy, we collapse levels, increase the data set, etc.
Typically, we try to make level 5, 6, and 7 quite selective, such that even the best coders have a hard time solving them.
How to tell whether a solution is correct?
For many examples, it is easy to tell whether a solution is correct, e.g. for the “move one match” challenge from above:
|Wrong Equation||Corrected Equation|
|3 = 2||2 = 2 or 3 = 3|
|93 + 27 – 30 + 16 = 68||53 + 27 – 30 + 18 = 68|
For other examples it may be much harder, e.g. with “Autonomous Cars” from 2014 where the task was to “drive a distance of 10 kilometers; avoid speeding tickets; avoid tickets for reckless driving; finish the test drive in under 690 seconds; keep the total energy usage below 6100 Wh”. For such examples we typically develop a simulator with a programmatic and a visual interface. The solutions of the participants then have to interface with the simulator which verifies the driving commands and gives feedback (see the blog article).
How long are the solutions (in lines of code)?
The honest answer is: “It depends.” Here is one concrete example:
|Level||Lines of Code (Java)|
|Level 1||53 lines|
|Level 2||59 lines|
|Level 3||77 lines|
|Level 4||80 lines|
|Level 5||99 lines|
|Level 6||112 lines|
Since we allow any programming language, those lines may differ a lot. Some problems are easier to solve in some languages. However, over the years we’ve seen that most often the best coders choose common programming languages like Java, Python, C++ or C# (e.g. see Infographic). Those are all imperative languages with similar language constructs, so the length of the solution depends more on the creativity of the coder than on the programming language.