There are three big things that both hackathon participants, regardless of their
skill level, need to know to win:
Who is your audience?
What should I focus on?
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.
One of them makes a fantastic note-taking app targeted at students.
The other makes an app that uses machine learning to tell whether your boss is
angry at you in an email or not.
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:
Make a website. Apps take way too long to develop so unless you're already a
professional app developer it's not worth it. It's also a lot easier to make a
website look good than an app.
Due to the simplicity and lack of need for setup, I would recommend the tech
stack of NextJS and TailwindCSS
DO NOT MAKE A CLI TOOL. I highly recommend avoiding Java / Python (unless
you want to use it as a backend), because even if your idea is spectacular,
judges will think it looks boring.
Really make sure you NEED a database before adding one to your project.
A majority of the time you don't actually need a real database, something
like localStorage should be good enough for the majority of people.
If you really NEED a database (your demo involves more than one computer
being in sync), then stick to a noSQL db like MongoDB.
Invest some time into making the product look good. It's often worth looking
at how professionals have done something similar and borrow the style (for a
solid example of this, compare my
OpenSearch to
Google).
Lie. Cheat. Deceive. And don't get caught.
I'm not going to call out any team specifically... but when I ran
GeomHacks, one of the teams created a project that
was particularly impressive. The basic premise was that they trained a model
to take the journal of a person who may be experiencing depression and be
able to tell whether or not they were """just""" depressed, or if they were
feeling suicidal. I believe they were going to win second place, but then
one of the teams looked at their source code and discovered it was, in
reality, just randomly picking between the two. They hard-coded the specific
case they were doing in the demo video. That's actually a really clever way
of cheating, but next time make sure to not publish that part of the code to
github 😉.
Make your demo interactive to the judges if at all possible.
When Oleks and I won first place at
BranhamHacks, we essentially made a kahoot / gimkit clone. It was later
revealed that our project wasn't originally going to get first place, it was
actually supposed to score much lower. Due to our demo allowing judeges to
join the game directly from their phones, it actually changed their minds on
the rankings and gave us an edge over other people.
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:
Go for the solo prize. You will statistically fare a lot better this way. This
is risky however because if other people are going for the prize, they are
very likely to be just as if not more talented then you in building projects.
In all other cases:
Go for the maximum team size, it's usually four.
I recommend a team with a skillset as follows
A front-end person. This person will be responsible for making the website
work functionally.
A back-end person. This person will be responsible for the backend if you
weren't listening to what I was saying above about not needing a back-end.
An artist. This person will design the site and make some art for it. This
person will be the most free to attend talks and participate in hackathon
activities.
The all-rounder. This person is here for three reasons:
If someone doesn't show up or has to leave early, this person can take
over the role of the person.
If someone is stuck on something (weird bug in code, can't find a good
design), this person can help un-stuck people.
This person can get everyone food/water (This is mostly a joke)
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.
