Published
17 December, 2013

Hack the Midwest 2013 & How to Win a Hackathon

#hackthemidwest2013

I had a great weekend thanks to Hack the Midwest. I attended last year, and if last year was awesome, this year was EPIC.

Hack the Midwest was held at Sporting KC and was sold out with 150+ developers creating 30 teams. It was amazing to see how not only the caliber of apps and presentations of them went up, but that as the number of overall developers went up, so did the number of women attending!

I was fortune enough to be on a team with fellow super-talented developers from VML – Russell Madsen, Joe Longstreet, and Todd Way. We created an app that allowed you to flag certain emails based on sender or subject line, and when an email when one of those flags hits your inbox, you received a phone call reading that email out loud. To check out our app, visit our Hackerleague page. We won best use of the Twilio API and took home shiny new iPad minis!

With that in mind, here are a few tips on how to win a hackathon.

1. Go in with an app in mind.
Review the APIs, and try to solve a real world problem using them. Prizes are (typically) awarded for best use of an API, so it’s important to use at least one.

2. Come prepared.
You never know when inspiration will strike(likely 2am though). Bring anything to help, be it an extra monitor, a soldering kit and arduino, or a pillow for a power-nap.

3. Establish a workflow with your team.
Determine who will do what task, and talk about how to commit your code. Appoint someone to be in charge of merging and branching to keep things current, and be able to quickly find old code as the app changes. Focus on immediate needs(interacting with the API and getting a response), before other things(users being able to create an account, design, etc).

4. In choosing an API ….
Understand the limitations of the API, but don’t let it deter you. Companies love to see the potential of use for their API, even if support for a feature may not be 100% accurate at the time.

5. Talk to the sponsors.
You may run into problems only they can solve. Certain APIs may only allow for a certain number of calls under a free account, and you can easily blow through this limit testing your app. They can get you set up with less limitations. Having trouble? It’s their job to know their API, and they’re there to help!

6. Code smarter, not harder.
Strive to build an app that will function for a demo, but don’t focus on perfection. This is a proof of concept, you want to show the general idea. Developing for every possible scenario will take up too much time, and you only need to show one example during a brief demo.

7. Recognize blockers and react accordingly.
If you are unable to implement something in a timely manner, raise a red flag with your team. Ask for help. If you’re all unable to solve it quickly, restructure your app, and move on to the next feature.

8. Take breaks.
Timelines are short, but slamming your head into a desk because you can’t solve a problem doesn’t get you anywhere. Go for a walk, hackysack, grab a beer(if permitted), or hang with your team. You’ll come back refreshed, likely to solve whatever you were grappling with, and may even have a few new ideas for features.

Breaktime! #halfyard #hackmw

9. Submit your idea.
Find out how to ‘submit’ your app. Many hackathons use hackerleague which allows you to add your project, team-members, site link, app description, and API tags.

10. Give a concise presentation.
Do a practice presentation first. Talk briefly about the problem your app is solving, and highlight the need for it. Discuss which APIs you used and how. Demo your app. Talk about future uses and extended features that weren’t able to be created in the hackathon’s time allowance.

SIDEBAR


Code of Conduct      Copyright 2023 © Kansas City Women in Technology