Posted: July 31, 2017 by James Pavur
Hackathons are a great deal of fun and also an opportunity to make connections with local tech companies, build a reputation, and grow as a coder. One of the best things about hackathons is the opportunity to win awesome prizes. Unfortunately the competition at hackathons can be tough. Indeed, sometimes hundreds of people will compete for a shot at only 3 or 4 prizes. It can be hard for a new hacker to stand out from the crowd.
This post shares some of the strategies I’ve picked up after a few years of intercollegiate hackathoning that have been personally effective. If you’re just getting started on hackathons, or want to turn more of your near-wins to victories, these 15 tips are definitely worth considering.
First, it’s important to recognize that hackathons are about way more than winning and losing. The best hackathons are ones where you make new friends, snag a new internship, learn something new, build something awesome, or even just eat a ton of free food. Never let the competition get in the way of these nobler goals - not only because it’ll make you miserable when you lose anyway (hackathons are far more luck-based than we like to pretend) - but because being hyper-competitive can also distract you from doing the things you need to do to have a winning hackathon.
In order to win a hackathon you need to know what “winning” means for you. Some hackathons will have standard prizes (1st place, 2nd place, etc.) - if so, knowing what prize you’re shooting for should be easy. Other hackathons will have sponsor prizes or prizes with specific requirements (e.g. ‘Best Virtual Reality Experience’, ‘Best use of the Twitter API’ ). If you want to win one of these prizes, you’ll need to come up with a project that meets the criteria.
One great strategy for hackathons with sponsor prizes is not to put all your eggs in one basket - try and find synergies and connections between different sponsor prizes and then build a project that meets the criteria for multiple. For example, a virtual reality browser that lets you explore Twitter feeds might be eligible both for ‘Best VR Experience’ and ‘Best use of the Twitter API.’ So long as you don’t spread yourself too thin, the more contests you’re eligible for the more likely you are to win one.
Before you get to carried away targeting prizes, remember to pick a project you and your team are passionate about. Sure, shoelace.io might have a great prize for the best smart-shoe-fastener but if you hate shoes - or know nothing about them - you might be better off picking a project that plays to your strengths. Hackathons are a great opportunity to try out an idea you’ve had but never got around to building, or to pick up a new skill that interests you. Don’t waste your time being miserable just because you think there might be a prize at the end of it. 9 times out of 10 you’re going to lose to the one person who came to that hackathon actually passionate about that subject anyway.
Working in a team at hackathons is almost always better than working alone. See the links at the bottom of this post for a whole article on how to best leverage your hackathon team. In general though, you want to team up with folks who each have unique talents that align well with your project idea. A team of only web-designers wouldn’t do very well at a hackathon since they’d need someone good at backend/server programming to build anything cool. Similarly, having a web-designer on your team when you’re working on building a robot isn’t super-useful because the robot won’t have any web interface at all. Giving people something they want to work on and can contribute towards is critical to maintaining morale and building a winning project.
Just because you’re not at a hackathon doesn’t mean you can’t be working on winning. Whenever an idea strikes you about a potential competition entry - even if you don’t know exactly how you’d do it - write down a little note for yourself. There’s nothing worse than showing up at a hackathon and knowing you had a brilliant idea a few weeks ago but no longer being able to remember it.
Hackathon judges tend to like projects that leverage popular new technologies (for example, Oculus took hackathons by storm a few years ago). Your FORTRAN cross-compiler for ARM may be the most impressive piece of code you’ve ever imagined but it’ll likely lose out to the hipper and flashier projects around it. The flip side of this is that you don’t want to get so much on the hype-train that you end up indistinguishable or directly compared with other teams. Being 1 out of 20 VR games at a hackathon will make standing out much harder.
At one hackathon I met a brilliant coder who was building a physics engine for VR flight simulators from scratch in a combination of C and lisp. Without a doubt he was one of the most technically competent coders at the hackathon but he didn’t have a shot of winning anything. By the end of the hackathon he had, perhaps, a respectable 1/10th of a functioning physics engine and no demo. Hackers are ambitious and hackathons play into this mindset - encouraging the dream of innovation and building something completely new. In reality, it’s far better to improve upon an time-tested idea or build something simple but unique that can expand down the line.
Come to a hackathon with a reasonable sense of what you can build - then shoot for about half of that. A completed simple project is far better than a broken manifestation of genius.
This tip has two meanings. The first is that mentors are great hackathon resources - they tend to be professional developers who are super-familiar with their company’s apis and tech capabilities. They can help you solve bugs, explain odd quirks in a technology you’re messing with, and even suggest useful features that would make a good project foundation. If you ever hit a roadblock, don’t hesitate to turn to a mentor and get some help.
The second meaning is that you should make use of your mentors as a tool for winning. One of the hardest parts of winning a hackathon is making a project that stands out from all of the others entered for the prizes. Mentors, especially when it comes to sponsor-specific prizes, tend to also be the judges who will decide if your project is or isn’t a winner. Talking to your mentors, learning about their experience and their company, and telling them about your project as it moves along will help make the project memorable. Plus every roadblock you overcome that weekend will seem far more impressive if you dragged a mentor down into the trenches with you while fighting it.
Most hackathons, I stay awake the full 48 hours from registration through awards. This is because I generally need little sleep to feel healthy. Some of my teammates on the other hand become little more than zombies after less than 8 hours rest each night. It’s important to assess how much sleep you personally need to work at your max and show of what you know. You should also be sure to eat meals, limit energy drink consumption to reasonable excess, and brush your teeth several times over the course of the weekend. If showers are available, try and make use of them, or at least change into a fresh set of clothing each day. When the judges come around to your demo and check out your project it’s far better to look awake, friendly, and clean than disheveled and distraught.
Set a hard cutoff for when you will stop adding features on your project. I try and shoot for at least 6 hours before the end of a 36 hour competition. At this point, your strategy should pivot from building something amazing to taking whatever (generally non-amazing) thing you have and sprucing it up into a functional demo. This could mean disabling ambitious features that don’t quite work, spending a few hours touching up the design and adding error handling, recording a demo video, rehearsing your “elevator pitch,” or getting your project on github and devpost in a way that looks respectable.
Expect your demonstration to fail - any feature that can break will break in front of your judges. Rigorously test and rehearse everything you are going to demonstrate and try to avoid wandering from the script and showing off functionality that you aren’t 100% confident about. There’s no shame in telling a judge that x feature isn’t quite done yet, but showing off a feature and having your whole program crash or enter some unhandled state can be a dealbreaker. I recommend having a video or slide-deck handy just in case your application fails and being prepared to switch to it rapidly. This is especially important in presentation-style demos where your team is given some amount of time to present their work to the panel.
Hackathons are just as much about how you sell as what you sell. Even the most incredible idea can be wrapped under so many layers of jargon and poor demeanor that it ends up losing its rightful award. You need to be excited (or at least act excited) about whatever you made - even if you don’t think it has a shot of winning. Talk to the sponsors and judges, show it off to as many people as you can, try to encourage folks to tell their friends about it. Demos, like job interviews, are no time for modesty. Decide that whatever hot garbage your team threw together over the past 36 hours is the next Uber/Facebook/Google and then convince everyone else that this is the case.
Also, don’t forget about your project’s online presence. Hackathons will often require you to post submissions on a site like devpost or github. Be sure to take your time and make these submissions look good. Include pictures, documentation, links to a live demo if you’re feeling brave, etc. Judges will often flip through the devpost site at the end to try and remember all of the hacks and pick the best one. The time you spend making a detailed and useful post can be a critical tiebreaker at decision time.
When you’re selling your hackathon project on demo-day you should always keep in mind why sponsors fund hackathons and what they are looking for. Generally, sponsors are there because they want to find new uses for their technologies, get a social media post that shows they support their local tech community, or recruit interns and hires for the future. Be sure to make your project something they could turn around and sell to their bosses to justify the money spent on a hackathon. Think about what’s in it for them when they pick you as a winner and be sure to angle your pitch around that idea.
It’s tempting to run off to a corner, bury yourself behind your computer, and emerge 36 hours later with your final product. However, your chances of winning a given contest revolve a lot more around your willingness to socialize and engage than you’d think. Part of winning on demo day is generating buzz about what you’re working on before hand. Make your project one of the “must-see” presentations by talking it up to other hackers, mentors, and anyone else you run into. Plus, this way you get to meet cool new people and grow a network for yourself as well.
Try not to think of hackathons as isolated events. You’ll tend to run in to many of the same people and sponsors at hackathons. Judges may look at your MLH/Devpost/Github accounts and see what you’ve done in the past. Do your best to keep a positive image of yourself, both online and in person. Go out of your way to include new hackers on your team, speak to mentors/sponsors you recognize and learn their names, and make friends with other hackers from your area. If folks like you and know who you are, they are way more likely to give you the benefit of the doubt when something doesn’t work perfectly.
If you have a success at a hackathon and win a prize immediately share credit - both with your team members and with other hackers and mentors. People love to feel important and be recognized for their contributions. Even something as simple as “We’d never have finished our project without that API tip you gave us - thanks!” goes a long way towards building relationships and making folks glad that you won instead of resentful or hyper-competitive.
Likewise, if you mess up and a project goes poorly or code doesn’t work - don’t lash out and blame your team members or others. Trash-talking your team makes you look bad and hurts your reputation down the line. Trash-talking a sponsor (e.g. “God, Amazon’s AI python library sucks…”) hurts your chances of getting a prize from them in the future. Be polite and respectful, congratulate the winners, and always thank your mentors.
Even with these 15 tips, you won’t always win hackathons. Indeed, almost everyone loses more hackathons than they win - the nature of the game is just too competitive. If you take hackathons as an opportunity to grow, do your best to win, and always try to be the kindest, most likeable hacker in the room - you’ll find that even those hackathons you lose end up feeling like wins. Hackathons are about far more than just the ideas you have and your ability to code. If you recognize and learn from your mistakes across all parts of the game you’ll end up with a killer hackathon team, great experiences, and great opportunities.
One piece of advice I give to people looking to transition from computer science homework assignments to meaningful proficiency in cybersecurity is to seek out Hackathons and Capture-the-Flag competitions.
Sometimes the amount of information on these events can seem overwhelming and it can be difficult for someone starting out to know which events are worthwhile and how to best make use of opportunities. After attending a number of these competitions myself, I wanted to share some of the advice I wish someone had given me.
This is one of a series of post to help folks enjoy and benefit from tech competitions. If you’re more interested in types of hackathons and ctfs, strategies to win ctfs, team management at tech competitions (coming soon), and turning contests into job offers (coming soon) check out the other posts in the series. The series is oriented towards students and early-career tech professionals but offers advice that might be useful to anyone interested in the hacking scene.