How to maximize your chances at winning a software hackathon

And why you should try

7 min readAug 16, 2021

A picture of a desk with a laptop on it, with someone’s foot propped up on the desk

In my second year in college, I was throwing myself at any Software Hackathon I thought was appealing.

At the end of this journey, I ended up with awards in all three of the hackathons I’d participated in, two of which were somewhat high profile.

One had more than 80 teams come up with prototypes, and the other had more than 1200 people participate.

It was hard and stressful work, and I lost multiple nights of sleep before the deadlines of these Hackathons.

Then why participate in Hackathons?

I found it fun. As an engineering undergrad, it’s often hard to get any meaningful work experience, and also pretty hard to motivate yourself to learn whole tech stacks by yourself.

Hackathons solve a lot of issues in one stroke. It gives you a very strict deadline in which you:

Absolutely have to learn to work with a tech stack
Adapt to performing within a team(which can also be fun if you participate with the right people)
And get meaningful awards(cash, internships, etc.) and recognition(stuff to put on your resume and/or LinkedIn profile).

Hackathons are also a really interesting experience to have for entrepreneurs and people who want to get experience working in a team for software development.

For a lot of undergrads, all of these are good things.

Ok, so how do I win?

Sorry, but the title was clickbait. There is no way to guarantee that you’ll win.

There are a lot of variables that go into a Hackathon, so the best you can do is improve your chances.

To start with, arguably the most important thing that needs to be discussed:

A picture of a mannequin sitting on a sofa, with 4 other mannequins behind her. The first mannequin is holding the head of mickey mouse.

1. The team:

What you can’t change before a Hackathon are your skills.

Hackathons are usually very strictly timed events. Expecting to learn a new tech stack or a language is planning to fail, though it can be done successfully.

Ideally, what you can’t do by yourself, you recruit other people for.

Let’s take an example of a website project. If you’re good at writing Backend APIs, then get a guy for the Frontend. A guy for the database. Another guy for Machine Learning or Blockchain or whatever is needed.

The point is, do not recruit people randomly. This can and will ruin your experience. It may be rude to say so, but your close friends may not be the best people to recruit if you want to win.

Look for people who:

Have good communication skills
Are willing to put in the same amount of effort and time as you
Have varied tech skills(and/or non-tech skills too)

Having people with different skills helps you brainstorm ideas to a great degree.

Your team could be made to win off of one guy who’s great at Computer Vision and another guy who managed to think of a good idea using CV.

2. Brainstorming: The USP

For most hackathons, there are usually a few themes given around which you need to think of an idea.

While your experience will vary greatly based on the hackathon rules and your teammates, you should undoubtedly have multiple brainstorming sessions.

Simple meetings, only discuss possible ideas. Do not linger on anything unless you think it could be your favorite child.

The ideas you’re looking for must have one and only one USP: “Unique Selling Point”.

Having multiple USPs is bad.

Having a USP you can’t explain at all to a non-technical person? Also potentially bad.

What is your selling point? Is it unique?

A good way to come up with ideas is to think of problems you yourself face that you want to solve.

One of my hackathon projects involved map data of restrooms that anyone could provide data for, and an option to lease out your own restrooms targeted for enterprises or others with spare restrooms.

I knew this had a real-world application; I myself had trouble finding sanitary restrooms in my college campus(Ahem, this is a joke. Maybe.)

I’d say keep having meetings until you come up with an idea that is possible to code and interesting enough to win(in your opinion). Sometimes you’re really starved for ideas and it takes a while.

Maybe do some research in between sessions and talk to non-technical or uninvolved people for fresh perspectives.

And remember, you can always try putting a new spin on pre-existing software/tech. All art is imitation after all.

3. Time to code: MVP

No, not “Most Valuable Player”. MVP stands for “Minimum Viable Product”.

What this means is, you’re not supposed to code the entire ideal version of your idea. Try to code only the MVP, or what the minimum to show off a demo of your selling point is.

Before you start working on your prototype, figure out what this minimum is. Delegate tasks so that no one is doing something that’s not important; even if someone is done with the prototype work, there’s always presentation work, and that can never start too early.

An example of this would be something like a text chat feature. Unless your USP is in the text chat, there is no point in implementing it. The judges will not directly give you points just because you implemented a feature.

What matters more than anything is how well your demo and presentation show off your selling point.

4. The presentation

This is what I’d consider contributes to 60% of the result. A mediocre prototype won’t make you lose, but a mediocre presentation definitely will.

Try to keep multiple days aside just to work on your presentation.

If it’s recorded, then take multiple takes and try editing it.

If it’s a live presentation, script it, rehearse it. Come up with questions they might ask you.

What helps with these things is statistics: if your idea helps you find restrooms, then show them a statistic that says people need restrooms. If your idea is about preventing road accidents somehow, then show them a statistic of relevant road accidents.

You should also present your idea to family members and friends. See what questions they have. Find out if they fully understand your presentation and what parts seem confusing.

5. Expect the worst: Murphy’s law

“Anything that can go wrong will go wrong”

If you’re using a new library or framework or language, expect things to not work. And expect to find out about this issue at the very last moment.

Plan for this. Try to plan so you start and finish early, keep schedules loose so people can shift to help out with some unexpected issue, and keep alternative implementation approaches in mind.

And even after doing all this, it might not be enough. But it helps. To put it in a lighter note, keep asking yourself this:

What can I do to maximize the chances of my team winning?

Your approach will have to adapt to the contest’s rules; You’ll have to think about exactly what the judges are looking for. It takes a bit of work, but it always helps to remind yourself of why you want to win. Could be the award, could be your competitive spirit.

Could also be that you’ve seen your team work so hard, that you don’t want to think about the possibility of losing.