The final part of the trilogy about hackathons. In I talked about the motivation to participate in such events. it was dedicated to the mistakes of the organizers and their outcomes. The final part will answer questions that didn't fit into the first two parts.
Tell me how you started participating in hackathons.
I was studying in the master's program at Lappeenranta University while simultaneously tackling data analysis competitions. My typical day looked like this: waking up at 8, attending several classes at the university, then competitions and courses until midnight (while waiting for submissions, I watch lectures or read articles). This strict schedule paid off, and I won the data analysis competition MERC-2017 (about which there was even a ). Winning boosted my confidence, and when I accidentally stumbled upon information about the SkinHack 2 hackathon in Moscow, I decided to visit my parents and find out what a hackathon is.
The hackathon turned out to be quite amusing. There were two tracks for data analysis with clear metrics and datasets, with prizes of 100k rubles each. The third track was for application development with a 50k prize, and there were no participants in it. At one point, the organizer said that a window with a button without any functionality could win 50k, because the prize could not remain unpaid. I didn't start learning to program applications (I don't compete in areas where I can easily be 'turned over'), but to me, it was a clear message that the fields in hackathons are not crowded.
At that time, I was solving both data analysis tracks alone. I found a leak in the data that allowed me to get the perfect score, but the leak column was not in the test data I received two hours before the end of the event (by the way, I realized then that having the 'target' column in the training set does not count as a leak). At the same time, the leaderboard opened, my submission without the leak was in third place out of five; there was a significant gap to the first place, so I decided not to waste time and left.
After reflecting on what happened, I found a lot of mistakes (one of my habits is to mentally replay what transpired with a notepad and analyze the errors, their causes, and what could have been changed — such a pleasant legacy of semi-professional poker playing). But one thing was clear — hackathons offer a lot of value, and I absolutely must capitalize on it. After this event, I started monitoring activities and groups, and the next hackathon came up quickly. Then another one, and another…
Why do you participate in hackathons instead of Kaggle?
At the moment, I'm not fond of Kaggle. At a certain skill level, without specific reasons for participating, Kaggle becomes less useful than other activities. I took part a lot before; I guess I managed to somehow 'move on'.
Why hackathons instead of working on your own project?
I like the idea of creating something cool with my own hands at a leisurely pace. The guys from ODS organized for anyone who wants to work on their project over the weekend among like-minded individuals. I think I'll join them soon.
How do you find events?
The main source is hackathon.com (worldwide) and the chat on Telegram (Russia). Plus, announcements of events pop up in ads on social media and LinkedIn. If nothing is found, you can check here: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Do you prepare a solution plan before participating, or does everything get worked out on the go? For example, a week before the hackathon, do you consider: 'We'll need such and such a specialist, I need to start looking'?
If the hackathon is product-oriented — yes, I prepare. A few weeks prior, I come up with what I'll be doing, think about who might be useful, and gather a team of friends or participants from previous hackathons.
Is it really possible to hack a hackathon solo? What should you do if you don't have a team?
Data science hackathons are real (I am a living example), I haven't seen product-related ones, but I also think they exist. Unfortunately, sometimes organizers impose a minimum number of participants for a team. I believe this is due to the fact that not all ‘lone wolves’ make it to the finals (i.e., they simply leave at the first difficulties), and participating in a team does help keep one engaged. Additionally, after the event, it is expected that you will continue working on the project. Having a team makes it easier to refine the project.
Overall, I recommend always participating with a team. If you don’t have your own team, the organizers will always help you find or create one.
How do you manage fatigue during a hackathon?
You are given 2 days to work at a hackathon, which is 48 hours (let's take 48 for simplicity's sake). We subtract time for sleep (16-20 hours), leaving no more than 30. Out of these, realistically only about 8 hours (on average) will be productive work. If you properly organize your activities (sleep, nutrition, fresh air breaks, exercises, mindfulness minutes, effective communication with the team, and switching activities), those deep work hours can be boosted to 12-14. After such work, you will feel exhausted, but it will be a pleasant fatigue. Coding without sleep and breaks, relying on energy drinks, is a recipe for failure.
Do you have your own ready-made pipelines for hackathons? How did they come about, how are they structured (are the .py files organized in folders, each for its own task, etc.) and how can one start creating them?
I don’t use fully prepared solutions from past hackathons in new ones, but I have my own collection of models and pipelines from previous competitions. I don't need to rewrite standard bits from scratch (for example, proper target encoding or a simple network for intent extraction from text), which saves me a lot of time.
Currently it looks like this: for each competition or hackathon, there is its own repo on GitHub, which stores notebooks, scripts, and a small documentation about what’s happening. Additionally, there is a separate repo for various box ‘tricks’ (like proper target encoding with cross-validation). I don’t think this is the most elegant solution, but for now, it works for me.
I would start by organizing all my code into folders and writing brief documentation (explaining why, what, how I did it, and the result).
Is it really possible to prepare an MVP from scratch in such a short time, or are all participants bringing ready-made solutions?
I can only speak about projects related to data science — yes, it is possible. An MVP for me consists of two factors:
- A viable idea presented as a product (i.e., a business canvas is outlined). There should always be a clear understanding of why and for whom we are creating the product. Sometimes, projects with a well-justified plan, but without a prototype, win awards, and this is not surprising. Unfortunately, many participants struggle to detach themselves from the bitterness of defeat and blame their failures on the short-sightedness of the organizers, continuing to build models without knowing for whom, at the next hackathons.
- Some indication that you can actually create this product (application, code, pipeline descriptions).
Sometimes, a team comes to a hackathon with a ready-made solution and tries to 'adapt' it to the task set by the organizers. Such teams are filtered out during technical screening, or only the part they worked on at the event is considered. I haven't seen such teams among the winners, but I think it's still beneficial for them to participate due to future value ().
Are there examples of bringing projects developed during hackathons to production/startup?
Yes. I have had three cases where we brought projects to production. Once by myself, and two times through the efforts of others based on my ideas and the code I wrote at the hackathon. I also know a couple of teams that continued to collaborate with the company as consultants. I don't know the final results, but it's likely that something was completed. I haven't organized startups myself and don't know if anyone else has, although I am sure there are examples.
After participating in many hackathons, what advice would you give yourself if you could go back in time?
- Tactics are more important than maneuvers. Treat every decision as if it were a finished product. An idea, a Jupyter notebook, an algorithm are worthless if it’s unclear who will pay for it.
- Before designing anything, ask yourself not 'what?' but 'why?' and 'how?'. For example, when designing an ML solution, first think about the ideal algorithm: what does it take as input, and how are its predictions used afterward?
- Join the team.
What do they usually serve at hackathons?
Usually, the food at hackathons is not great: pizzas, energy drinks, soda. Almost always, the food is organized in a buffet style (or a serving table) with a huge queue. Food is typically not provided at night, although there was one case at a competition in Paris where they left snacks overnight — chips, donuts, and cola. I can imagine the organizers' thought process: 'So, what do programmers eat? Oh, right! Chips, donuts — that's what they'll have. Let's give them this junk.' The next day, I asked the organizers: 'Guys, could you possibly prepare something else for the night? Maybe some porridge?' After that, they looked at me like I was an idiot. Famous French hospitality.
At good hackathons, food is ordered in boxes, with options for regular, vegetarian, and kosher meals. Plus, a refrigerator with yogurts and muesli is provided for those who want a snack. Tea, coffee, and water are standard. I remember Hack Moscow 2 — they warmly served borscht and cutlets with mashed potatoes in the 1C office cafeteria.
The quality of hackathons, so to speak, depends on the professional background of the organizers (for instance, the best hackathons are organized by consultants)?
The best hackathons were organized by those who had either organized hackathons before or had participated in them. Perhaps this is the only factor that determines the quality of the event.
How do you know you're not a newbie and it's time for a hackathon?
The best time to attend a hackathon was a year ago. The second best time is now. So go for it, make mistakes, and learn — that's normal. Even a neural network — one of humanity's greatest inventions after the wheel and gradient boosting over trees — can't tell a cat from a dog in the first training epoch.
What are the 'red flags' that immediately indicate the event won't be good and it's not worth your time?
- A clear description of what needs to be done (relevant for product hackathons). If you're given a specific task at registration, it might be better to stay home. In my experience, there hasn't been a good hackathon with a clear brief. For comparison: Good — create something related to audio conversation analysis. Bad — develop an app that can separate a conversation into two distinct audio tracks for each person.
- A small prize pool. If you're asked to create a 'Tinder for online shopping with AI' and the first-place prize is 500 euros with a minimum team size of 5 people — you probably shouldn’t waste your time (yes, this is a real hackathon that took place in Munich).
- Lack of data (relevant for data science hackathons). Organizers usually provide the basic information about the event and sometimes a sample dataset. If they haven't provided one — just ask, it won't hurt. If it’s unclear what data will be provided or if any will be at all in 2-3 days — that's a red flag.
- New organizers. Don’t hesitate to Google information about the hackathon organizers. If they are organizing this type of event for the first time — there’s a good chance something will go wrong. On the other hand, if the organizer and jury members have previously held hackathons or have actively participated in the past — that's a green flag.
At one hackathon, I was told: 'You had the best solution by score, but sorry, we're evaluating teamwork, and you worked alone. If only you had brought a student or a girl...' Have you encountered such unfairness? How did you cope?
Yes, I have, more than once. I take everything that happens in stride: I did everything I could, and if it didn't work out — so be it.
Why are you doing all of this?
It's all just out of boredom.
Source: habr.com
