A Guide to Participating in Your First Hackathon

Recently we put together a guide for how large organizations can host successful hackathons. Next, we’re going to draw from our Air Liquide hackathon experience (which was actually my first hackathon) and cover what first-time hackathon participants should be aware of.

Prepare

If the hackathon you’re participating in has any sort of preliminary information session, do what you can to attend it. If that’s not an option, most hackathons have useful, informative websites that will lay out the objective, what you need to bring, what will be provided, etc.

Get Your Gear in Order

Laptop? Check. Mobile device? Check. Chargers and power cords? Check and check. You get the idea: Make sure you have everything you need to hack for hours.

Arrive Early

Arriving as early as possible gives you time to set up and settle in. It’s also an opportunity to eat and get that first mandatory cup of coffee. But perhaps most importantly, arriving early gives you time to network and chat with people. This is especially useful if you’re a free agent looking to join a team or are part of a team that has a vacancy.

Take Advantage of On-Site Expert Mentors

In our How to Host a Hackathon post, we talked about how important it is for hosts to provide on-site mentors. Not every hackathon will have them but if they do, take full advantage of them. They’ll impart industry knowledge that you don’t have that will have a huge impact on what you and your team design. At the Air Liquide hackathon, we talked to a variety of mentors for upwards of three hours. That amounted to three hours we weren’t designing, coding or pitch crafting, but it was totally worth it. They helped us map out the core problems and allowed us to focus our solutions. In fact, later in the day, they actually validated our understanding and our solutions and ensured that we were on the right track.

Divvy Up Responsibilities

It’s important that everyone on your team knows their role and what to focus on. Having clear goals will help everyone stay on track, and prevent the need to manage people throughout the process. Usually, hackathon teams range from 2-5 individuals.

arcweb-hackathon-win

 

Select a Speaker

While code and design is a big part of any hackathon, the results of all your hard work will go unnoticed if your pitch isn’t polished. That’s why teams should choose their speaker wisely—and early. Doing so will get them comfortable in the role and provide ample practice time.

Practice, Practice, Practice (And Be Humble)

Most hackathons will give you the ability to practice your pitch in front of mentors. If you get this opportunity, TAKE IT! You’ll be making your final pitch to people that have seen literally hundreds of pitches so there’s no reason for you to pass on practice runs.

Towards the end of Day One of the Air Liquide hackathon we had the opportunity to do a practice run. We were very cocky going into it. We had spoken to the experts, had some great designs, functional code, and a solid keynote. We were ready. We presented a practice run and waited for the applause.

It never came.

What we got instead were a ton of questions. Why mobile? Why are your features important? What problem are you trying to solve? Why? Why? Why? Why? We got stark feedback too. I don’t get it. So what. Your message is not clear. I don’t care about this.

Harsh, right? Before our practice run, we had already declared ourselves the winners. And then we got shot down, punched in the gut, left out in the rain. You should expect this—and you should learn from it. This was single-handedly the moment that turned everything around for our team. We accepted the critique. We dissected and analyzed it and them most importantly, we applied it.

Bottom line: make changes. If the critique comes from an expert, don’t be above it. You’re team/idea/pitch/code isn’t going to be polished which means it can be better. Listen and learn from the on-site experts. You won’t regret it.

The InVision Impact

Aside from the deck, we knew a prototype was critical. This would back up all of the bold claims we had made with a tangible artifact that we could show, and even pass around to the judges. Through InVision’s suite of incredible tools, we were able to not only put together a clickable prototype with a shareable link, but we were also able to push it to several phones for an even more realistic experience. Because we were pitching a mobile app, the act of seeing something functional on a device really got the judges attention. We know the moment they saw it, their minds envisioned happy customers and future profits. So come armed with the suite of tools and applications you think you’ll need to make your idea as close to a reality as possible.

Plan A, Plan B, Plan Oh Sh—!

One other nugget of enlightenment that the mentors bestowed upon us is to have a solid backup plan—or three. Something will go wrong so be prepared. Planning a live demo? Have a video as a backup. Keynote crashed? Expect to be able talk through your pitch without visuals. Phone dies mid-demo? Make sure your app is on multiple devices. So many great pitches have been ruined by unexpected circumstances. Plan for them, don’t be frazzled, and roll with the punches. Your pitch will be that much better if nothing goes wrong.

Code Freeze

Inevitably your hackathon will come to a close and you must be done with all of the work. Monitor your time closely and the code freeze will not sneak up on you. Lose track and you will be unprepared and in trouble. Take this time to practice more, since just sitting around waiting for your pitch time will be brutal.

Sell Your Heart Out

When it comes time to pitch, crush it. Sell your heart out. Speak with confidence,. Convince the judges they would be stupid not to pursue your app or concept. Set up the problems you are trying to solve, then knock them down with your amazing solutions.

Here’s how we went about our pitch…

First, we explained the problem. We used specific examples of pain points and customer quotes. We were stern but, lighthearted. (A strategically placed, Simpsons GIF representing a confused customer, can ease the tension in the room as well as humanize and illustrate the pain points you are trying to tackle.)

Next, we presented our solution by answering how our app would address the specific pain points we had just identified. We then explained the benefits and showed the audience why our solution would be valuable to the user.

Then we demoed what we built. We illustrated our solution’s ease-of-use and how it would solve the customer’s challenges. We developed a clickable prototype too to give the judges something tangible to experience. (Side note: If your solution is mobile, present it on a proper device. Emulating a phone on your computer screen has much less impact.

Finally, we thanked the judges. This sounds like common sense, but it matters. Make eye contact, shake their hands. Make an impact and they will remember you.

The Results Are In

If you followed the steps outlined here you are well on your way to being victorious during your next hackathon. If you approach the solutions smartly, work hard and give a great pitch, you’ve already won. You may not “win” the day, but you should be proud of yourself and your team. And there’s also a good chance you’ll have learned a ton that you can take back to your job, colleagues and clients.

Good luck out there!

Share this post:
Like what you see? Get more like this in your inbox.