Published: October 12 2012

Hackathons are a thing now. Over the past two years I've had the benefit of participating, helping organize, watching demos for, and (soon) judging more than 15 hackathons. One of my favorite things about the hackathon community has been how quickly best practices have spread from organizer to organizer.

To that end, here are some "hackathon hacks" I've noticed or come up with over the past few years. If you're working on putting together your next hackathon, I hope they help!

Events around the hackathon

  • Pre-Hackathon Tutorials. Especially for a college hackathon, something like or git/python/html-css/javascript for beginners, and particular new interesting frameworks/tech for hackathon veterans are a great way to get the word out and build confidence. You're not going to teach anybody Ruby on Rails in sixty minutes, so consider the tutorials to be a chance to plant seeds and offer a technical head start. Newbies appreciate having at least some initial guidance and a rough path they can continue to take during the hackathon. Experienced hackers get a sense of what kinds of things might be fun to explore during the hackathon. I've seen PennApps put these together the week before and the Friday afternoon of the hackathon, both to solid attendance.
  • Office Hours. Greylock Hackathon from this summer (and I'm sure others before them) have explored the possibility of having Tech luminaries drop by and take meetings during the hackathon. The best time for office hours is probably about half or two-thirds of the way through the event, once participants already have a sense of what they're working on but are not so close to the end that they only have time for small changes.

Hack Breaks

  • Swag Raffles I picked this idea up from Philly Game Jam in 2010, and it was deployed to great success throughout various PennAppses. The basic premise is simple: offer participants a chance to win free stuff given out by sponsors if they meet some criteria (usually, being up late or answering a trivia question).

Originally, this was (largely) a ploy to get students to have a reason to stay late, since drawings occurred every hour from midnight to 6AM, and the prizes (as well as your odds) got better the later you stayed. Since then, it's become a great way to distribute swag available in limited quantities, get participants to follow you on twitter (by announcing winners there), and generally create a fun environment for everybody. I worry about the impact of too many disruptions, but using something like Twitter to announce winners (and setting a time limit to collect) has mitigated the concern.

  • Late Night Athletics There's a kind of euphoria I tend to get around 2 or 3 in the morning, after spending more time than is reasonable working and knowing that the end is not yet in sight. Euphoria with a good mix of fatigue.

Athletics help. Taking a bunch of friends and strangers and going "alright, now let's do something silly" is fun. PennApps has a midnight run tradition that is exactly what it sounds like: at midnight (really, closer to 1:20 AM) everybody who is up for it heads out and goes for a 10-minute jog around campus, jeans and not-quite-running shoes and everything. Tis a blast; highlights include the time when we jogged Dave from Andreessen Horowitz back to his hotel. More recently, a 3AM game of ultimate frisbee (complete with glow-in-the-dark frisbee) made me happy the organizers had not neglected gatorade a drink option. I've also heard of impromptu juggling lessons.

Late night athletic events have the benefit of being both fun and sufficiently out of place to be memorable. Plus, it's nice to get out and stretch your legs.

  • Bubble Tea and other excesses Some of the more fun food hacks/surprises involve ordering several gallons of Bubble Tea (at PennApps), Red Bull Jello Shots (really) at the Greylock Hackathon, and late night cheese-steaks (via Venmo at now-every PennApps), and Ice Cream Sandwiches (HackNY).

I'm still waiting for somebody to cater a pancake/crepe maker to make breakfast crepes on demand, for the morning of demos. There's probably no better sign of how hackathon-spoiled I am that I'm waiting for that.

Update: HackNY and Michigan email/tweet me to provide photo evidence of said crepes/pancakes. I love the internet.

HackNY Fall 2012: fall 2012 hackNY student hackathon

Michigan's Learn To Hack:

Logistics Hacks

  • Catering Figuring out catering for a hackathon ends up being rather non-trivial; the location you're having may have union or contract rules that say you can't bring in outside vendors, and traditional catering options are expensive and kind of 'meh' (no, we don't want another sandwich plate).

Some of the best food I've seen at hackathons comes from working with existing favorite choices, from bringing in popular food carts or popular choices from campus or the city, and getting a bulk discount based on the traditional pitch that you are exposing desirable customers to their menu. I've also heard that Chipotle and Red Bull representatives (amongst others) don't have a problem providing some amount of free or heavily discounted merchandise to hackathon organizers.

Provide variety throughout the event, provide (reasonably healthy) and vegetarian options. Whatever you do, don't order Pizza. Not even once. OK, maybe once if you get desperate.

  • Room For Improvement: Organizers' Sleep Schedules. PennApps recently moved to a "who sleeps on what night" rotation, meaning that event organizers will likely get a reasonable night's sleep on the first night or the second. This is certainly better than the previous ordeal (organizers sleep when they can no longer stay awake) but can still lead to an organizing team in charge of demos at less than 100%.

Here's my proposal: break the organizing team into two: a Hackerspace team responsible for during-the-hacking events, and an Event team in charge of everything surrounding the hacking: Kickoff and API Tutorials before the start, and the Demo Session and Awards after. A dedicated event team means folks that have gotten a ton of sleep before each event and are wide awake to move quickly and deal with any issues that come up at the last minute. I'd love to hear from anybody that has an approach they've tried and liked, and that works.

  • Room for Improvement: Drinks Vendors.

Anybody who's had a summer internship at a big-enough, 'tech' company knows about the contents of the Facebook/Google/Twitter beverage fridge, full of fresh fruit juices and various ice teas and all sorts of goodness. Since the first PennApps, I did my best to replicate that experience, to make (by any means necessary) to make the point that there were some benefits to working at a startup, and look: here they are, an always stocked, no limits free fridge of goodness.

I learned that getting a see-through beverage fridge, as well as actually obtaining the necessary drinks for the fridge (Honest Tea, anybody) is a bit of a challenge. Those types of fridges are a headache to rent, and Honest Tea is just not for sale at Costco.

I've since learned that O'Sullivan Vending provides drink catering to Google, Facebook, and most tech companies in the Bay Area. They are expanding to other areas, though not quickly enough.

If anybody has seen any hackathon do an awesome job of their drinks catering, from the fridge to the selection to the constant availability, let me know - I'd love to learn and share how.

Demo Hacks

With a seemingly endless supply of teams hoping to demo and an exhausted audience, lots and lots of things are continuously trying to go wrong. Some hacks towards making demos run more smoothly:

  • Demoing mobile apps

Ideally, obtain a document projector (like back in middle school) a few days before the event, set the focus (once) properly, and put up a big sign saying "don't touch this knob." Explain this principle to demoers, and make it trivial to switch one of the on-screen views to the mobile projector.

If not, I've had a surprising amount of success with taking the demo laptop and using it's webcam to show off the mobile experience. It's hacky, and should be prepared way beforehand, but it works.

Emulators are a bad idea; they involve plugging in somebody else's laptop into the projector. Pain this way lies.

  • Preparing teams for their demo:

Folks, X by Y is the resolution you're going to demo on. Better be ready.

Don't rely on Wi-Fi working. There's no place like 127.0.0.1.

In general, if you have any special requirements let the organizers know way in advance.

No using your own laptop unless you absolutely, unequivocally, have no choice whatsoever (IE, desktop app). If so, let the organizers know in advance and we'll see how we can accommodate you.

Ideally, have a second (identical) set-up in a nearby room for teams to practice on a few minutes before they demo, as part of the demo queue. If not, at least make the demo setup available morning-of the demos and encourage teams taking a chance to practice.

  • Demo Order Use things like HackerLeague (or just Google Forms) to organize the demo submissions and order.

Does anybody have to leave early? Put them in front. Otherwise, randomize demo order.

Publicize demo order ASAP, and make it obvious where it is. It really helps teams to know where they are in the queue in case any of them sneak out to the bathroom, etc..

  • Needs Improvement: Demoing with >50 teams If you have more than 30 or so teams demoing (and especially more than 50), consider exploring ways to cut down to either about 30 demos or about 15 demos with judge interaction. I've heard about the LinkedIn Intern hackathons doing this well, and Greylock Hackathon and AngelHack both did a good job as well.

The worry with multi-tiered judging is this: imagine you spent your entire weekend sleepless. Your implicit reward, prizes or not, is that a hundred or more people will get to see what you did and, prizes or not, applaud your effort. Instead, you go into a tiny closed conference with 4 older-looking folks who listen to you for two minutes and then wait for an email with the list of finalists - a list you're not on.

That sucks.

Multi-tiered demoing needs to be done in a way that recognizes the work hackers put in. I don't know how to do that yet; having three demo auditoriums for the first round feels a bit of a logistical mess. Open for ideas - email me on this one.

Updates: