Garmin Programming Competition 2014
Yesterday at my university, Garmin was hosting the Programming Competition.
Competition like that is a great opportunity to practice programming, algorithms and problem solving skills.
We could form teams of 1-2 students. My partner was Daniel Wang. We could use following languages: C++, C#, Java and Python. We chose Java. We were using Eclipse IDE and git to share the code.
Organizers prepared very real-life problems.
Competitions had two parts:
- Read and perform simple input conversion (1 hour).
- Reuse code from Program 1 and do more complicated operations with input (3 hours).
We solved part 1 without any problems. Part 2 required two programs: 2A and 2B. We solved both, but our programs didn't pass all test cases. In 2A: 3/5 test cases passed, in 2B: 4/5. There were points for correct solution and bonus points (depended on the time when solution was submitted). Additionally, there was a timer showing how many bonus points we could earn sending solution now.
You can find problems description here. Our solutions are available on Bitbucket repository. Be aware that it is bad code, written under time pressure and never refactored. However, efficient enough to pass required time constraints. This is how you write code during programming contests :)
After competition we asked organizers about test input sets and they sent it to us.
This is the description of the bug we had and how we fix it (you can skip this part if you don't want to read the description of problems):
The issue we had, was reading (shift mod 26) straight from the input file. Because e.g. shift = 45 should be effectively shift = 19 (45 mod 26). The program should stop when shift = 0. Then, when original shift was e.g. 52 we had stored shift=0 and we stopped (which was wrong). We thought that we should stop when the 'effective shift' is 0. Unfortunately, the test cases were stopping when the 'original shift' was 0. Fix was pretty easy (we just store two values: shift and shiftOrig for each cell). It would be very hard to fix this without test cases from organizers ;) It was like in real-life: small detail caused significant error.
The challenge during programming competitions is that you cannot get all test cases. This time, there were 1 sample input per program. Which make sense, because otherwise everybody could just hardcode expected solution :) What is worse, you cannot see the program output (in case of runtime error). Fortunately, guys form Garmin were nice and when we asked, they were showing us the output (on their machine). It helped us (a lot) in fixing the runtime errors (during the competition).
The next event I am looking forward is Google Code Jam. It starts in April 11, 2014 (Friday). Registration begins in March 11. I really encourage you to sign up. You can learn what various problems you can face and what you should consider during writing your programs. Additionally you can practice, apply your programming skills and compete with the best programmers in the World.