

How To Win A Hackathon - Ataub24
http://alexstechthoughts.com/post/28836325740/how-to-win-a-hackathon

======
Timothee
Based on my humble experience (I won at Disrupt SF last year), I'll add this:

\- as the OP said, when presenting, _start with the problem_. But really
insist on it so that it becomes painful for the judges. Show the problem
you're trying to solve on existing sites/apps. Then show your solution on how
you solved it. (See this post by Dave McClure for reinforcement of the idea:
[http://500hats.typepad.com/500blogs/2009/08/your-solution-
is...](http://500hats.typepad.com/500blogs/2009/08/your-solution-is-not-my-
problem.html))

\- don't try to do too much: e.g. you don't need a web app + a mobile app to
show you've solved the problem. "And we have a mobile version of it" doesn't
help you in convincing the jury that there was a problem and that you solved
it. Everyone knows that a website that solves a problem can exist in the form
of a mobile app. You're wasting your time just mentioning it.

\- don't discuss the technical problems you've had. For you it's interesting
that you finally managed to get around that hurdle and it's tempting to
quickly brag about it, but jurys don't care.

\- while _focusing_ on an API can work, I'd say to also try to incorporate
some APIs if that makes sense and you have time. My hack was about showing
movie schedules à la Hipmunk (a slow, uglier-than-it-was-then version is still
up: <http://flickmunk.com/>), but I managed to find the time to add some
Twilio pieces to it (I was familiar with the API already) and that was enough
to win their prize too (a MacBook Air no less) while other hacks were _fully_
focused on Twilio and didn't. E.g. if you need to store files of some kind,
use Box or Dropbox if they're there. Don't push it too far though. Pick one or
two that make sense. Your hack is not a NASCAR car.

\- while your presentation should be as polished as possible, I was never
convinced by people who made videos, flash animations or beautiful slides. I
think some judges want to see a minimum viable product/PoC, not a PowerPoint.

\- as far as polish go, I'm sure a nice design does help, but amongst the
winners at Disrupt, it wasn't the most polished that won. (mine clearly
wasn't) It was the ones who solved a problem and worked. Too much polish might
make it look like you had been working on it for some time before. Nowadays,
with Bootstrap, you get something decent-looking enough to get started.
(though beware: everyone uses it too)

\- finally, and that's important: be persistent. My old MacBook couldn't be
connected to the projector at demo time so they told me I couldn't present. I
was pissed! But I stayed around, asked for a second chance at the end if there
was time, just for _at least_ present. I almost gave up but I'm glad I didn't.

Of course, all this comes with "YMMV", or "your jury may vary". I think most
judges look at demos and want to see something authentic, something that was
really built during the hackathon and will excuse roughness around the edges.
Some jurys can probably be swayed by a nice design and presentation.

~~~
caseysoftware
Twilio evangelist here..

I think Timothee hits most of the points very well. Nice job but I'd like to
add a few things:

\- To add to the "don't try to do too much" point, I'd say the _vast_ majority
of judges would like to see a few things done really well as opposed to a
flock of things sort-of-done. When I mentor a group, I tell them to close
their presentation with "Going forward, we'd like to also do A, B, and C. Any
questions?"

\- Avoid video if at all possible. Videos take 5-10s to switch into and
another 5-10s to get out of. And that's assuming you have the audio set up
properly. I saw a group recently spend ~10s switching, started playing the 30s
video, had to stop it to adjust the audio, restarted it, and then ~10s to
switch. It threw off the pace and ate a minute of their 5 minute presentation.

\- Practice out loud as many times as possible. The demo will be smoother and
just feel easier.

My 0.02..

~~~
jasonlotito
> "don't try to do too much"

Yes. This has served me well. I got into a hackathon with the assumption that
I'll be the only developer there. With that in mind, I focus on what _I_ can
accomplish in a weekend.

I plan for additional things, but I keep focus on what I need to do.

I also try to plan for additional people. For example, if I get another
developer, what will they work on? A lot of it is back and forth, but having a
plan at least gives you a place to start.

Planning is important, and lets you spend the weekend having fun instead of
worrying about whether you will get done or how to manage a larger team.

------
eggbrain
I've won a couple of Hackathons recently, and the two keys I found were:

1) Make sure your presentation is flawless 2) Don't take on too big of a
challenge.

