How to Win a Hackathon

October 22 2012

Hackathons For Fun and Profit

Before I switched over to the Developer Evangelist side of the hackathon business, I had won seven or eight major events, thousands of dollars in cash and prizes, and a bit of a reputation as the girl who leaves no cool stuff for anyone else. Now attending these events as a sponsor, I focus on advising teams using Temboo on how to maximize their probability of success when they demo.

As a result, teams that have used Temboo at hackathons have won prizes at Hack’n Jill, AT&T Mobile App Hackathon, and HackNY. In fact, multiple teams took home prizes after building their hacks on Temboo at HackNY.

So what is the secret? Hackathon success is about strategy, not necessarily top technical skill. Of course, the better, more versatile developer you are, the easier it is to be successful. But the best hacks are rarely written by the best minds in the room.

Know Your Audience

Or in other words, pick your prize. Sponsors will often bring their own prizes as “Best Use of” awards. Your odds of winning one of those is much greater than winning First Prize or People’s Choice, especially if you structure your hack to speak to their needs. I once won $1,500 from Getty Images because I not only used their API the way they were hoping developers would, but I wrote a quick library for other developers and threw it up on GitHub. By speaking to their interests, I left a bit richer.

Define Winning

Which brings me to my next point: winning a hackathon is not necessarily about first place. Ultimately, hackathon crowds give more weight to number of prizes you’ve won over the supposed hierarchy of those prizes. The bulk of a hackathon demo audience are fellow hackers hoping to win prizes for their own submissions. The team that picks up two or three prizes has much better odds of being remembered and getting the boost in street cred than the team that takes home the top prize. You remember the winners that matter to you. You remember the people who beat you. By the time first prize comes around, most teams know they’re not serious contenders, so the biggest impact of reputation often comes from winning where others think they might have a shot.

What leads good hackers astray is thinking that tacking on as much as possible will improve their odds of success. These piecemeal hacks rarely hit the mark because their array of features often don’t make sense. If they do win something it’s usually by default: they were the only team to use a particular service.

So do go for multiple prizes, but be strategic about it. See who’s sponsoring prizes. Can their technology add value to your idea? Focus on one or two interest groups and go after them directly.

Do Something Interesting

A hackathon is not a business plan competition. Sure, there are more business-focused ones like Startup Weekend or Angelhack, but ultimately hackathons are not about solving problems or building businesses. They’re about going beyond the things you would normally build at work, playing with and pushing the limits of technology. Many teams go home empty handed because they try to build startups instead of hacks. They explore reasonable ideas or create solutions to problems people aren’t particularly passionate about. Does group food ordering have a larger potential market than a fridge that can alert you when someone is stealing your snacks? Yes, of course. But the snack stealing got the top prize because it was both creative and technically interesting.

People don’t come to tech events to see their current inconveniences reflected back at them. They come to get excited about the future.

Keep The Theme

I’ve seen groups win big using none of the suggested technology available at the hackathon, but I’ve never seen a group win that didn’t keep with the theme of the event. But boy do people try. Often these hacks are existing ideas/project that the hacker is trying to reframe to qualify. It’s really obvious when it happens, and hacking on an existing project is frowned upon anyway. You can sometimes get away with bringing in previous work if the match with the theme is perfect and the hack itself is really impressive, but otherwise don’t bother.

Remember you’re dealing with a sophisticated audience, you won’t fool anyone.

Maximize Your Swag

Every now and then sponsors bring hardware to the hackathon. If you have any interest at all in the device in question: hack on it. Don’t concern yourself with the idea, just hack on it.

Nine times out of ten the sponsor with the goodies turns around at the end of the hackathon and announces that anyone who hacked on the device in question can keep it. They already can’t sell what you’ve spent the day screwing around with and (depending on how far they’ve come) it might be an expensive pain to take whatever they’ve brought back with them. The marketing value of putting a free device in the hands of an influential user outweighs the loss of giving it away.

Avoid Large Events

Yes, I know: the fame and glory of Tech Crunch Disrupt beckons. The prize money can’t be beat at large events, but you’re basically trading a whole lot of value that hackathons can bring for a tiny chance at winning the lottery. Large events mean more stress, more competition, fewer teams assembled on the fly, less getting to know your fellow hackers, less interaction with sponsors and guest speakers, less networking, longer demos, less quality people, cheaper food, worse accommodations.

Smaller hackathons, indeed dare I say even hackathons without prizes, have a lot going for them. Most of the really impressive people I’ve met through hackathons I’ve met at smaller events. People who know their stuff don’t want to spend a weekend getting as stressed out as they might get at work.

Don’t Go For Cheap Gags

Giving a great presentation can be the difference between going home with nothing and going home with glory. Having a great sense of humor and being comfortable speaking in front of people helps a lot, but sometimes people misunderstand the influence of a demo that rocks the crowd and assume the secret to success is building something funny. These teams think they’re making a serious bid for People’s Choice, but People’s Choice tends to go to the hack the audience admires the most … not the one that’s the most entertaining. If someone builds a hardware hack while you’re messing around with fart jokes and cat memes, you’re done for.

Do be funny, but have some substance behind that funny first.

Don’t Be Afraid To Fly Solo

My rule of thumb with the ‘to team or not to team’ question is this: do I have a clear idea already and is there a group whose idea interests me more? Sometimes I show up without a clue what I might want to build. On those occasions I’ll usually jump on someone else’s team and pitch in where I can. It’s a great way to get to know a new group of people.

But hacking solo has its advantages too. It’s usually both faster and easier. You don’t have to mesh your style with someone else’s or worry about code you write at 3am being readable and elegant. You also don’t have to worry about splitting your prize up.😉

Don’t Overplan

Every time, without fail, there is always at least one team that wastes valuable time debating the minutia of technical components that might be significant to scale the app to a hundred million users–Wait, what? I’m not kidding, I once watched a group argue for twenty minutes on whether or not to use a Captcha system to prevent spam robots from using the app they were building. Twenty valuable minutes of hacking time wasted talking about something that did not matter at all. Even if they were able to get their hack live and online, spam bots were not going to descend immediately.

Fake Your Interface

Let’s be clear: No one expects you to build a production ready app in less than twenty-four hours. Your hackathon audience will generally forgive a certain amount of fakery on time consuming, but technically uninteresting elements. Don’t fake the core components of your hack, but if you don’t need to demo a user logging into Facebook, don’t waste time setting up authentication when you can just use some clever HTML/CSS to simulate the same thing. We all know you can do it for real. There are only ten thousand various tutorials on it now.

Know Your Stack

Hackathons are great places to learn about and experiment with new technology. However, if you want to win, this isn’t the time to get your feet wet in a completely new language or an unfamiliar framework. Try to limit the number of “new” elements to one or two small things. You will hack faster and maximize your focus as time is winding down. There’s nothing more disheartening than wrestling an issue you have never seen before at three o’clock in the morning. When learning a new language, you’re going to want to take your take your time. Time is one thing you do not have at a hackathon.

Remember What Hackathons Are About

You go to have fun, to hang out with other people who love tech, and to push your limits. Hackathons are basically networking events for hackers; profiting from them is about more than just winning a prize. I’ve made so many valuable connections at hackathons: people who have opened doors for me, mentored me, gave great advice, and helped me find resources to continue sharpening my skills.

Hackathons For Fun and Profit Before I switched over to the Developer Evangelist side of the hackathon business, I had won seven or eight major events, thousands of dollars in cash and prizes, and a bit of a reputation as the girl who leaves no cool stuff for anyone else. Now attending these events as […]