How to Win a Hackathon
I’m an avid east coast hackathon attendee and an organizer for Yale’s hackathon YHack. Here’s my guidebook for winning at a hackathon.
What Judges Look For
These are the criteria I personally use to judge whether or not my ideas are viable:
- Practicality — How useful is it really? Think about who the user is and why someone would use it. Usually ideas related to current events prove the most useful. (Ex. Fake news, Gun violence, Lead in Flint, Michigan, etc)
- Technical Difficulty — Does it sound hard to make? Is there something you’re doing that I didn’t think was possible in a weekend? (Ex. Wifi Linux Kernel modifications, interesting hardware integrations)
- Originality — Please don’t make another “Tindr, but for ____”, a barcode scanner for nutritional information, or a collaborative music playlist.
Essentially, solve a current real-world problem.
Before the Event
- Come up with an interesting idea that fits the above criteria. The idea itself is almost more important than the execution.
- Create a plan to create the idea and demo it. This usually means the technical framework you think is needed to support your application.
- Find teammates with the skills you need and sell them on your idea.
- (Optional) Look up possible APIs for bonus prizes. Note that this isn’t necessary and you should keep your eye on the grand prize or the category you’re shooting for. You can also look up useful libraries/publically available hackathon starter kits.
- Create a progress timeline. It doesn’t need to be fully flushed out as it will probably change anyway, but it gives a good structure for check-ins through the evening.
Failing to plan is planning to fail.
36 Hour Grind
Have fun, enjoy the food and follow through on your planning. If you did your preparation work well, then it should be fairly straightforward to implement your idea.
Usually, things will fall slightly behind schedule. That’s okay. Just remember that things need to be demoable by the time you present. Not everything needs to be implemented, but priority should be given to those features that any judges will see. (Usually this means no time for fine tuning neural nets)
Your Presentation
Try to split up the work and have everyone speak as it shows collaboration and teamwork. I personally like this structure to frame the project:
- Attention Grabber — Catch their attention and wake them up. Find something relatable if possible. “Have you seen fake news ads recently saying ‘Hillary Hates Kittens!’ ?“
- Problem — Briefly explain the real-world problem you’re solving. If it’s important enough, the judge should already know about it, otherwise if it’s not very well known, have an emotional tie-in. Everyone loves a good story.
- One-liner — “We made Uber for laundry”. A simple high level overview of your approach to the problem and how you’re planning to solve it. Speak in the judges’ language, don’t make it overly technical.
— At this point, you should be at most a minute in to the presentation. (20%-) - Technical Detail — What did you use to make it happen? It should be about 20 seconds per component. Show that you did a lot of work to make it happen and it wasn’t easy. Give them a taste of what you did, but leave it open for details. Be very aware of your audience, if it’s a sponsor judge, namedrop [Sponsor] APIs you used, but otherwise, focus on higher level.
- Demo — One of the most important parts. By this point you should have sold them on your idea and your approach to it. Now, you just need to show what you did works. Go through the demo once with your own test data. Then, let the judges input their own data and see that it also works. The second part is vital to convince judges you’re not just hard coding results. People for some reason are always convinced if something works twice that it’ll work any amount of times.
— 3 minute timing checkpoint (~85%) - Questions — Judges are not very creative. Usually it’ll be something like “What’s the hardest part about what you made?”, or “How do you envision this will be used?”. You can prepare for those ahead of time. This part usually doesn’t matter as much as they’ve already formed an opinion by now.
Great! You did it. Now, sit back, relax (sleep), and wait to collect your prize at the awards ceremony.
Epilogue: Success at a hackathon isn’t about the prizes
Most hackathon prizes at large hackathons will be around $300 USD. If you work at minimum wage of ~$10/hr, you will earn $360 USD over the same 36 hours. If you eventually work in the tech industry, that’s about the amount you’ll earn in one day of work if not less. Hackathons simply aren’t worth it for the money.
Instead, I urge you to focus on these:
- Learning — It’s a good opportunity to learn a new language or a new framework. I never have time dedicated to learning something on a whim, and a hackathon is the perfect opportunity to invest in your personal learning.
- Friends — If you can work with each other while cranky and deprived of sleep, you can make a friendship last. There are also many conversations that happen at 5am, but don’t usually happen at other times. It’s a great chance to get to know your friends beyond the technical skills they have.
- Fun — Enjoy yourself! There’s tons of fun activities from laser tag to dance-offs. It’s a weekend after all.
As cool as a drone or that Alexa could be, I’d much rather have a good friend or a new one I could turn to at the end of the hackathon.
Thanks for reading! Feel free to leave a clap, comment below or read some of my other musings.