We saw plenty of people that had great projects, but when they went up to
present, they had the worst speaking skills I've ever seen, and failed to get
their ideas across to the judges. Similarly, we saw plenty of people who took
on too much in one weekend, and their presentation consisted of "Well, we
wanted to finish X, but we ran out of time" or "This is cool, but doesn't work
yet".

The projects we won with were never very complicated, but they were highly
polished and you could instantly wrap your head around them.

~~~
Ataub24
Great advice. Thanks.

------
aggronn
The first hackathon I attended was won by some very uninspiring use of the
last.fm API and some other simple tools. It was basically a dashboard to
listen to music and get information about the artists with some geolocation
stuff. It was interesting to see them win first place, because to the
'hackers' at the event, the project was pretty lame, but since they were done
with the functional part of the project after just a few hours, they could
spend the rest of the day working on making it look nice. They clearly had the
best looking product of the day, and they won because of it. Second place went
to a twitter bot that responded to tweets with jokes. I think that a lot of
hackers (or maybe just me) go into these things, especially if they haven't
gone before, expecting to win by way of being innovative and smart, only to
find that what counts in a world of non-technical judges (ie, the real world),
isn't necessarily new ideas, but aesthetics, humor, and more generally, human
appeal.

------
tikhonj
I think this advice really depends on each hackathon in particular. I've only
gone to hackathons at my university, and I haven't found that good design is
enough or even necessary to get first place. In fact, the first-place projects
I remember had fairly poor design and won because they were impressive
technically. Of course, really beautiful apps that were far less impressive
technically _did_ place, but only second or third.

The first-place winners I remember were: a program that synced lyrics to music
automatically, a distributed computing framework for JavaScript and a rather
accurate face-recognition system. All of these did not have beautiful (or,
frankly, even _passable_ ) front-ends, but were nontrivial and rather
interesting from a CS standpoint. Moreover, this is not because _nobody_ had
good design--there were certainly very polished apps, and they even often
placed second or third. They just never won first place at any of the
hackathons I've been to.

------
kandalf
A couple more tips:

Topical ideas are great. The judges can better identify with the problem that
your hack solves, and it seems more relevant.

Hardware hacks tend to steal the show, e.g. a touch-enabled chalkboard,
hardware "facebook", or a tweeting microwave. At three of the last four
hackathons I've been to, a hardware hack has won. But be wary - at some
hackathons they'll specifically tell the judges that the winning hacks must
balance being awesome with being useful (specifically the facebook hackathon).

Fake it until you make it. This is a lesson I still need to take to heart. If
your app doesn't look like it's going to work and you have an hour to go, hack
together something that will give a good demo.

------
telecuda
John Sheehan from Twilio has some great tips too -
[http://www.quora.com/Hackathons/What-are-some-useful-tips-
wh...](http://www.quora.com/Hackathons/What-are-some-useful-tips-when-
competing-in-a-Hackathon)

~~~
Timothee
_John Sheehan from Twilio_

Actually, it's now " _formerly_ from Twilio". He works at IFTTT now.

------
codenerdz
Ive noticed at a couple hackathons that Ive been to(including Disrupt and
AngelHack) that a number of teams came with projects that were either already
prepared and they just added a feature on top of them or they were already
half-done and were completed at the hackathon.

Furthermore ive seen people communicate with remote teams at Hackathon.

Both of these I see as sort of cheating, not unlike doping in sports, since
idea of the Hackathon is to show what can be done in 10-20 hours of hacking.

------
carterschonwald
Who cares about the weekend winning? Meet cool interesting new people and
learn a wee bit. Hackathons can also be great collaborative community building
events!

------
picardo
I had a lot of fun at ecommerce hackathon. I've thought about what makes for a
great hackathon, and, credit where credit is due, it comes down to the
organizer. Alex organizes the best hackathons I've ever been to in NYC, and
I've been to them all. Photo hack days last year were several notches above
everything else, and now that Alex is at Dwolla, we're seeing the same thing
in ecommerce themed hackathons. Great job, Alex!

~~~
Ataub24
Thanks dude, means alot.

------
powerslave12r
Can someone tell me where I could, as a hobbyist, participate in some
hackathons?

I have tried searching and most events seem to be specifically for intra-
company, or entrepreneurs vying for some piece of a pie.

~~~
nicolethenerd
<https://www.hackerleague.org/>

------
bproper
Dev + Designer + Keep em laughing = $$$

