Sure, you enjoy participating in hackathons, but maybe getting a win once in a while would be nice, right?

I've participated in my fair share of hackathons and other coding/design contests. Not to brag, but I've also won more than my fair share. Which is good, because you want to learn how to win from someone who's won, right?

A couple of quick résumé highlights:

• XPRIZE Big Ocean Challenge: 1st place (category) out of +1,500 entrants
• NASA International Space Apps Challenge: Honorable Mention (overall) out of +9,000 entrants, 1st place ("virtual" location) out of +1,400 entrants
• South Florida Hackathon: 1st place
• Pebble UI Design Content: 1st place
• Pebble + XDA Developer Challenge: Finalist
• Boston.com Hack Day Challenge: 3rd place
• I've been perma-banned from internal company hackathons 🙁

Alright, let's dive in.

Caveat: Hackathons are great places to learn, have fun, and network. If that's your goal, stop reading and enjoy yourself. The rest of this article is about increasing your odds of winning at the cost of the idealized "hackathon experience".

Hackathon Selection

Choosing the right hackathon is 9/10ths of the work. For me, there are four key qualifiers:

1. It must allow me to use a tech stack I'm already competent in, or that my teammates are experts in
2. It must have a timeline that gels with the requirements and with the amount of work I expect to put in
3. It must provide a prize that will keep me and my team invested for the duration
4. Absolutely no public voting in the judging process

That last point instantly disqualifies many hackathons, but is arguably the most important box to check. Unless you're an influencer or have an insanely large LinkedIn network, you will be bested by someone with an inferior idea. I'm sure you can think of at least one example of a low-quality idea or person being voted as a winner due to their popularity alone.

Team Selection

This bullet trips up a lot of people. If you're here to win, not make friends, then go solo or choose a team of people who have complimentary skillsets and will stay to the end. The biggest problem I've had over the years is finding teammates who won't flake out in the final hours, succumb to burn out, or spend time on non-priorities.

The smaller the group, the better. This is like group projects back in school or college; one or two of you will do the bulk of the work, while the rest sit back and watch you earn them an A+ grade.

Idea Selection

Here comes the easy part: choosing your idea. Yes, I said "easy", that wasn't a typo.

Most hackathons these days have fairly strict guidelines on what they want you to build. (If you've entered a Wild West style free-for-all, awesome!) More and more hackathons are also splitting the options into categories.

If your hackathon does have categories: Pick the least interesting category. If there's a way to find out who is signed up for each category, pick the category with the fewest entrants. For my last hackathon, the XPRIZE Ocean Challenge, I picked the "Shipping & Trade" category. I have zero experience with this, and even less interest, but less competition means a bigger chance of winning.

At this point, you should have a much narrower scope of possible entry ideas. Focus on ideas that best make use of you and your team's expertise, favor mobile over web (everyone loves an app), and choose an iterable idea (more on that later).

If your hackathon does not have categories: Alright, this is a little harder. Still prioritize ideas that cater to your team's skillset, favor mobile, and go iterable, but also go big. If you follow the next point (on iterable ideas), there's no reason not to aim as high as you can. You need to "wow" the judges at this point with not only execution, but also vision.

Fortunately, teams will either shy away from the moonshot ideas, or plan poorly and fail to deliver. If you can overcome those problems, you're good to go.

Feature Selection

This is where you win, because this is where everyone fails.

Once you have an idea, treat it as a bootstrapped startup with a very limited budget. Jot down all your grand ideas for what this idea can be, and then whittle it down to the core feature.

What is this idea's minimum viable product (MVP)?

Discuss it with your team, very clearly define what it is, and write it down where everyone can see it. This is what everyone works towards, no more, no less. Plan on this taking you right up until the deadline.

Then ask yourselves, "If we finish an hour early, which of these other features could we add?". Write that down on a separate piece of paper, and ask that same question again and again until you're satisfied.

A feature set that you can iterate over and use to continuously improve is the key to everything.

Timing

If your MVP is going to be a bit late, fake it 'til you make it. There's no shame in cutting corners with static or fake data; you're presenting an idea, not a product ready to ship.

If you're going to finish right on time, great! You have a good idea that actually works, so you're better than half of the competition.

And if, most likely, you're going to finish your MVP a little early, everyone on the team is now available to start tackling that "nice to have" wishlist of extra features. Finish one at a time, in order, and keep cutting away at the list until the very end.

Cheating

Don't cheat, please. It ruins it for everyone.

That said, other people will cheat, and the judges don't care.

I've been in countless hackathons with strict start/stop times, but reviewing a competitor's GitHub repo shows half of their commits were the week before the hackathon. The judges response? The hackathon is over, the prizes have already been awarded, it's not worth the hassle.

Even if the commit timestamps are within the window, the competition is still not guaranteed to have abided by the rules. Did you know that you can alter commit timestamps in git, and GitHub will show the altered timestamps with no indication?

Always be aware that this is most likely going on, and work accordingly.

It's also important to make a distinction between cheating and faking. As I mentioned earlier, hackathons are about the presentation of ideas more than writing a ready-to-ship product. (If your hackathon is indeed about shipping a polished product, you chose a bad hackathon.)

I've absolutely worked on ideas that were impossible to finish in the allotted time. For one hackathon, I spent at least 25% of the time working on faking data and functionality well enough to get it approved in the Apple App Store.

Conclusion

If all this sounds cold and calculated, that's because it's intended to be. This is about winning and nothing else. Sometimes, though, winning and sharing that joy with your teammates is as fun as participating in a hackathon to "just have fun".

I hope that something in this article is useful to you, and helps you bring home that big check, trophy, battle axe or whatever it is they're giving away as the top prize.