About a year and a half ago, I started participating in hackathons. During this time, I have taken part in over 20 events of various scales and topics in Moscow, Helsinki, Berlin, Munich, Amsterdam, Zurich, and Paris. In all these events, I was involved in data analysis in one form or another. I enjoy visiting new cities, making new connections, coming up with fresh ideas, implementing old concepts in a short period, and the adrenaline rush during presentations and announcing results.
This post is the first of three on the topic of hackathons, where I will explain what hackathons are and why you should start participating in them. The second post will cover the dark side of these events — how organizers made mistakes during the events and the consequences of those mistakes. The third post will address frequently asked questions about hackathon-related topics.
What is a hackathon?
A hackathon is an event that takes place over several days, aimed at solving a specific problem. Typically, there are several problems presented at a hackathon, each represented as a separate track. The sponsoring company provides a description of the task, success metrics (metrics may be subjective, such as 'novelty and creativity,' or objective — accuracy of classification on a held-out dataset), and resources to achieve success (company API, datasets, hardware). Participants must formulate the problem, propose a solution, and demonstrate a prototype of their product within the allotted time. The best solutions receive prizes from the company and opportunities for further collaboration.
Stages of a hackathon
After the tasks are announced, the hackathon participants form teams: each "lone wolf" gets the microphone to discuss their chosen task, share their experience, present their idea, and specify what kind of specialists they need for implementation. Sometimes a team can consist of just one person who is capable of handling the entire project independently at a sufficiently high level. This is relevant for data analysis hackathons, but often it is prohibited or undesirable for product-oriented events—the organizers aim for further development of the project, but within a company; a formed team has several advantages over participants who wish to create a product alone. An optimal team usually consists of 4 people and includes: a frontend developer, a backend developer, a data scientist, and a business person. By the way, the distinction between data science and product hackathons is quite simple—if there is a dataset with clear metrics and a leaderboard or if the victory can be achieved with code in a Jupyter notebook, it’s a data science hackathon; anything else that requires creating an application, website, or something engaging is considered product-related.
Typically, the project kickoff occurs at 9 PM on Friday, and the deadline is set for 10 AM on Sunday. Some of this time needs to be allocated for sleep (not sleeping and coding is a sure path to failure; I’ve tested it), which means the participants don’t have much time to create something of quality. To assist participants, representatives from the company and mentors are present at the venue.
Work on the project begins with discussions with company representatives, as they have a better understanding of the task's specifics, metrics, and they will most likely judge your work at the end. The purpose of this communication is to identify the most relevant directions and focus your attention and time on what matters most.
At one hackathon, the task of regression was set using a dataset with tabular data and images, with a clear metric — RMSE. After speaking with the data scientist from the company, I realized that they needed classification, not regression, but someone from management decided this task was best approached that way. However, they needed classification not to achieve an increase in monetary metrics, but to understand which parameters are most important in decision-making, and then to process them manually. Thus, the initial task (regression with RMSE) shifted to classification; the evaluation priority changed from the achieved accuracy to the ability to explain the result. This, in turn, ruled out the possibility of using stacking and black box algorithms. Such a dialogue saved me a lot of time and increased my chances of winning.
Once you understand what you need to do, the actual work on the project begins. You must establish check points — deadlines by which the tasks must be completed; meanwhile, it’s good to continue communicating with mentors — representatives from the company and technical specialists — as this is useful for adjusting the path of your project. A fresh perspective on the problem can suggest an interesting solution.
Since hackathons involve many newcomers, it is good practice for organizers to conduct lectures and workshops. Usually, there are three lectures — on how to present your idea as a product, a technical lecture (for instance, on using open APIs in machine learning, so you don't have to write your speech-to-text in two days but can use ready-made solutions), and a pitch lecture (on how to present your product, how to properly gesture on stage so that the audience is engaged). There are various activities to energize the participants — yoga sessions, table football, tennis, or gaming.
On Sunday morning, you need to present your work results to the jury. At good hackathons, everything starts with technical expertise — does what you claim actually work? The goal of this check is to weed out teams with flashy presentations and buzzwords, but no product, from those who have actually created something. Unfortunately, not all hackathons have technical expertise present, and there are cases where a team with 12 slides and a mindset of '... blockchain, quantum computing, and here AI will finish it...' wins first place. Such precedents are rare, but since they are remembered best, many think that a good presentation is 99% of winning at a hackathon. The presentation is indeed important, but its contribution is no more than 30%.
After the participants' presentations, the jury decides on awarding the winners. This concludes the official part of the hackathon.
Motivation to participate in hackathons
Experience
From the perspective of the experience gained, a hackathon is a unique event. There are not many places in nature where you can realize an idea from scratch in 2 days and receive immediate feedback on your work. During a hackathon, critical thinking, teamwork skills, time management, ability to work under stress, skill in presenting your work results clearly, and presentation skills are all developed. This is why hackathons are an excellent venue for people with theoretical knowledge who wish to gain real experience.
Prizes
Typically, the prize pool for a hackathon is about €1.5k to €10k for first place (in Russia, it ranges from 100,000 to 300,000 rubles). The expected value (EV) of participation can be calculated using a simple formula:
EV = Prize * WinRate + Future_Value - Costs where Prize — the amount of the prize (for simplicity, let's assume there is only one prize);
WinRate — the probability of winning (for a novice team, this value will be capped at 10%, and for a more experienced team, it could be 50% or higher; I have met people who left every hackathon with a prize, but that's more of an exception, and in the long run, their win rate will be lower than 100%);
Future_Value This is a measure that indicates the future benefits of participating in a hackathon: it could be the profit from gained experience, established connections, received information, etc. This value is almost impossible to determine accurately, but it is important to keep it in mind.
Costs Expenses for transportation, accommodation, and other costs.
The decision to participate is made based on comparing the EV of the hackathon with the EV of the activity you would choose if the hackathon did not exist: if you planned to lounge on the couch and pick your nose over the weekend, then participating in the hackathon might be worthwhile; if you prefer to spend time with your parents or girlfriend — bring them to the hackathon (just kidding, decide for yourself); if you wanted to freelance — compare dollar per hour.
Based on my calculations, I can say that in Russia, for an average junior to mid-level data scientist, participating in hackathons is comparable to the monetary gain from a regular workday, but there are nuances (team size, type of hackathon, prize fund, etc.). Overall, hackathons at the moment are not a gold mine, but they can provide a pleasant boost to your personal budget.
Hiring in a company and networking
For a company, a hackathon is one of the ways to hire new employees. It will be much easier for you to demonstrate that you are a competent person and can work effectively at a hackathon than in an interview while drawing a binary tree on a board (which, by the way, does not always reflect what you will actually do as a data scientist, but traditions must be respected). Such a test in 'combat' conditions can replace a trial day.
I got my first job thanks to a hackathon. At the hackathon, I showed that I could squeeze more money from the data, and explained how I planned to do it. I started a project at the hackathon, won it, and then continued the project at the sponsoring company. This was the fourth hackathon in my life.
The opportunity to obtain a unique dataset
This is a very relevant point for data science hackathons, the importance of which is not understood by everyone. Usually, sponsoring companies provide real datasets during the event. This data is private and under NDA, which does not prevent them from showing you a proof of concept on a real dataset, rather than a toy Titanic. In the future, such results will greatly assist you in getting hired by that company or a competing company, or in justifying similar projects. Agree that, other things being equal, having completed projects that have been positively evaluated is better than having none. Overall, such implemented projects play a similar role to medals and statuses on Kaggle, but their value is more apparent in the industry.
Tips
Generally, working at a hackathon is quite a varied experience, and it’s hard to formulate a specific list of rules. However, I would like to present a list of observations that can help newcomers:
- Don’t be afraid to attend hackathons even if you lack experience or a team. Think about how you could be useful. For instance, do you have an interesting idea or a strong understanding of a particular field? You can leverage your domain knowledge when formulating the problem and identify non-trivial solutions. Or perhaps you excel at Googling? Your skill can save a lot of time if you can find existing implementations on GitHub. Or are you very proficient at tuning lightgbm parameters? In that case, don’t attend a hackathon; prove it in Kaggle competitions.
- Tactics are more important than maneuvers. Your goal at the hackathon is to solve a problem. Sometimes, to solve a problem, you need to identify it first. Ensure that the problem you have identified is indeed relevant to the company. Check the alignment of your solution with the problem; ask yourself about the optimality of your solution. When assessing your solution, first and foremost, they will look at the relevance of the problem and the adequacy of the proposed solution. The architecture of your neural network or how many Kaggle ranks you achieved will interest very few.
- Attend as many hackathons as possible, but don’t hesitate to leave poorly organized events.
- Add the results of your work at hackathons to your resume and don't hesitate to write about them publicly.
The Essence of Hackathons. Briefly
Source: habr.com
