How to Navigate Your First Hackathon

The official student hackathon league Major League Hacking sends coaches to events to help participants come up with ideas, build their projects, demo, and receive prizes. As coaches we see the good, the bad, and the ugly of these events. This piece has some of our best advice on how to have an excellent hackathon experience, from arrival to final demo time.

The reigning motto of hackathons is “the perfect is the enemy of the good.” Teams meet, scramble to come up with a viable idea, and then assign roles and dive in — often in the course of under an hour. Necessarily less polished than something with a longer scope, hackathon projects are exciting and fast-paced. It is common to change directions several times in the interest of time or feasibility. Hackathon culture is extremely valuable and has been leveraged in the tech industry with mottos like “Move fast, break things” and internal hackathon week events that are now held at companies like Facebook, Microsoft, Google, Zillow, Pinterest, and many more.

Team-building

The people who work with you at a hackathon have the largest impact on the success or failure of your project and on your overall experience. Teams either form ahead of time or at the hackathon upon arrival.

Bring Your Own Team (BYOT)

Decided to attend a hackathon with your best friends? This approach works well because teams are already familiar with their members’ weaknesses, strengths, and personalities. However, it can introduce extra drama — working on an intense project into the wee hours of the night can severely test friendships.

Here is some advice if you are planning on coming with a pre-formed team:

1. Talk through your expectations ahead of time: You may think everyone is on the same page — you may be wrong. Are you making an Android app? Is the priority winning or participating in workshops at the event?
2. Assign a team leader or divide responsibilities: Many teams find that this approach works well in order to create a clear division of duties. Who will handle the Devpost submission? Who will present? Not all teams need to fulfill these roles but discussing them can prevent unnecessary hurt feelings.
3. Team size matters: If your friend group is too big, don’t be afraid to suggest splitting — you can still hang out! If the group is too small don’t hesitate to bring in a ringer or two . This can be a great way to both get a fresh perspective and integrate a new person into the hackathon community!

Remember that you don’t need to work with the people you know. If you feel awkward, suggest splitting into several groups so you can branch out and make the most of your experiences. Keep in mind that it can be hard to work with friends and very beneficial to try out your skills with a new group of people and fresh perspectives.

Team-searching: Party of 1

Don’t have a group? No problem. Many hackathons provide team-forming aids like a Slack channel or Facebook group. If they don’t have one, don’t be afraid to suggest it! This can be a great way to scope out potential ideas. Here is our general advice for on the spot team formation:

1. Don’t be shy: Approaching a random group of people can be scary. But most teams are very open to taking on an outsider.
2. It’s okay to specialize: Most teams can use a generalist willing to work on whatever is necessary, but someone with expertise on design, backend work, or something else more specific is also valuable. If you’re looking for a specific role, make that clear. And don’t settle — if you want to learn a specific skill don’t stop until you find a team where you can do that. Post on Slack and walk around at the event. Be open about looking for a particular piece of the pie so that you and the team can benefit each other.
3. Piece by piece vs. joining a team: In general you can try to join an existing team or start by joining one person and gradually accumulating members. Both work well, but the second strategy is more well suited towards team-forming environments at a typical hackathon.

Ideation

Teams often feel pressured to create The Next Facebook and get too wrapped up in this self-imposed pressure during ideation phases. Keep it simple.

Step number 1: Think about what you are interested in building: Is it a game? An app? A website? Start with the technologies you like best or are working on improving and then go from there.

Step number 2: Think about your collective interests. Do you all love sports or eating healthy? Is there a member of the group with an interesting background (like a minor in biology)?

Step number 3: Think of things that you need. Teams often get stuck trying to find ideas for something that everyone will use. The reality is that if everyone needed it, someone is probably already working on it or has already made it anyway. Unless you are redesigning Facebook as an exercise (which can be fun but not a big judge pleaser) stick to things that you personally would use. Coach Nick Engmann recommends “Keep a notebook with you, or notes on your phone. Note ideas around during your day to day, about things that would be helpful to you or would just be fun to make.”

Don’t sweat ideation too much. Although it may seem big, even seemingly low quality ideas often have more complexity than can initially be seen. Start somewhere and welcome whatever pivoting opportunities are introduced.

Coach Sharon Lin recommends “Hackathons are the best places to test out crazy ideas with others who are crazy enough to try them out with you. Whether it’s a pancake flipping robot, a smart coffee maker, or a web app that texts you when there’s free food nearby, try to think of cool things you’d never typically build in a classroom setting.”

Planning

Now that you have an idea, time to get down to brass tacks. Planning is hard and even the savviest software experts out there often struggle to create accurate estimates for how long something will take. The most important thing is to try. The only planning method that we know never works is just “not planning.”

Draw it out

