Practical Track

Practical Track

For the practical round, you are asked to write and submit the source code of a complete program in the programming language of your choice, capable of solving the specified task. For this we have prepared five juicy tasks to keep you occupied:

  1. The ATM
  2. Code Cracker
  3. Underground City
  4. Hockey Tourney
  5. Training Plan

Note: in contrast to the last year, participants are not allowed to submit in teams.

Note: your programs are supposed to read the input from the standard input! If you use a language, for which that is (almost) impossible, read the input from a file

How to submit

You should submit your program directly via the submit-form linked at each of the task-pages. Either submit the sourcefile directly or, if you have multiple files, as a an archive. There is also a field for a documentary file (optional but strongly desired).

If you have problems submitting, you can also send the solutions via email to (please note your full name and login-name in that case).

Please do not send binary-files, but sourcefiles only! We will not look at binary files. The documentation can be in any (readable) format (e.g. pdf, latex, doc, plaintext, etc.).

If possible, try to have just a single source file in order not to complicate things. At the top of the source, include a header specifying which task you solved, which programming language you used and your login-name:

  Task: sample
  Lang: C++
  Users: chuck


A program that correctly solves all our test cases within reasonable time (seconds) will receive the maximum score. Note that these testcases are not public, so you do not know them in advance. For the time constraint we are looking at the asymptotic runtime complexity of your program. This generally means you should optimize your run time from months to seconds, but not from 4s to 3s. Moreover your programs can use memory up to a «reasonable» limit (100MB as a rough value).

  • If your code is fast and correct, you will score the maximum (and no extra points can be gained from the documentation).
  • If your program is correct, but slow, you will be awarded partial points depending on how slow it is (also look at partial scoring on the task sheets).
  • If your program is fast but (partially) incorrect, you will score (almost) no points.


We encourage you to also write an explanation (in words), what the idea is behind your program. If your program has a bug, you will lose a lot of the points caused by the bug, unless you send a correct (and good) documentation. In the latter case we will award partial points depending on the quality of the content of your documentation and source code. Thus you can save some of these lost points.

These rules are intended to avoid an art contest. (You should learn something when explaining your solution in words.)