← Back to index

Programming competitions

March 6, 2016 · 3 min

Today I went to my first programming competition (it was actually my second, but Google HashCode doesn't count as I missed the first two and a half hours of it). It was a fun experience, even though it didn't go as well as I would have hoped. Here are some of my thoughts from today:

Sphere

All code was submitted through a web platform called Sphere. This was -- as is unfortunately pretty common with new, "cool" web platforms written by consulting firms that don't really know what they're doing -- a very bad platform.

You submit you code in a little editor window that (quite impressively actually) supports closer to 100 programming languages. The code then gets compiled on the server and executed against a bunch of different test cases. As a submitter you then get a message saying either that your submission was accepted, that running it resulted in a runtime error, that it gave the wrong answer on some test or that the execution "timed out". This last one turned out to be the mother of all evils.

You see, it wasn't enough to just solve a problem. You had to have an efficient solution as well. I'm totally cool with this. I even like it, as it encourages you to write optimized algorithms to solve your problems. No, the problem was not with the time limit, but rather with how the timeouts were managed.

First of all, you didn't know how fast your code had to be, and since it is pretty gruesome to write your own test input to test all edge cases (for example 10000 nodes in a graph with 1000000 edges) it was really hard to debug your code when you got a timeout. What we ended up doing was essentially writing a decent solution, testing to submit it, be met with a message saying that the execution timed out, tweaking a couple of things in the code, resubmitting, be met with the same message, and repeating the same process all over until we just gave up.

As you can probably imagine this was not a nice experience.

A better approach to this would have been to supply us with a number of inputs to the program, and make us submit just the outputs instead of the entire program. This would make it a lot easier to debug your program to find bottlenecks, and you wouldn't be left wondering if your solution was too complex or if the servers Java runtime was just really slow. It would also make the lives of the developers of Sphere a lot easier, since they would then only need to compare the submitted answer to a pre-defined correct answer, instead of having to dynamically compile and run all submitted code. This is how Advent of Code does it, and it works really well.

Time pressure

Writing code under time pressure is hard. It is easy to fall into a mode where you think that you are really close to the solution, and just bang out tricks and hacks to get done. This is often where your solution falls apart. You could have been rigorously methodical up to this point, being almost 100 % sure confident that all your lines of code do exactly what they are supposed to do, but when you start grasping for straws like this things tend to quickly go south.

What you need to to when this happens (because it will happen, trust me), is to take a step back, allow yourself to calm down, and attack the problem with news eyes from a different angle. Most of the times this is surprisingly efficient, and you will start to see errors in your code that you stared blindly into just moments before.

Doing this is hard though. Especially when you are coding under time pressure.

Java

Java is a great languange. I love Java! But when it comes to programming competitions it feels like it just doesn't cut it. Maybe it is the static typing that does it, I don't know. All I know is that I'm probably better off learning Python for my next competition.


That's all about today's adventures! On another note, fnatic just defeated Luminosity Gaming to become the masters of Intel Extreme Masters Season 10. Go Sweden!

/Mats