5 Things I Learned From My First Hackathon

The company I work for recently hosted it’s first Hackathon ever, which also happened to be the first hackathon I’ve ever participated in. For those of you asking yourself, what the heck is a hackathon? I’ll tell you.

A Hackathon is usually a technology-based, organized event that gathers developers, engineers, and designers together to develop a web concept in a set amount of time, usually 1 – 2 days. Dave Fontenot describes it best when he says, “Hackathons provide a venue for self expression and creativity through technology. People with technical backgrounds come together, form teams around a problem or idea, and collaboratively code a unique solution from scratch. These generally take shape in the form of websites mobile apps and robots.”

My company’s hackathon was comprised of six different teams, who all had three themes to choose a project from and complete that project within two days. At the end of the second day your team had to present your project to the judges.


I would be lying if I said I wasn’t a little intimidated. Would I be able to keep up with the lead developers or would I slow my team down if they went with a language I’m not fully versed in? This is where my first lesson came to the fore.

1. Don’t hesitate – just do it

It’s natural to feel anxious about any new experience, but that should never stop you from trying something new. When I joined my team that morning we immediately dove into brainstorming different concepts. We finally picked one that we all were excited about and – maybe more importantly – felt we could finish in 2 days.

Everyone was given the chance to voice a concept or idea – no matter how vague and we quickly voted on one we all felt we could complete and one that we felt would wow the judges.

That being said, I wasn’t the only one who was nervous about being the weak-link on the team. But if I’ve learned anything it’s that you should never underestimate people in a competition.

2. Everyone can contribute something unique


This seems like an obvious, if not sentimental statement, but it’s really true. Our team was comprised of four Front-End Developers, 2 leads and 2 juniors and one QA Engineer. Our QA Engineer didn’t think he knew enough code to contribute to the structure and building of our concept. Despite all that the moment we took off with our concept he started researching all the benefits that could come from our project in a marketing and business sense.

After we presented our idea at the end of the hackathon several judges came up to our team to compliment our emphasis on business strategy and statistic details in our presentation. All of this is because of one person on our team who was afraid they couldn’t contribute anything. One could argue that he took on the hardest part of the entire project – selling our idea to the judges.

3. It’s all about the presentation


Ok. ok. It’s not all about the presentation – if you don’t have a working prototype even the best presentation won’t win you a hackathon, but it’s pretty crucial.

This is the chance for you to wow the judges with all the different layers of thought you put into why your concept would benefit the sponsors – or in our case – our company. Make sure you don’t get caught up in making a paragraph, bullet-pointed powerpoint presentation. Show graphs, stats and demo your amazing app.

Try to limit yourself to a certain amount of slides – like 5 or less. If you can’t say something in 5 slides or less, you need an editor. Plan to have the experts speak to their sections. Pull in your best communicator to explain any code concepts that might get complicated. But make sure to prep and practice this in your team before going ahead and presenting. In Michael Bleigh’s Five Tips for Hackathon Participants he advocates the presentation preparation: “[d]evelopers like to believe that code can speak for itself, and that’s actually pretty true. However if your hackathon includes a presentation component you must speak for your code, so don’t completely ignore a plan for presenting.” You don’t want to be so technical you bore everyone, but you don’t want to be too vague that you don’t explain how you constructed the concept.

4. Try something new

Our team utilized AngularJS to construct our project and while I’ve used this peripherally, I hadn’t worked with this language in any in-depth way. The hackathon allowed me to have a focused look at how this language works and the developers well-versed in Angular were able to walk me through the components.

I’m not going to claim I’m an expert or even intermediate at Angular from this one interaction – that’s not the point. Because of my experience with Angular at the hackathon I’m now utilizing Codeacademy’s class on AngluarJS to learn more and dive deeper into a language I now feel I can work with.

5. Have fun

With all the competition, stress, and anxiety these hackathons can bring it’s important to take a breath and have fun with your idea. I had a blast working with developers who I don’t work with every day on a concept that was totally outside our normal everyday workload.

Sadly, my team didn’t win, but we had such an amazing time brainstorming, connecting, mocking up UX workflows, developing, testing, and finally presenting our fully formed project in a mere 2 days.

If you have the means, I highly recommend joining your city’s next Hackathon whether you’re a new developer, QA engineer, or designer. There are teams ready and eager to have you and you have so much to learn.

Previous Post


Next Post


Leave a Reply