What team do you usually go to hackathons with? Initially, we stated that the ideal team consists of five people - a manager, two programmers, a designer and a marketer. But the experience of our finalists showed that you can win a hackathon with a small group of three people. Of the 26 teams that won the final, 3 competed and won as a musketeer team. How they did it - read on.
We talked to the captains of all three teams and realized that there is a lot in common in their strategy of behavior. The heroes of this post are the teams PLEXeT (Stavropol, nomination of the Ministry of Communications), Composite Key (Tula, nomination of the Ministry of Informatization and Communications of the Republic of Tatarstan) and Jingu Digital (Yekaterinburg, nomination of the Ministry of Industry and Trade). For those who are interested, a brief description of the commands was hidden under cat.
Command DescriptionsPLEXet
There are three people in the team - a developer (web, C ++, information security competencies), a designer and a manager. We didn’t know each other before the regional hackathon. The team was assembled by the captain based on the results of online testing.
Composite key
There are three fellow developers in the team - fullstack with ten years of experience in IT, backend and mobile, and backend with a focus on databases.
jingu digital
The team consists of two programmers - backend and AR / Unity, as well as a designer who was also responsible for managing the team. Won in the nomination of the Ministry of Industry and Trade
Choose a task that is close to your competencies
Remember, there was such a rhyme “drama circle, photo circle, and I also want to sing”? I think that this feeling is familiar to many - when everything around is interesting, you want to show yourself in a new way in your direction, and feel the new industry / development area. The choice here depends only on the goals of your team and your willingness to take risks - can you accept your mistake if you suddenly realize in the middle of a hackathon that it is unrealistic to pull out this task? Experiments from the category “I don’t rummage in mobile development, but what the hell is not joking” - for an amateur. Are you that amateur?
Artem Koshko (), command "Composite key": “We originally thought about trying something new. At the regional stage, we also tried several nuget packages, which we never got our hands on, and Yandex.Cloud. At the final, we deployed CockroachDB in Kubernetes, tried to roll migrations onto it using EF Core. Some went well, some not so well. So we learned something new, and tested ourselves, and made sure of the reliability of proven approaches.”.
How to choose a task if your eyes run wide:
- Think about what competencies are needed to solve this case, and whether all team members have them
- If there are not enough competencies, will you be able to compensate for them (come up with a different solution, quickly learn a new one)
- Conduct a brief research of the market for which you will make a product
- Calculate the competition - which track / company / task will go to the most people
- Answer the question: what will drive you the most?
Oleg Bakhtadze-Karnaukhov (), the PLEXeT team: “We made a decision at a ten-hour transfer at the airport - just at the time of landing, a list of tracks and brief wording of tasks fell on our mail. I immediately identified four tasks that are interesting to me as a programmer and for which the action plan after the start is clear - what needs to be done and how we will do it. Then he estimated the tasks of each team member and assessed the level of competition. As a result, they chose between the tasks of Gazprom and the Ministry of Telecom and Mass Communications. Our designer’s father works with oil and gas — we called him and asked questions about the industry. As a result, we realized that yes, it’s interesting, but we won’t be able to offer something fundamentally new and we definitely won’t pull out competencies, because there are too many industry specifics to take into account. As a result, we took a chance and went to the first track.”
Diana Ganieva (), Jingu Digital team: “At the regional stage, we had a task related to agriculture, and at the final - AR / VR in industry. They were chosen by the whole team so that each person could realize their abilities. After we sifted out what seemed to us not so interesting.
Do your homework
And we are not talking about code preparations now - it makes no sense to do this at all. It's about team communication. If you haven’t played yet, haven’t learned to understand each other and negotiate, get together a couple of times in advance and simulate a hackathon, or at least get on the phone to talk about the main points, think over an action plan, and discuss each other’s strengths and weaknesses. You can even find some case and try to solve it - at least schematically, at the level of "how to get from point A to point B".
For this paragraph, we risk catching minuses in karma and comments, they say, how is it that you don’t understand anything, but what about the excitement, drive, the feeling that now a prototype will be born from the primordial broth (hello, biology lessons).
Yes, BUT.
Improvisation and drive are good only when they become only a small deviation from the strategy - otherwise the risks are too great to spend time cleaning up chaos and correcting mistakes, instead of working, eating or sleeping.
Oleg Bakhtadze-Karnaukhov, PLEXeT team: “I didn’t know any of the members of my team before the competition - I chose and invited them based on competencies and grades at the online testing stage. When we won the regional hackathon and realized that we still had to go to Kazan together and complete the hackathon project in Stavropol, we decided that we would get together and train. Before the final, we met twice - we found a random problem and solved it. Something like a case championship. And already at this stage, we saw a problem in communication and distribution of tasks - while Polina (designer) and Lev (manager) were thinking about corporate style, product features, looking for market data, I had a lot of free time. So we realized that we needed to take a more difficult nomination (I’m not bragging, it’s just that we mostly came across tasks related to the web, but for me it’s one or two) and I need to get more involved in work processes. As a result, at the final, during the preliminary research, I was engaged in mathematical modeling and developed algorithms.”
Artem Koshko, Composite Key team : “We prepared rather morally, there was no talk of preparing a code. We also distributed roles in the team in advance - the three of us are all programmers (we have fullstack and two backends, plus I rummage a bit in mobile development), but it was clear that someone would have to take on the roles of designer and manager. That's how I imperceptibly became a team leader, tried myself as a business analyst, speaker and presentation maker. I think if we hadn’t said it in advance, we wouldn’t have been able to correctly allocate time, and we wouldn’t have reached the final defense.”
Diana Ganieva, Jingu Digital: “We didn’t prepare for the hackathon, because we believe that hack projects should be made from scratch – that’s honest. In advance, at the stage of selecting tracks, we had a general concept of what we want to do”.
On some developers do not leave
Diana Ganieva, Jingu Digital team: “We have three specialists in different fields in our team. In my opinion, this is the perfect composition for a hackathon. Everyone is busy with their own business and there are no intersections and division of tasks. One more person would be superfluous.
Statistics showed that the average composition of our teams is from 4 to 5 people, among which (at best) one designer. It is generally accepted that it is necessary to strengthen the team with developers of various stripes - in order to be able to get into the base and surprise with a “machine” if anything. At best, they also take a designer with them (don't be offended, we love you!), the presentation and interfaces won't draw themselves, after all. The role of a manager is even more often neglected - usually this function is taken over by the team captain, part-time developer.
And this is fundamentally wrong.
Artem Koshko, Composite Key team: “At some point, we regretted that we did not take a specialized specialist into the team. If we were still somehow able to cope with the design, then it was difficult with the business plan and other strategic things. A striking example is when it was necessary to calculate the target audience and market size, TAM, SAM.”
Oleg Bakhtadze-Karnaukhov, PLEXeT team: “The contribution of the developer to the product is far from 80% of the work, as is commonly believed. It cannot be said that it was easier for the guys - almost the entire main array of tasks lay on them. My code without interfaces, presentations, videos, strategies is just a set of characters. If there were other developers in the team instead of them, we probably would have coped, but everything would have looked less professional. Especially the presentation is generally half the success, as it seems to me. During the defense and then in real life in a couple of minutes, no one will have time to understand whether your prototype really works. If you get carried away with schemes, then no one will listen to you. If you go too far with the text, everyone will understand that you yourself do not know what is important in your product, how to present it and who needs it.
Time management and relaxation
Remember how in childhood cartoons like "Tom and Jerry" the characters put matches under their eyelids so that they would not close? Inexperienced (or too enthusiastic) hackathon participants look about the same.
It’s easy to lose touch with reality and the sense of time at a hackathon – the atmosphere is conducive to unrestrained coding without breaks for rest, sleep, fooling around in the game room, chatting with partners or attending master classes. If you treat it like a World Cup or an Olympics, then yes, maybe this is how you should behave. Not really.
Artem Koshko, Composite Key team: “We had a lot of chak-chak, a lot - a tower was built from it in the middle of our table, it supported our morale and reinforced carbohydrates at the right time. They rested and worked almost all the time together, they did not rest separately. But they slept differently. Andrey (fullstack developer) likes to sleep during the day, Denis and I like to sleep at night. Therefore, I worked more with Denis during the day, and with Andrey at night. And he slept in between. We did not have any system of work and setting goals - rather, everything was spontaneous. But this did not interfere with us, because we understand and complement each other well. It helped that we are colleagues and communicate closely. I am Andrey's former intern, and Denis joined the company as my intern."
And here, by the way, is the same mountain of chak-chak.
Competent time management was named by almost all the participants we interviewed as the main criterion for success at the hackathon. What does it mean? You distribute tasks in such a way that you have time for sleep and food, and tasks are not performed in the mode everything collapsed, but at a pace that is comfortable for each team member.
Oleg Bakhtadze-Karnaukhov, PLEXeT team: "Our challenge was not to work as many hours as possible, but to stay productive as long as possible. Although we slept for 3-4 hours a day, we seem to have succeeded. We could go to the game room or hang out at the partner stands, set aside normal time for food. On the second day, we tried to relieve Lev as much as possible so that he could get enough sleep and manage to put himself in order before the performance. The hackathon rehearsals helped us, as we already understood how to distribute tasks, and the synchronization of the daily routine - we ate, slept and were awake at the same time. As a result, they worked as a single mechanism.”
We don’t know how this team managed to get the Eye of Agomoto to the hackathon, but in the end they even managed to shoot a video about the project and prepare a handout.
A few tips for time management at the hackathon:
- Go from big to small - beat tasks into small blocks.
- A hackathon is a marathon. What is the most important thing in a marathon? Try to run at the same pace, otherwise you will fall down by the end of the distance. Try to work with approximately the same intensity and not bring yourself to exhaustion.
- Think in advance what will be included in the tasks of each participant, and how much time it will take him. It will help to avoid surprises when there is half an hour before the deadline, and you don’t have a big piece of work ready.
- Check the coordinates to adjust the volume of tasks. Do you feel that you are going well and even have time? Great - you can spend it on a dream or finalizing a presentation.
- Don't get hung up on details, work in broad strokes.
- Breaking away from work is difficult, so specifically set aside time for yourself to sleep, rest, or downcast. You can set alarms, for example.
- Set aside time to prepare and rehearse your speech. It is mandatory for everyone and always. We talked about this in one of the previous .
And yet there is such an alternative opinion. What option are you for - torture by coding or war by war, and dinner on schedule?
Diana Ganieva, Jingu Digital team: “In our team, each person is responsible for one thing, there was no one to replace us, so they could not work in shifts. When there was absolutely no strength left, they slept for three hours, depending on the amount of work that was still left for the participant. There was no time to hang out from the word at all, we do not waste precious time on this. Productivity was supported, albeit with a short, but sleep, and goodies with tea - no energy drinks or coffee.
We hid several useful links under the cut if you want to dive into the topic of time management. It will come in handy in everyday life - believe the author of this post, who is always late 🙂
For the conquerors of time — Effective time management techniques were collected on the Netology blog by a Kaspersky Lab project manager:
- Good article for beginners on Cossa:
Try to stand out
Above, we wrote about the team that made a handout to protect the project. In their track, they were the only ones like that, and we are sure that among the 3500+ participants there were no more of them.
Of course, this did not become the main reason for their victory, but it definitely brought an additional plus - at least, the sympathy of experts. You can stand out in different ways - some of our winners start each performance with a joke that they made a bomb (Sakharov team, hello!).
We will not dwell on this in detail, but simply share the case of the PLEXeT team - it seems to us that it deserves to become a joke about the son of a mother's friend.
Oleg Bakhtadze-Karnaukhov, PLEXeT team: “We understood that we were ahead of the curve and decided it would be cool to come to pre-defense with a handout. The project has a lot of technical details, explanations of algorithms, which are not included in the presentation at all. And I want to show. Experts supported the idea and even helped optimize it. They didn’t even look at the first version, they said that they would never read such a canvas. We were the only ones on defense."
Something is bound to go wrong, and that's okay.
At the hackathon, as in ordinary life, there is always a place for jambs. Even if it seems that you have foreseen everything - who among us has not been late for a plane / exam / wedding simply because the cars decided to get stuck in a traffic jam, the escalator - to break down, and the passport - to forget at home?
Oleg Bakhtadze-Karnaukhov, PLEXeT team: “Polina and I made a presentation all night, but in the end they forgot to upload it to the computer in the hall where the defense was held. We are trying to open from a flash drive, and the antivirus perceives the file as a virus and demolishes it. As a result, we managed to start everything just a minute before the end of our performance. We managed to show the video, but still very upset. A similar story happened to us in pre-defense. Our prototype didn't launch, Polina's and Lev's computers froze, and for some reason I left mine in the hangar where our track was sitting. And although the experts saw our work in the morning, we looked like a team of eccentrics with a handout, beautiful words, but without a product. Considering that many participants perceived my work on mathematical models as “sitting, drawing something, not looking at the computer,” the situation was not very good.”
It sounds trite, but all you can do in this situation is exhale. It's already happened. No, you are not the only one, everyone messes up. Even if this is a fatal mistake, it is an experience. And also think about whether the person who evaluates you considers this case a fakap?
Share in the comments which line-up is more comfortable for you to work on a hackathon (both in people and specialists) and how you build processes in a team.
Source: habr.com