How to !win a Hackthon

Caleb Gucciardi
2 min readFeb 9, 2023

--

Photo by Alex Kotliarskyi on Unsplash

I competed in the ICHACK2023 organized by Imperial College London.
My team didn’t win and I’m gonna explain to you why, but first of all, why should you bother participating in hackathons?

  1. Hackathons are usually sponsored by companies looking for talent; it is a great place to do networking and maybe find your next job.
  2. You can win all kinds of prizes, who doesn’t like prizes???
  3. It’s fun, you can work with the technologies you like, learn new things, get experience and drink lots of coffee.

Now, instead of giving you tips on how to win, I’ll do the exact opposite: here is what my team and I did in 24 hours.

⇒ Pick random people for your team

Don’t take people that you know for a hackthon, it has to be a bet.
Don’t consider your individual goals for the competition, in fact, the more your opinions diverge the more chances you have to succeed.

Someone wants to win someone wants to meet new people, someone wants to do technical challenges and someone wants to create a nice product, that's the recipe for a great team, in one word? chaos.

Another important thing is to not prepare yourself, you shouldn’t create boilerplate code and most important you must not align with the team on which technologies y’all are comfortable with.

⇒ Rush the idea phase

Please, I’m begging you, don’t overthink the idea, everyone knows that the idea in a hackathon it’s not important. You only have 24 hours in most cases, you can’t spend more than 20 minutes thinking of an idea… you could end up winning.

You are going to compete with other teams if your ideas are too similar they will not shine, and that's what you want.

⇒ Choose your tools carefully

When it comes to choosing the tech stack you should take into consideration two fundamental aspects:

  1. You need to choose something you’ve never worked with before, this way you are going to spend much of your time reading documentation and debugging
  2. Use tools that make you invent the wheel again, that are really difficult to debug or that have a lot of constraints

Conclusions

I’m sorry if this post sounds so strange, but these are such simple things that I never imagined I would get wrong, and yet, with the pressure of competition and bad organisation, we fell at every point.

I learnt a lot from my mistakes and I hope you now have a better perspective on what not to do during hackathons. Despite the poor performance, I had fun and am already preparing for the next one, hopefully the title for the next post will be different :)

--

--