How to Prepare for a Hackathon

DZone 's Guide to

How to Prepare for a Hackathon

Want to prep for a hackathon? Yeah you do. Check out these great tips.

· Agile Zone ·
Free Resource

In a previous post I wrote of why I like to participate in hackathons. This time I'd like to talk about how to participate. What sort of prep work you will need to to get ready.

Understand the Theme and the Sponsors

You may have the most awesome idea for an app, but if it doesn't fit the theme of the hackathon you will lose. If the theme is "Teaching Kids", in some way your app must help teach kids. If it doesn't, you lose. 

So take the time to fully understand the theme of the hackathon. I recently participated in the Tizen Devlab and Hackathon in Los Angeles. The theme was to increase the apps in their store and to raise awareness of their mobile platform. The apps which won, including my own, were something the judges felt were both store worthy and could be finished in a reasonable amount of time. "Pie in the sky" apps didn't win.

Also take the time to know who are the sponsors and judges. If the some of the judges work for Yahoo for example, your app will probably be rated higher if it uses Yahoo's APIs. In many hackathons, use of the APIs is the theme. I have see developers make many mind blowing fails, like not using the API of the company sponsoring the event and instead using one of their competitors. I haven't seen any of those devs win yet.


Take a look at when the event start and ends. Make sure it is something that you can fit into your schedule. Not just the time at the event but the time you will have to spend preparing for it. You don't want to have to tell the judges that your app is crap because you didn't have enough time to prepare. Everyone gets the same amount of time. You should only participate if you are prepared to bring it.


The very first thing you should do in order to prepare for a hackathon is to read all of the instruction. This is more than just the web page announcing the hackathon, you will want to read everything. All of the rules, regulations, and the fine print stuff. The bigger the prize, the more thoroughly you should read everything. If you are part of team, every member should read the instructions. It would absolutely suck to have coded your heart out only to be disqualified in the end for a minor rule violation.

Keep a special eye out for things which would disqualify you like being an employee of one of the sponsors. Many companies have very complicated structures and you may not even be aware that your company and the corporate sponsor are both owned by the same parent company, which may make you disqualified. If you have questions, be sure write the sponsors ahead of time.

Create a To Do List

For nearly every hackathon there are things you must do. Some are explicit and others implicit, but all should be on a to do list. For example if you need to use a sponsor's API, it will help to know the API before the day of the event. If the hackathon is in another city, you may need to buy travel tickets or make hotel reservations, both things you wouldn't want to forget, plus you usually save money by doing them early. My favorite tool for this kind of thing is Trello.com. It is free and it is easy to use. But a pen and paper also works.

Scout the Venue

Google Maps is an essential tool for scouting the venue. If you are driving, it is critical to know where you are going to park. Some venues provide parking but many don't. Even when provided, the lot may be small and parking scarce. So I like to scout out the location. Find a free or cheap parking lot and map how to get from the lot to the venue. Be sure to be aware of city parking regulations. Few things suck more than getting a parking ticket or worse getting towed.


You need to make sure to pack everything you may need. I have seen devs scrambling around for items which they forgot at home at every hackathon I've attended. Things as crucial as power supplies or as easy to forget as a video connector. I travel with my machine so much that I have two power supplies and to video connectors, one travels, one stays home. I check my travel box before I leave home and the venue to make sure I don't forget anything. Most venues will have video connectors for PCs, if you are on a Mac like me, remember to bring your own. In order for judges to fairly rate your app, they need to be able to see it.
Think about the noise level of the event. You may want to bring headphones or ear plugs so that you can concentrate. I bring my headphones, their charger, and my USB cable to charge my phone. 

I also recommend bringing your own snacks. Most venues will supply snacks and water, but you are at their mercy as to what constitutes a snack. I prefer to bring my own snacks. Along this line, be careful of too much caffeine. I see people drinking energy drinks like water and you can see it "weirding" them out. I usually drink just one energy drink per event and I save it for that long period of time from midnight until dawn. To keep from falling to sleep, I usually focus on my to do list, listen to fast music, and go for walks when thinking. 

Get Plenty of Sleep 

The night before the hackathon be sure to get plenty of sleep. Many times developers try to get too much done that last night and wind up hitting the sleep wall and fading early. Instead, be sure to get at least eight hours of sleep. And avoid doing anything too strenuous, save all of your energy for coding. 

Arrive Early

There are many benefits to arriving a bit early: parking is easier to find, you can scout out a good location to set up (some place away from the restroom and kitchen), and you can unwind and get yourself into a good coding frame of mind. 

Know When to Say When

I have been guilty of coding until the last minute and it is a bad thing to do. The judges aren't expecting a finished app, but they would like to see a demonstrable one. Stand before them and trying to talk your way through a crashed app won't impress them. Instead stop coding before the deadline and make sure your app works. 

Use a version control systems like Git, can save the day. It will allow you to roll back to the last working version instead of wasting time trying to figure out what you broke. While Git is helpful to an individual, it is critical for teams. Nothing sucks more than when someone breaks the build and time is pressing. Version control helps prevent this immensely.

It also helps to spend a bit of time planning out your app. This is even more important if you are partnering up with others. The app needs to broken down into bite sized nuggets and everyone needs to know what they are doing. Once again Trello helps here.


Newbies continue to be surprise by the fact that they will have to present their app. Don't be. Depending on the hackathon, your presentation may be as much as 33% of your weighted score. Now, judges aren't expecting some salesman-slick PowerPoint presentation. What they want is for you to be able to explain usually in less than five minutes, why you think you app has won. This is time to state all of the things from the theme that you used. I recommend writing what you are going to say and present down. I keep 3x5 cards in my go bag. 

Be careful of is bluffing. The judges are usually tech professional and they can smell a lie a mile away. I was at one hackathon where a guy present this great parking, but when ask what was the data source, he crumbled. There is no central repository of parking data and building that up would be a endeavor which would probably require VC money. It was a lot more effort than could be expected of a small mobile app hackathon. The guy didn't win.
Please don't let this list scare you off. It does take work to win a hackathon, but not too much. Plus, there are hackathons for all skill levels appearing around the world. Some only last a few hours and are geared towards beginners and students. So if you are interested in improving your skills, having fun, and winning prizes, please participate in a hackathon near you. And if you see me, say "hi".

agile ,hackathon

Published at DZone with permission of Troy Miles , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}