How to attend a hackathon

December 9, 2012

hackathon networking meetups

I think hackathons are really a great thing. They are a relatively new concept, so it is not surprising when I attend one I find myself hacking away with others that are new to the idea. I also think they are a little misunderstood. Even some organizers do not focus on where the real value is with hackathons.

My background with hackathons

I wouldn't be involved in startups if I didn't attend Startup Weekend in Seattle back when I was in college. The idea of taking the extra effort to build products with likeminded people immediately struck a chord with me. I haven't looked back since.

I also wouldn't be in the bay. I attended another Startup Weekend in San Jose shortly after the one in Seattle that helped me network with people. From there, I was able to meet the people that got me my first job in the bay. More importantly, I'm still close friends with many of the people I met at hackathons. Even years later we meet regularly.

Different hackathon types

There are 3 general types of hackathons as I see it.

In-person (AngelHack, Startup Weekend, Disrupt)

Usually a large group of people that don't know each other well. Usually a competition is involved with the winning receiving some sort of seed-funding or support to continue their project into a real company. These are the most 'entrepreneurially' focused. These are the focus of my article.

Internal

A hackathon at work. We've done this at Tapjoy a couple times. The rule we have is, "you have to work on something you wouldn't do on a normal work-day." As I understand, it's gone very well from all sides. I would encourage looking into doing something like this for your own team. We've had some variations in how we've done it (assigned/unassigned teams, in-office and off-site), but I can't say what's better/worse just yet.

Online (Rails Rumble, Node Knockout)

A hackathon that is conducted only online. These are the most engineer-focused. Typically the products will have a smaller scope and target more specific challenges. Usually there are prizes, but most people participate just to build something. There is usually little-to-no need for non-engineers and non-designers in these types.

Who can attend a hackathon

Pretty much anyone can attend so long as they are willing to participate. Even if you don't code/design, you can work on building a business model, pitch deck, website copy, etc.

If you're a student or new to coding don't be worried. Hackathons are a great place to learn new things. If you're looking for a job, they're incredibly good for networking. Unlike most networking events, your contacts will actually be able to speak about your skill in a very intense environment. In fact, I would actually like to see universities get much more involved in hackathons.

Why attend a hackathon

The number one reason is to have a good time. Expect to laugh, socialize, learn a ton and spur some creativity. It is so powerful that I find after I attend a hackathon I have a much improved attitude and have a higher level of creativity.

Expect to meet some new friends. Even if your team is with co-workers or current friends, you will find you're much closer to them following the event.

