Three Hacks to Nail Your First Hackathon

From what I’ve seen, signing up for a hackathon without a clear understanding of the challenges that can come up often leaves entry-level developers, in particular, feeling intimidated or disappointed. This happened to me, but, after having attended several hackathons, I’ve learned how to approach these challenges with an open mind and handle them effectively.

I remember the first time I attended a hackathon. In my mind, a hackathon was a place where professional hackers got together and hacked other people’s computers. “This is going to be fun,” I thought to myself. I reached out to a few people I knew who had been to hackathons before to find out more, BUT they only told me about the nice things, such as the networking opportunities, cash prizes and of course, the food.

When I got there, though, it was overwhelming. My team hadn’t figured out how to work well together, and we ran into lots of problems that were very obvious when we got to the first round of presentations and had nothing to demo. I even broke down at some point because everything was just going wrong.I wanted to quit and go home. It wasn’t as fun as I had imagined it to be, and I felt so intimidated by the other teams who seemed to have everything all figured out. Luckily, we managed to get it together at the last minute and used the experience as a lesson that all of us took forward.

Now, having attended more hackathons, and working in a mentoring role, I would like to see younger developers treating hackathons as a learning process that they can have fun with and grow from. To do this, I have found that doing these things will help make hackathons a more valuable experience:

• Being upfront with your teammates about your ability
• Making use of Agile practices throughout the process
• Selling your product with confidence

Be upfront with your teammates about your ability

A hackathon is a coding challenge or competition where developers and designers get together and build digital applications. This means that people with many different skill sets have to get together and work in a group to produce a final product. The hackathon usually lasts for 24 - 48 hours, and with only a short amount of time, teams are up against a lot of pressure, and with no time to sleep, it can get overwhelming very quickly.

For this reason, I’ve learned that it’s important to be upfront with people about how much you know and how you can most effectively contribute to a team in the limited amount of time that you have.

Honesty builds trust and transparency in a team. Don’t be scared to admit that you don’t know something, because you won’t know everything.

At my first hackathon, I had very little coding experience and felt scared to admit that to my group. I fumbled through the task I was given and the more I realised I didn’t know what I was doing, the more I panicked and the less work I actually got done. After our disastrous presentation, I realised that it’s okay to ask questions if you are not sure. People are more willing to help than you might think – it just takes the courage to reach out and ask. When I feel nervous about doing this, I remind myself there’s no such thing as a stupid question, only stupid answers. 😉

Another thing that I’ve learned is that hackathons provide you with great networking opportunities. By being honest and showing that you want to learn from others, you set yourself up in such a way that people want to collaborate with you not only on the day, but potentially in the future too.

Make use of Agile practices throughout the process

At my first hackathon, I wish we had used Agile practices to help us have a clearer vision of what we were doing. Because we hadn’t communicated effectively from the start, we didn’t work out a clear process and tasks were assigned kind of randomly.

Now, when I go to hackathons, I make sure that we follow certain Agile processes to work through our project as effectively as possible. Some of these include:

Using a kanban board to track each other’s progress: The khanban has a list of tasks that tracks what each person has to do, what they are working on and what they have completed. This is great for visibility and maintaining focus during the tight timeline we have to work with.

Working with pair programming: This is where two people work together on one task on the same computer – for example, one person will write code, while the other one looks out for bugs. As they always say ‘two is better than one’, and this is especially true at hackathons where it’s easy to get overwhelmed and not think clearly.

Having regular standups: While it might seem like a waste of precious time, checking in to discuss which tasks have been completed, what still needs to be done and the struggles that each person is facing is great to see where we can help each other get to solutions quicker. If we can’t solve a certain problem as a team, we know we can reach out to the mentors at the hackathon who are there to help out.

Doing a retrospection: After the hackathon, I’ve found it useful to do a retrospection. This gives us the opportunity to talk about what we did well, what we liked and disliked, and what we could do better at the next hackathon. In my experience, these sessions really help to consolidate learnings, and make me feel more confident.

Sell your product with confidence

I’ve learned that another major part of hackathons is understanding how to think about the product that you are building in a business context. How would it be used, who would it be used by and how would you sell it? Each group then has to prepare a pitch presentation of their product to do in front of everybody. These presentations are done throughout the hackathon, and can be very scary if you don’t approach them with the right mindset.

At my first hackathon, during the midnight presentations, my team had nothing to demo. ‘Who will stand in front and present a solution that is not even half-done?’ – this was the question. We looked at each other skeptically, pointing fingers and arguing. Nobody in my team wanted to go to the front. We didn’t even have proper presentation slides - IMAGINE!

My heart rate went from zero to hundred real quick when we were called on stage. At that moment, I wanted to hide under the table, but that would be silly because people could still see me. I googled how to disappear quickly, but I couldn’t find anything useful on Google. The only solution to this was to face the bad music.

At the last minute, we decided that we weren’t going to demo the application, but instead present the idea in a way that everybody would be able to understand without seeing the application. This meant that we had to shift our minds out of technical mode and into human mode.

When it was my turn to speak, I reminded myself that I was talking to people, not robots, and if I believed in what I was saying, there was a high chance they would too.

We got through the presentation and people loved it. My key takeaway from this experience? If the application that you are building doesn’t seem to be working out, make sure that the presentation is A1.

Hackathons are very useful for entry-level developers to give them a glimpse into what to expect in the real world. The working world is not about cash prizes or great food, but rather about solving problems that arise on a day-to-day basis. If you approach hackathons with an open mind, you can learn a lot that will help you with everything that you do. Aaand, as a plus, they also look great on your CV as employers can see the cool applications you have developed.

Lihle Menzeleleli is a Web Developer and the Co-founder of BabesGotBytes, a non-profit organisation that is aimed at teaching and empowering females to code.She is currently completing a Java Software Development course at Project CodeX. Lihle is passionate about improving the lives of the youth in South Africa through technology. During her spare time, she volunteers by teaching communities around Cape Town how to code. She believes that we can change the future by educating the next generation.