How to Win at Hackathons

There are three big things that both hackathon participants, regardless of their skill level, need to know to win:

  1. Who is your audience?
  2. What should I focus on?
  3. What should my team look like?

We're going to go through each of these points 1 by 1.

but first...

Who am I?

I'm Lino Le Van, I am soon to be leaving high school and heading off to college and I've organized ~three hackathons and participated in countless others.

In these next few headers I'm going to be bringing up anecdotes and examples that may seem strange, though I promise all of these things are something that I've experienced before.

Anyways, I'm not going to waste your time. If you really want to win, you must understand that you're not going to have fun and you're not going to feel good.

If you agree to the terms and conditions, then feel free to read the rest of this article.

Who is your audience?

This is the number one mistake that I see hackathon participants make. I can't tell you how many times someone will make a product that appeals to their-subgroup specifically. Often times, as a student, we makes things like notetaking apps or things to make being in long lectures easier... if these things don't appeal to the judges, you're not going to win.

Let's do a quick case study. In this example there are two teams.

If the judges are students (which is rare but does happen), the first one will most likely win.

If the judges are adults, who have been working for ten - twenty years, they are much more likely to select the second one.

The fact of the matter is that hackathon winners play the game the best, and one of the easiest ways to do that is scope out who is going to be judging your project. Most hackathons publish their judges weeks in advance, so if you want to have the best shot at winning it's worth to do a little bit of linkedin-stalking to find out who these judges are and what they stand for.

Ethically, this advice seems questionable, but I promise you the teams that don't do this don't win.

What should I focus on?

Another question that gets brought up a lot, mostly by beginners, is "What should I focus on to win, the idea or the product?".

The answer you get from hackathon organizers varies significantly. There is one common answer which, in my opinion, is wrong.

Focus on the idea, we're not grading you based on what prototype you are able to build in such a short time.

If you want someone to win a hackathon, this is completely the wrong advice to give. Judges, whether they be students or employees, don't care about the idea as much as how shiny your finished build looks like.

The idea doesn't have to be super in depth... it just has to look good on a screen. This will come up later in the section where I talk about what your team composition should look like, but for now hear me out.

My advice for teams that want to win through their product is as follows:

Anyways, that was a lot of advice. Let's move on to the shortest section of them all...

What should my team look like?

This section is really simple and so I will keep it as short as possible. There's really only two cases.

If there is a solo prize AND you know you can build a whole project by yourself:

In all other cases:

That's it!

This is as far as my experience can take you. All that's left is for you all to take the advice I've given and go out there and practice it.

Personally, do I recommend doing what I say here? No, not really. No one fondly remembers hackathons where they won by deception. I know you won't believe me if you've made it this far, so go out there and have fun!

If anyone wins by following this advice, send me an email. I'd love to hear what you did.

Comments