Hackathons are intense. I try and do very little the day before a hackathon starts (and I typically don't even pull the all-nighters as some do).

What shouldn't you expect?

  • Don't expect to find a great idea; hackathons are about execution.
  • Don't expect to win; hackathons are an experience first and competition second.
  • Don't expect to launch a company; the way you execute in a hackathon context does not translate to the real world.
  • Don't work too hard; there's a high probability that most of the work you do will never be seen by anyone outside your team.

Most importantly though: try not to expect anything. Every hackathon involves a ton of chaos. That chaos is where the benefits lie.

Regardless of the hackathon, they have a standard formula that takes place over 1-3 days:

  • Pitches and building teams
  • Deciding what to build
  • Building product
  • Deciding what to demo and how to demo
  • Demo/presenting/judging
  • Heavy drinking

The pitches

I like how Startup Weekend does this part the best. They start everyone out on Friday night before the weekend. Everyone goes down to a big auditorium where they have soda + pizza, give some introductions, thank the sponsors, then have everyone line up that brought an idea to pitch it for about a minute.

I haven't actually given a pitch myself, but I am pretty analytical with regards to the pitches. Picking a team is a big deal, and most of my decision will be based on the pitch.

Pitches contain the following:

  • A problem to solve
  • A vague idea or 2 on possible solutions
  • What roles are filled and need to be filled
  • Roughly what the pitcher's background is

Some are serious, some are less so, and some are not even real projects. At AngelHack there was a team that was going to spend the day flying a plane around in the parking lot. Another team wanted to film pornography.

Personally, I am looking for the following in the pitch:

  • Do I care about the problem?
  • Does he/she understand the problem?
  • Does he/she understand their own solution and it's complexity?
  • Is it something I think can get done in a weekend, with time to prep a demo?
  • Will the solution actually demo well?
  • What is their role? Is it someone I think I will like to work with? (Hard to answer this one)
  • Will it be fun to work on?

You might be incredibly disappointed after hearing the pitches. I was my first couple of times. The reality is that ideas really aren't ever that great. It's virtually impossible to tell what the winning team will be at pitch time. Remember though: this isn't about winning, it's about the experience.

Another tip: Take notes. Write down the teams that sound interesting. Make sure to also note what the speaker looks like, what their name is and what they're wearing so you can find them later.

Finding your team

After the pitches everyone breaks out and tries to find their team. It's the most chaotic part of the weekend.

People start swarming different presenters. You'll find that some groups get a ton of people and some get very few. Your job is to talk to as many teams as you can to find the right one for you.

This is also the point when you might get a little scared. You might think "well I didn't really love any of the ideas... maybe I should just go home and relax for the weekend". Power through it. This happens to me as well. You'll be glad you did.

Find out what the roles are going to be exactly. Are you a PHP developer? Do they want to build the back-end in Django? You might want to break out of your comfort zone and try something new. In fact, hackathons are where I learned both Rails AND Django. If you could believe it, I wanted to build my first app in .NET. Still, be realistic. If you're really not interested in learning what they want to build the app in then find a different team.

Brainstorm the solution, you'll quickly be able to decide if you want to work with that team.

Don't worry about big vs small teams. I've had a 8-person group that was great. We all had specific roles and executed well. Obviously, I met way more people as well. Large teams are also more likely to win (but again, that's not your focus).

I also have had 2-people groups that were great too. Definitely walked out after the weekend with someone I was happy to call a friend. I also got to have way more input in the solution and felt much closer to the product. More coding, less discussion.

Really though: find the team that feels right. You'll find one, I promise. One time I actually switched teams mid-hackathon because I found a better fit where people needed me more.

Refining the concept

Now that you've found your team, you'll likely seamlessly transition into some planning. Brainstorm different ideas about solutions. The conversation will be a little crazy. You'll jump all over the place. Only thing to keep in mind is to be optimistic and positive. This is no time to ruin creativity by shooting down ideas.

Find a place to set up camp for the weekend. Grab a drink. Just let the conversation go wherever it goes for a little while.

Once you have all these ideas out there, you'll start nailing down exactly what the product should be. Then it'll get even finer to 'what you can demo in a weekend'. This all happens pretty naturally.

When deciding your scope, keep it crazy small. Can't/won't demo it? Don't build it. You can build apps anytime: hackathons are for doing this socially. If nobody sees your code in action, it might as well not exist.

Hacking

There is really not much to say here. This is the most natural part of the event. Don't work too hard. Remember to meet people. Walk around and ask others what they're working on at least once during the event.

Oh, and caffeine is the hackathon wonder drug. You'll hack harder, longer, and be more motivated. Keep the red bull + coffee handy for you and your team.

Some hackers will go all night, I don't suggest it. Get what sleep you can. It'll be hard to sleep since the ideas will be swarming through your head. It's likely the morning of day 2 will involve some dramatic shifts in the product, almost always for the better. Hacking through the night won't encourage the healthy perspective after the drive home and a good night's sleep.

Start the day off with a solid re-analysis of the plan. Figure out what you can do for the demo.

That demo is hugely important. Repeatedly stop coding and think about what you're actually going to demo. It's tempting to build out features that won't be involved in the demo, but stop yourself.

Get screenshots! The best demos I've done have only been screenshots. Screenshots also can't fail like demos always seem to.

Demo time

It can be hard, but try and support your competitors. Winning is not important. Still, you're going to want to put on a good demo for the judges.

If you're actually going to show off your real product, remember to have your screenshots handy just in case. Last time I gave a demo we had to use a powerpoint on an iPhone. Be prepared for every piece of technology to fail. They're all likely to.

Post-hackathon

Go grab a beer with your team! If everyone is too tired, or not in the mood or whatever, set up a time during the following week to meet up. Even if you have to email them and meet individually: do it.

When networking, if you have that second interaction, it really 'seals' it somehow. You'll also have a ton to talk about between the idea you hacked on, the execution of it, the teammates, the other teams, the judges, everything. It won't be a boring conversation.

The number one thing hackathons do wrong

People disagree with me on this one, but the number one thing that virtually all hackathons do that I do not like is have a winner. I attended one hackathon (the Ballmer Peak-A-Thon) that did not have a winner. Everyone presented their projects and instead of critiquing everyone while thinking, "psh, mine is better" I was excited to see what each team built and felt a much better sense of community.

I didn't realize there was not going to be a winner until the pitches were already halfway through. At first I was disappointed thinking that our project could have won. I felt like I lost. That went away quickly. I noticed I appreciated the other projects SO much more.

Don't get me wrong: I love competition. I'm also sure that you reading this are probably thinking that without the without the competition the motivation would disappear. I disagree. People are naturally motivated to build things. The only thing having a winner provides is everyone to believe their project should win, and that every other project is worse.

I would like to see more winner-less hackathons. It's a much more pleasant environment.

Get out there and do it!

I try to attend a hackathon every couple of months. It's a big time investment that makes my weekend completely disappear. Still, every hackathon I've walked away from feeling as if I really gained a life-changing experience. They are intense, but so worth it.

- xxx


Related Posts