Coach Nick Walsh recommends “It’s easy to get caught up in what functions your product will have, but drawing out potential screens of a mobile app, pages for a web site, schematics for hardware, or a schema for a database will all help you stay focused and keep on track for delivering on your goals by the end of the event.”

Split responsibilities

Begin by dividing up the general tasks. If you formed your team based on who wants to work on each component, this step will be easier. If not, it’s still totally doable. Start by agreeing that it is possible not all of you will get your first choice. You will likely end up working across the stack anyway. Hackathons require some flexibility from all team members. Keep discussing until you come to a division everyone is comfortable with — no one is less motivated than someone who is working on something they really don’t like in the first place. Make sure the whole team is on board!

Have goals or checkpoints

Create times when you expect to have a particular feature done. These can be as vague as “Front end finished by Saturday morning” or as detailed as “Implement parsing of sound waves by 3 PM today.” Regardless of your different styles, you should have some broad goals to guide your team and help unblock each other if one part ends up taking longer than expected (which it always does). The best part of planning is that it will keep you focused and prevent needless time-wasting on subjects like “who is implementing the login functionality?”

Pivoting

Pivoting can be a very successful strategy at hackathons. Jeremiah, Tim, and Kyle from Embry-Riddle Aeronautical University participated in a competition by Thales Group, which is a multinational defense company. The team spent 2 careful weeks planning and creating a project submission for the contest involving laser communications for satellites. The night of the submission deadline, disaster struck. The diodes the team was using had burned out. The team rallied and was forced to quickly change directions and worked 6 straight hours to put in a submission and create a video. In the end they miraculously pulled it off and managed to advance to the final rounds and go on to win the international competition! Moral of the story? Some of the best work can happen directly under the nose of a deadline.

If you do decide to pivot, try and salvage some of the work you’ve done. This is heavily dependent on why you are switching direction.

Here are three common cases:

Case 1.You changed your mind on the idea

Did you realize that your idea isn’t as awesome as it initially seemed? Do you have a structure for a messaging application that you meant to use to connect dog-walkers? You can salvage much of your work to turn it around and make a messaging service for rescue victims.

Ask yourself: What is the most general description of what we have built so far?

Then brainstorm: How could we use this technology for other use cases?

Here are a few examples:

• A chrome extension for blocking profanities from a page could be used to highlight relevant information for someone who wants to read something quickly
• A messaging application to facilitate communication between firemen could be used to help employees at the same company instead
• An Android application designed to catalog someone’s fridge items could be converted into a tool for an artist who wants to remember what supplies she has in her studio

There are no bad ideas — come up with several and then choose.

Case 2. Your code no longer works as expected, but you think you can salvage it.

In an early stage it will often be easier to change directions entirely (think: I realized I hate Android studio). Later on, you can dial back carefully (think: using the part of your app that logs location to give periodic notifications but ditching the interactive map component).

Case 3. You changed your mind on the format.

Likely the hardest option, it may be difficult to keep your idea and change the way it works altogether. If possible, consider using what you built for another purpose (see step 1). If not, there are some creative workarounds. Did you decide you want something you can use on your phone and not a web application? See if you can still use your backend services.

It’s Demo Time!

Everyone should do a demo run through. Even if your application is Broken with a capital ‘B,’ set aside some time to demo. If your project is 100% flawless and you all know it inside out, still set aside some time.

Coach Nick Walsh recommends: “Be sure make a sacrifice or two to appease the ‘demo gods’, as no matter how many times you test something, there is always a chance that it will miraculously malfunction when it comes time for demos. Seriously though, try to test on the same computer/environment that you will be using to demo, as it will ensure consistency of experience and reliability.”

Teams generally fall into 3 big pitfalls when doing a demo:

1. Problems with setup: Ask the organizers or your MLH rep if you can connect your own machine during demos. Make sure they will supply the right connectors.
2. Problems with execution: Make sure the parts of your project you want to demo work! Run through it at least twice. If it doesn’t all work, show the parts that do.
3. Not leaving enough time to go through the project. Although it is interesting to hear your goals and experience, focus on the demo. People are insanely visual, so this should be your priority. Talk through your project while demoing how it works and IF YOU HAVE TIME AFTER get to your motivations / setbacks / etc. Too many teams spend their time talking about these pieces and have to rush through their demo at the end. Don’t let this be you, and don’t worry about focusing on features that aren’t core to your project, like how someone might register for an account.

At the end of the day…

The most important part of attending a hackathon is getting there — that’s it. Just by participating in a hackathon you are guaranteed to learn something (and very likely to eat something delicious too). Here’s a top 3/TLDR:

1. Come in with an open mind
2. Don’t be afraid to change directions
3. Even if it didn’t totally work out, go ahead and demo!