Although the first round was taking place on the day before an exam, myself and two other students from Abertay took part. This round involved answering ten programming questions: 9 based on the C++ language and a final question focussing more on object oriented design.

I wasn’t sure what to expect beforehand (other than a vague notion that reversing a string in place might be involved) but found actually sitting the test to be quite a relief! Although I wasn’t 100% sure all my answers were spot on, there weren’t any concepts which I was unfamiliar with. It certainly increased my confidence (or at least reduced my sheer terror) concerning programming tests I might face when applying for a job.

I was pleasantly surprised to be told that I was one of the eleven programmers who had reached the second round, a more open-ended programming task. For this we were given an uncompleted and incorrect Asteroids like game, and tasked with fixing and improving it within seven days. Working with someone else’s code was an interesting exercise, and I aimed to uphold their programming style and standards as much as possible. I hadn’t touched DirectX or DirectInput in some time, but I didn’t find it hard to get back into; nothing in the codebase was particularly surprising or unfamiliar.

The only downside of the problem was the short timespan, as I also had coursework deadlines and continued work with Digital Colony and on my dissertation to contend with. I successfully submitted a corrected and improved application, however it would have been nice to dedicate more of my time. I’m still waiting on the results of this stage, so I will of course update the blog when I hear back. Since I worked on someone else’s codebase I’m unsure whether posting screenshots of the application is acceptable, however I may also follow up with those at a later date after seeking permission.

Image used under Creative Commons license from Computer Science Geek.

The basic format of the competition was that around seven teams from various universities were each given one computer between the five members. After a basic practice question to check we could correctly read the output and would be able to submit our answers, we were given three hours to solve three further problems. Finally, at the end of the day we were tasked with writing AI for a spaceship to complete an Asteroids-like game, which the competed against the other teams.

For each of the three questions our team managed to agree upon a solution and write out the psuedocode required to implement it. What really took time was actually writing out and testing our solutions. Being so pressed for time really emphasises the amount of overhead involved in writing in C++. Creating functions involves either writing prototypes for them or ensuring they’re all written in order, and finding one again means using Ctrl-F or searching through the file. The obvious way to make things neater would normally be to create multiple files, but that becomes almost unthinkable when you consider the overhead involved in writing headers. Then you come to testing the project – the compile time really adds up. Don’t get me wrong, all the teams were working in the same conditions (we were also given the option of using C# – I’m not sure if this would have improved the situation or not), but at any rate, at the end of the three hours we only had one solution to submit.

The second section of the competition (creating the game AI) went better. Knowing we would be short of time we focused on creating the most simple working solution we could – staying in one position, rating asteroids based on several criteria and shooting the highest rated one. As it turns out, most of the criteria we calculated were almost useless, or even hindered the spaceship – far more important than anything else was shooting the closest asteroid to the player. Our ship did very well in round one, but unfortunately we hadn’t considered what would happen at the end of the level when no asteroids remained, and we crashed out of the competition leaving two ships to continue through the next rounds.

At the end of the day things were looking a little bleak – we had had fun but given all the teams had successfully submitted more solutions than us and we knew ours wasn’t perfect, so we were hugely surprised to find we came in 3rd place, winning Amazon vouchers. Hopefully the competition will take place again next year as we now have a far better understanding of how we’d take part.

Things we learned:

• Don’t enforce time limits for each problem unless things aren’t working – one working solution is better than several non-working solutions.
• A quick solution which works in most cases is better than a perfect lengthy solution which will take a long time to implement.
• Don’t try to solve problems at the computer – just type up pseudocode.
• There are tasks one person can do while the rest of the team is working on the first solution, for example reading in the input into data structures.
• Global data works just fine.
• Working with people you know well is far easier than getting a group together – no matter how brilliant they are.