How to tackle your next GenAI Hackathon
A few months ago I was given the opportunity to participate in a Hackathon Learning Challenge, focused on how can we use Generative AI to tackle different challenging scenarios in the Software Development Lifecycle.
The hackathon was beautifully organized, with materials and setup already well-prepared for the participants so they can properly focus on leveraging the power of GenAI while also testing its limitations. And even with really well pre-defined materials and documentation, the challenge still proved quite difficult without a proper strategy.
Allow me to share with you how together with my team we managed to reach a successful solution and learn a lot in the process.
Disclaimer : This post shares my personal experience and strategy while participating at that hackathon and how our team’s approach helped us achieve a successful result and presenting an impressive solution on the last day. It is just a personal reflection on the experience and I am hoping it can help other AI enthusiasts tackle GenAI related challenges, hackathons or even normal Software Development problems in general.
The Hackathon had different possible problem scenarios we could tackle, each team could chose one by preference. The interest part about it was that the teams weren’t really meant to compete against each other, instead we were competing against ourselves, with the goal to explore and learn about the possibilities and limitations of GenAI, and to see if an efficient solution is possible for the problem scenarios suggested by the organizing team.
The problem scenario my team tackled was the following :
“ Your task is to develop a system that hooks to a Git repository and, upon each commit, automatically generates unit tests for the changes introduced. These tests should then be executed automatically, with reports on the outcomes provided to the developers.“
I think it is quite obvious from the problem scenario that we are tackling not only a simple coding task, but an integration of different ends of the stack. From the infrastructure part of working with git hooks and pipelines; the unit testing generation and validation; and to the API usage of the GenAI tools, you can clearly understand that quite a lot of different technical knowledge and applicability would need to be involved. Therefore, a good strategy and a clever way of leveraging not just the GenAI tools, but also the qualities of every member of our team was vital to the success of our challenge.
To better understand our approach, I have divided it into the logical steps through which it was achieved.
The most difficult task usually at a hackathon or any coding challenge is figuring out how to get started.
1. Getting started
When you read the problem statement it is quite clear the direction where you think you want to end up in, but it can be very confusing how do you reach that goal? There are these common questions that arise all the time especially when you are on a team with completely new people. Like for example: where do we start from, how do we reach the solution that is expected from us?
And the first thing that you can do, and which is more important than any other step in this list, is to get to know your teammates!
Go through a short introductory round where everyone can just summarize a few aspects that are critical to how you will work together as a team :
- what is your technical background?
- what is your knowledge on the topic required for the hackathon/challenge?
- what is your experience with hackathons/challenges?
- what are your hobbies?
You might ask yourself why is a question about hobbies important in this context?
Well, the answer is quite obvious : the social and informal aspect of the question already helps you breach a few of the professional co-working barriers and create a better cohesion within team. And at the same time, you might even catch some hints about the character and the working behavior of one person.
Whereas the other three questions will help you determine a better distribution of roles and tasks between the team members later on.
After you got to know each other a bit, focus on the technical and organizational aspects of the challenge.
- Did everyone perform the setup required for the challenge?
- Did everyone go through the materials provided by the organizing team?
- Is anyone fully available for the challenge during the whole time period?
Discussing and agreeing to these aspects will help you create a shared knowledgebase within team and make sure that everyone is on the same page and no one is gonna be left out when the coding gets serious.
No matter how technical or fancy a hackathon/coding challenge is, always remember that it is a team challenge, and the social aspect of it is the key factor for your success!
2. Brainstorming
For some the most fun part, for some the most stressful, brainstorming is the most crucial technical part of a hackathon because this is the moment where you set up the parameters of your solution.
It can be really fun to discuss ideas and to hear different perspectives about a topic that other like-minded people are as passionate about it as you… but it can also be very stressfully if your ideas keep clashing on one another, or you simply feel like you are hypothesizing too much and not really materializing anything into concrete decisions.
How does one explore the boundaries of creativity without deviating too much from the limitations of the task at hand?
The answer is simple : Start small, and grow from there.
Imagination, creativity, passion… they can all drive you towards impressive solutions that you know would really take the edge of the competition. But you have to remember that you also have a deadline, and your goal is to have a working solution by the end of that deadline.
Think of it like this, if you design a majestic and impressive solution that realistically cannot be fully developed in the given timeframe, or the margin for errors is simply too small to cover your risks, then you have a high chance of not being able to touch all the points you designed and in the end it will look like an unfinished solution. Or to use a more natural comparison, imagine a huge majestic tree that is missing a lot of leaves, or maybe even branches.
Whereas, if you try to start small, and first design a first prototype, and then also plan what would be the next expansion of your prototype, how will it integrate as a feature, and not as a fix, you will deliver a solution that will more clean in the end. To use the same natural comparison standards, this time you have built a clean-looking tree, of a perhaps considerably smaller size, but with a lot of potential to grow.
Which of the two trees do you think would be more appealing to the gardener?
3. Iterate
Having in mind the growth perspective we just discussed in the previous chapter, think of how you iterate not only the prototypes through which your solution will go till the deadline, but also the steps of implementing your solution.
Let’s talk about these points separately:
First of all, the prototypes iteration :
- Consider having at least 3 different releases of your solution, let’s call them alpha, beta and gamma.
- Define how your solution will look in these 3 different releases and how the other releases will expand on to it. This step is important not only for your hackathon, but also for the future of the solution after the hackathon.
- Think of each prototype as a version of your solution that you should be able to present if the hackathon is over. And this way you will also handle the pressure of the time constraint to deliver before the deadline.
Secondly, the implementation steps iteration :
- The easiest way would be to go in sync with the prototypes iteration you have set for your solution, but it is highly likely that you would need a lot more intermediate steps within the implementation of one prototype.
- Try to analyze how many touch points you need with the full-team together within one prototype iteration. You don’t wanna over discuss things, you wanna get things done. But at the same time, you have to keep all individual features in sync and be able to adapt on the move in case something doesn’t work as expected.
- Don’t be afraid to completely change your team’s methodology from one iteration to the other. Maybe it just didn’t feel right and part of the team was not efficient while the other was stacking lines of code. Or maybe things were going well but you also wanted to touch the other end of the stack.
Remember : At the end of the day, the prize is the least important part of a hackathon. It is the learning process and the experience that truly stays with you after all of it is done.
4. Deliver
No matter if you’ve gone through the hackathon by applying the approach I mentioned or a completely different one, at the end of the day you will still have to deliver a solution as a culmination of the work you have put together through the challenge.
So what would be the best way to make sure you present the best out of your solution and show its potential to the maximum?
The answer we came up is actually asking more questions.
We came up with quite an interesting way of questioning our own solution, and basically forming the presentation based on the answers to a few questions that will not only explain how we’ve implemented the solution, but also how it meets the requirements criteria and what its potential is.
So, my suggestion is, when you’re gonna start thinking of how to present your solution, try to answer the following questions:
- What was the problem statement that your solution is trying to solve and how does it solve it?
- Were you successful in solving the problem? If the answer is not a 100% yes, then what were the limitations?
- What does the architecture of your solution look like and how did the team divide the work?
- What are the next steps for your solution?
These are just the tip of the iceberg but they should give you a good idea of how to show the value of your solution, or maybe even just to analyze if you have a viable solution or not. They are basically retrospective feedback questions that can help you well understand the work you’ve put in the challenge. Treat them seriously and in detail and you might just get the best out of your work.
Conclusion
A hackathon is one of the best and most fruitful learning experiences in the life of an IT enthusiast. No matter what approach you take in the challenge, you’ll still have more to gain even by just being there than by not participating or doing an online course at home.
If you read this article because you wanna participate in a hackathon soon and you’re not sure how to tackle it, or if you’ve done it numerous times before and you were just curious about my approach, my message is the same to you and it is quite simple :
Go out there, challenge yourself, work together with other people because that is the beauty of the challenge and the biggest growth process you can have not just professionally, but also personally.
I like to believe that we seed a bit of our personalities into the solutions we design. So the more we challenge ourselves together and the more we embrace collective moral principles as teamwork, trust and respect, the brighter our future will look and the more positive we will be while stepping forward into the next era of IT.
