Hackathons – Impacting People, Organizations and Technology

With the lessons learned from the first hackathon we organized another one months later. This time around we were focused on improving the event instead of building it from the ground up. This second edition of the hackathon felt as madness once again albeit a refined madness in my eyes. It took a few more years for me to switch places and get on the participating end of things.

Being a Participant

In the span of just a few months there were 2 internal hackathons organized in Documaster. The idea behind both was to focus and work on technologically centered ideas for improving our components. While the overall premise of the company hackathons felt distant to the ones we used to organize at university, the atmosphere was not at all that far off.

We had less than 48 hours to work on a proof-of-concept solutions and present them in front of the whole office in Bulgaria. Most of the ideas worked upon were topics of discussion for months, but the time was never right for someone to start the research and development on them. That was the most significant reason why so many of us could not wait for the event. Some of the ideas concerned optimizing our development flow and internal tooling, some were about new user-facing features, some other were about introducing new types of testing for the product.

I personally worked on the matter of “dockerizing” our major components for the first hackathon with one other colleague. At first, we were optimistic about the scale of the task given the time for the hackathon. We already had some docker configurations that ran monolithically so our main task was to split that up rather than develop things from complete scratch. Of course, once the actual development started, we did hit many issues along the way – we had to come up with a technique for the components to properly await each other in the final starting phase, we had to resolve VPN issues and decide on what’s the right default state for the components so they can be utilized by as many people as possible. While the task wasn’t finished in time for the hackathon finale, it encouraged us to continue working on it throughout the coming weeks. 

At the end of the company hackathons every team was a winner – everybody developed something exciting for them, brought some value and a positive impact to the organization and possibly the end clients. Other hackathons, however, must select their official winning teams who had managed to persuade the jury in the excellence of their execution, idea, implementation and presentation.

Being a Jury Member

I was invited to be part of the jury for the latest edition of the hackathon that started it all, it was time for HackAUBG 4.0. It’s the position with the shortest lifespan – just a few hours. It’s also the position with the most well-defined responsibilities - there’s little space to do anything out of line. Yet again it is a challenge for which you can and should prepare. The way I tackled it was by asking for advice one of the experienced members of the jury from the previous editions of HackAUBG. His number one advice was to take detailed notes during the presentations. Equipped with them I was able to bring up valid points for defending the teams I sided with in front of the other jury members.

Besides personal notetaking, it was crucial that we as a jury worked as a cohesive team during the Q&A minutes of the presentation slots. Fortunately for us, the organizing team brought us together well beforehand to give us the time to agree on some basic rulesets. It helped us clear out the way we would sync effectively in real time when it was our turn to ask questions to the teams – our most significant job that should be executed with as few hiccups as possible.

The major criteria on which we graded the teams’ accomplishments were the complexity of their solutions, the degree to which they were developed during the event, the originality of their ideas and their presentation performance. These general categories were further divided into smaller subtopics for assessment which helped me with the judging process. The greatest challenge while evaluating the presentations was the constant need to multitask between thinking about it and remaining present in the auditorium, listening to what’s happening.

After announcing the winning teams and the hackathon officially came to its end I was put on the other side of the fence. Almost every team was eager to hear some feedback on its performance, they asked questions about the areas they needed to improve, what we did not approve of as jury and so on. One more occasion on which the detailed notetaking came in handy.

While this was my first and only experience in the shoes of a jury member, what made the hackathon count for me was the simple realization of seeing all the passionate organizers, participants, mentors and partners in the same place years after the event was originally born.

No matter what role you come to play in a hackathon you are bound to be involved in an adventure full of exchanging ideas, building up human relationships, applying and learning more about cutting-edge technology, arriving at unexpected results.