How To Win A Hackathon

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...)

- 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.

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.

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.

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.

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.

John Sheehan from Twilio has some great tips too - http://www.quora.com/Hackathons/What-are-some-useful-tips-wh...

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.

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!

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!

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.

Dev + Designer + Keep em laughing = $$$