Thoughts on hackathons
2019/03/02
Through the years, I have had the opportunity to take part on hackathons competitions some of them local and others, like the hashcode, online. After the last hashcode, I wanted to write some thoughts and experience that I have learnt through the years.
One of the main things that most people do not give the importance necessary is the language choose. Hackathons are quick challenges that wants to test our ability to solve problems and creating algorithms. They do not want to test how good are you with the language (Ok, I know that you need to be good with a language in order to be fast and solve the problem but that is not the point) but how you solve it. I know how good is C, is my favourite language, but you can not use it to solve a 3 hours hackathons. Java and C++ are ok languages, not that I like them but I acknowledge their relevance and power, but you can not use them neither. When you are on a hackathon you need a quick and easy language to try your ideas, do not waste your time creating a Java package or including libraries in your C++ code.
Choose a language like Python3 (Please use 3 not 2.7), Ruby, or one of the many powerfull choices availables. The language election is one of the things that I hate the most. People choose hobby languages for big projects (see Javascript, Python, Ruby,...) and when it comes to quick competitions they choose the professional languages. One main advantaje of hobby languages is that they show you how good your algorithm is, if it never finish, you may need to change your way of thinking. Unless your algorithm is some kind of backtracking that you should implement on a real language, you should choose a simpler language.
Another main important thing that I allways apply, is the same strategy. Start the competition with the random solution, this has two important benefits. The first one is that it helps you to create a base code where you will add the real solution. The second benefit is that it will help you to understand the challenge. Read the problem statement a couple of times and start creating the random solution, you will learn about the input data as well as the output data in a more practical way.
Once you have choosen the language and you already had coded the random solution, you can start thinking on the solution. At this point, I usually start coding the naive solution, or if we are a team, one starts coding it. I prefer this previous step before the true solution, because it gives you a pretty good skeleton to code the final solution. It can also help you to discover other solutions while you are coding.
To sum up: