This year I competed in three hackathons, finishing 2nd, 1st and 1st. Reflecting back on those events, I walked away with several non-technical lessons learned to make a team successful. Here are my battle-tested tips for winning a hackathon.
Before the event:
- Marry up: If you're really serious about winning, you'll do what I did and marry a technically competent person who works well under pressure and can woo the judges. Short of that, you'll have to choose a partner.
- Choose a Good Partner: Choosing a partner or team is the most important decision you'll make. You need to find someone that you communicate well with, especially in those tired cranky moments. I saw one team yell at each other half way through the night, pack up and go home, never to return. It's also important to have people you can trust to execute because you'll need to divide up the work.
- Sleep: The day of the competition, take the day off from work and sleep. Sleep as much as you can up until the event begins.
- Equipment: Bring a monitor or two and your favorite mouse. Create a comfortable environment where you can be productive.
During the event:
- Plan, then Execute: Do all of the heavy thinking and planning early in the evening. Write out your plan clearly while you have your wits about you. Spend the later hours just executing your plan.
- Cut your Losses: Don't fall victim to the sunk cost fallacy. I spent 6 hours at one hackathon trying to get rCharts to work with Shiny. At some point I had to just give up and use ggplot to generate plots, which ended up being just fine. Static ".png" charts are better than no charts. Remember, you're under the clock.
- Build Incremental Pieces: Make one thing end to end quickly. Get at least something basic put together, and all further enhancements should just be additions onto that first piece. An incomplete grand idea that the judges can't see isn't going to win.
- Be Anti-Social: Maybe I'm an overly competitive recluse, but people are oddly chatty at these things, which can throw off your coding zen. Bring headphones to be less approachable and make it look like you can't hear them.
- Dedicated Focus Time: Take breaks from your teammates. Have dedicated time to just code and work through something independently. Resist the urge to pepper each other with comments and questions all night. Write down your question if it's that important. Those little distractions will break someone's already fragile concentration.
- Story, Story, Story: Everything you're doing is in support of your pitch to the judges. Each chart you build should be part of that narrative. Think carefully about the order of your presentation, and as good talking points come to you over the course of the night, write them down. You'll be too tired to remember later.
- Naps are Good: Don't be afraid to take a short nap. My clue for a nap is when I start creating more bugs than I'm fixing. That normally hits around the 10-12 hour mark. Even if you're not able to get to sleep, the still time will help you think through the thing you're stuck on.
- Play to the Judges: We are trying to win here, so it's all about the judges. Find out who they are. Learn what you can about them, what makes them tick, and how technical they may or may not be. Droning on about the computer science paradigm you solved with Scala last night won't impress a business person. Having a solution to their business problem is what will impress them.
Near the end of the event:
- Don't Break It: Stop making code edits 30 minutes to an hour before the whistle blows. You don't want to break your code just before game time. Use the remaining time to read through your notes and stitch the story together.
- Test the Projector: Test your computer's connection to their projector. Make sure the colors and resolution come out right.
Good luck and happy hacking!