How to Hackathon in 5 Easy Steps
Why aren’t more people talking about Hackathons? They’re a blast and frequently supply free food and fidget spinners. But most importantly, they’re a great way for software developers to improve their skill set in a short amount of time, while offering non-technical professionals an opportunity to execute a vision and bring an idea to life.
If you’re interested in entering one, colleges and tech-related organizations hold them all the time. I am proud to work for a company (Asurion) that sponsors an annual hackathon, which produces dozens of innovative ideas and impressive implementations. During this year’s event, other than managing to surround myself with great teammates, I followed these five steps to optimize my hackathon experience.
1. Pick something topical
Many interesting projects come out of hackathons, but after you’ve been to a few, you’ll start to see some repeats. To maximize novelty, try picking a relatively new technology or theme. Even if you don’t win, you’ll learn more and expand the constraints of your comfort zone.
For example, due to the massive increase in home assistant ownership (129% year over year), our team decided to utilize the Amazon Echo for our hack. Our service, Soluto, provides instant premium support for technology issues. We thought that the Echo could be a convenient entry-point to our service.
Your hackathon idea doesn’t always need to change the world. It can be something simple and fun that’s inspired by an engaging new show, movie or game. I participated in my first hackathon a few years ago when 2048 originally came out. Because one of our sponsors was SendGrid, I decided to hack together an email-powered 2048 game. It was well received, due to its relevance at that time.
2. Define an MVP
Most hackathons last between 24 and 72 hours. Although this might seem like it’s a lot of time to work with, it’s not, even if you bring a sleeping bag. As such, you need to define a minimally viable product (MVP) that’s feasible for your team to create, while leaving you time to spare.
You can accomplish this by limiting your hack to a few core features. If your hack is too broad, each feature will likely appear unpolished. If you have ideas for how to expand your hack in the future, include them in your presentation as talking points. The audience and judges won’t forgive you, however, if you have a great sales pitch but nothing tangible to show for it.
3. Test third-party integrations early
Many hacks utilize application programming interfaces (APIs) to integrate their application with other web-based services. You can have your users log in through their Google account, send out tweets chronicling their in-app activity, and much more. Using APIs expands your target audience, simplifies development work, and enriches your user experience.
Unfortunately, APIs, by design, have their limitations. These third-parties worked very hard for their databases and features, and they’re not going to let you use them unabated. Some APIs require payment, most limit how many calls you can make within a given amount of time, and all restrict access to their data in some way. To avoid any misconceptions, you should test your integration use-case early, perhaps before creating any other functionality.
I learned this the hard way. At a previous hackathon, my team set out to create a Facebook application that identified which friends you haven’t interacted with recently, and gave you the option to reconnect with them. We built the entire application during the first half of the hackathon before starting the API integration. There was only one problem: Facebook prevents you from getting information about your friends unless they also have the app. As the app would be useless until a significant part of the population installed it, we had to completely rework our idea with very limited time.
At the Asurion Hackathon, we benefited from being able to use internal APIs that we’ve worked with in the past. Even still, we worked on the integrations first, just in case anything came up along the way. This allowed us to focus most of our energy on creating and refining the user experience.
4. If it ain’t broke, don’t fix it
If you’ve implemented your MVP with time to spare, you might be tempted to change it in some way. Your team should not take this decision lightly. A hack is not a ready-to-market product. Last minute code refactoring has no place at a hackathon. If your hack could use some additional user-facing improvements or features, you need to evaluate what the risk vs. reward of these changes are, and give yourself time to recover if something goes wrong. At minimum, I would refrain from making any modifications to the hack within an hour of your final presentation. At some point, you have to stop breaking things!
This doesn’t mean that you shouldn’t create a list of possible changes to tackle at another time. As previously mentioned, a hack, if done correctly, is just an MVP, not a finished product. But that shouldn’t stop you from thinking about future iterations on the concept. Hopefully, your hack is something you believe in, so feel free to pick the project back up after the competition ends. Just don’t risk breaking anything right before your presentation. Speaking of which…
5. Present like your hack depends on it (it does)
Some hackathons have sequential demonstrations, while others have showcases where judges check out the hacks at their leisure. Either way, presentation matters as much, if not more, than the hack itself. If you have an amazing project but can’t convey its awesomeness, what’s the point? Make sure to dedicate a significant amount of your time to preparing and practicing your presentation.
This is where having non-developers on your team can be tremendously helpful. After defining the MVP, these members of the team can plan how to best market it in parallel with development — so long as both groups communicate with each other about any major changes. Developers can help focus on the “what,” while the others help refine the “why.”
Before designing your pitch, you must identify your audience. If your hackathon invites the public to judge, you’ll want to capture their attention and keep it light on the nitty-gritty. If you’re presenting to business stakeholders, incorporate key financial projections and examples of value-adds for the organization. Lastly, if your fellow hackers are rating your project, go over the tech stack and show-off the intricacies of your architecture.
The most memorable presentations are usually the most interactive ones. It’s one thing to witness a program being used; it’s another to experience it for yourself. If you can find a way to allow the audience to demo your product, go for it (as long as you’re cognizant of your potential edge-cases).
If you follow these steps, you should leave the hackathon with an interesting, unique, and well-executed deliverable. This is not to say that you’re guaranteed to win, but that’s far less important than the skills and experience you gain from participating in these events.
If you’re interested in joining our team, feel free to check out the job openings at Soluto Nashville and send me a note!
