For about a year and a half now, I've been participating in hackathons. During this time, I have taken part in over 20 events of various scales and themes in Moscow, Helsinki, Berlin, Munich, Amsterdam, Zurich, and Paris. At all these events, I focused on data analysis in one form or another. I enjoy visiting new cities, establishing new contacts, generating fresh ideas, realizing old concepts in a short period, and the adrenaline rush during presentations and announcements of results.
This post is the first of three posts on the topic of hackathons, where I will explain what hackathons are and why you should start participating in them. The second post will delve into the dark side of these events â discussing the mistakes made by organizers and their consequences. The third post will be dedicated to answering questions related to hackathon themes.
What is a hackathon?
A hackathon is an event held over a few days, aimed at solving a specific problem. Typically, there are several problems at a hackathon, each represented as a separate track. The sponsoring company provides a description of the task, success metrics (which can be subjective, like 'novelty and creativity', or objective â accuracy of classification on a holdout dataset), and resources for achieving success (the company's API, datasets, 'hardware'). Participants must define the problem, propose a solution, and showcase a prototype of their product within the allotted time. The best solutions receive prizes from the company and the opportunity for further collaboration.
Stages of a hackathon
Etter at oppgavene er annonsert, samles deltakerne fra hackathonen i grupper: hver "alene kjĂžrer" fĂ„r mikrofon og snakker om den valgte oppgaven, sin erfaring, ideen sin og hvilken type spesialister han trenger for Ă„ gjennomfĂžre dette. Noen ganger kan et lag bestĂ„ av Ă©n person som er i stand til Ă„ utfĂžre hele arbeidet selvstendig pĂ„ et hĂžyt nivĂ„. Dette er aktuelt for hackathoner innen datanalyse, men ofte forbudt eller uĂžnsket for produktarrangementer â arrangĂžrene er fokusert pĂ„ videre arbeid med prosjektet, men allerede i et selskap; det dannede laget har flere fordeler over deltakere som Ăžnsker Ă„ skape produktet alene. Det optimale laget bestĂ„r vanligvis av 4 personer og inkluderer: frontend, backend, data scientist og en forretningsperson. Forresten er inndelingen mellom datavitenskap/produkt-hackathoner ganske enkel â hvis det finnes et datasett med klare mĂ„lemetoder og leaderboard, eller man kan vinne med koden i Jupyter Notebook â er dette et datavitenskapshackathon; alt annet â der det kreves Ă„ lage en applikasjon, nettside eller noe som fanger oppmerksomheten â er produkt
Som regel starter arbeidet med prosjektet klokka 21.00 pÄ fredag, og fristen er klokka 10.00 pÄ sÞndag. En del av denne tiden mÄ settes av til sÞvn (Ä ikke sove og kode er en sikker vei til Ä mislykkes, det har jeg prÞvd), noe som betyr at deltakerne har begrenset tid til Ä lage noe kvalitetsmessig. For Ä hjelpe deltakerne er det tilstede representanter fra selskapet og mentorer.
Arbeidet med prosjektet starter med samtaler med representantene fra selskapet, ettersom de har bedre forstÄelse av oppgave-spesifikasjonene, metrikker og de vil sannsynligvis bedÞmme arbeidet ditt pÄ slutten. MÄlet med disse samtalene er Ä forstÄ hvilke retninger som er mest relevante, og hvor man bÞr fokusere oppmerksomheten og tiden sin.
PĂ„ en hackathon ble det satt en regresjonsoppgave pĂ„ et datasett med tabulĂŠre data og bilder og en klar metrik â RMSE. Etter Ă„ ha snakket med dataspecialisten i selskapet, forsto jeg at de trengte en klassifisering, men noen i ledelsen hadde bestemt at oppgaven skulle lĂžses pĂ„ denne mĂ„ten. De trengte klassifisering ikke for Ă„ oppnĂ„ Ăžkonomiske gevinster, men for Ă„ forstĂ„ hvilke parametere som er viktigst i beslutningsprosessen, for sĂ„ Ă„ behandle dem manuelt. Den opprinnelige oppgaven (regresjon med RMSE) ble dermed endret til klassifisering; prioriteten for vurdering skiftet fra oppnĂ„dd nĂžyaktighet til muligheten for Ă„ forklare resultatet. Dette utelukker bruken av stacking og black box-algoritmer. En slik dialog sparet meg for mye tid og Ăžkte mine sjanser til Ă„ vinne.
NĂ„r du har forstĂ„tt hva du mĂ„ gjĂžre, begynner det reelle arbeidet med prosjektet. Du mĂ„ sette opp sjekkpunkter â tidspunktet du mĂ„ ha gjennomfĂžrt de tildelte oppgavene; i tillegg er det lurt Ă„ fortsette Ă„ kommunisere med mentorer â representanter fra selskapet og tekniske spesialister â dette er nyttig for Ă„ justere ruten for prosjektet ditt. Et friskt perspektiv pĂ„ problemet kan gi deg interessante lĂžsninger.
Siden det deltar mange nybegynnere pĂ„ hackathons, er det god skikk fra arrangĂžrene Ă„ holde forelesninger og workshops. Vanligvis er det tre forelesninger â om hvordan man presenterer ideen sin som et produkt, en teknisk forelesning (for eksempel om bruk av Ă„pne API-er i maskinlĂŠring, slik at du slipper Ă„ skrive din egen speech2text pĂ„ to dager, men kan bruke en ferdiglaget), og en forelesning om pitching (hvordan presentere produktet sitt, hvordan hĂ„ndtere kroppssprĂ„ket pĂ„ scenen slik at publikum ikke kjeder seg). Det tilbys forskjellige aktiviteter for Ă„ energisere deltakerne â yogatim, bordfotball og tennis eller konsollspill.
PĂ„ sĂžndag morgen mĂ„ du presentere resultatene av arbeidet ditt for juryen. PĂ„ gode hackathons begynner alt med teknisk ekspertise â fungerer det du sier virkelig? MĂ„let med denne sjekken er Ă„ filtrere ut lag med vakre presentasjoner og buzzwords, men uten produkt, fra de som faktisk har gjort noe. Dessverre er ikke teknisk ekspertise til stede pĂ„ alle hackathons, og det forekommer tilfeller hvor et lag med 12 lysbilder og tankegang som "... blockchain, kvanteberegning, sĂ„ her gjĂžr AI det ferdig..." vinner fĂžrsteplassen. Slike tilfeller er ikke sĂ„ vanlige, men siden de huskes best, tror mange at en god presentasjon er 99% av seieren pĂ„ et hackathon. For Ăžvrig er presentasjonen virkelig viktig, men dens bidrag er ikke mer enn 30%.
Etter deltakerens presentasjon tar juryen en avgjÞrelse om Ä premie vinnerne. Den offisielle delen av hackathonet er nÄ avsluttet.
Motivasjon for Ä delta pÄ hackathons
Erfaring
Fra et erfaringsperspektiv er hackathon en unik hendelse. Det finnes ikke sÄ mange steder hvor du kan realisere en idé fra ingenting pÄ 2 dager og fÄ Þyeblikkelig tilbakemelding pÄ arbeidet ditt. Under et hackathon utvikles kritisk tenkning, teamarbeid, tidsstyring, evnen til Ä hÄndtere stress, evnen til Ä presentere resultatene tydelig, presentasjonsferdigheter og mange andre. Derfor er hackathons et flott sted for folk med teoretisk kunnskap som Þnsker Ä fÄ praktisk erfaring.
Premier
Den vanlige premiepuljen i et hackathon utgjĂžr omtrent 1,5k â 10k euro for fĂžrsteplassen (i Russland â 100-300 tusen rubler). Den forventede gevinsten (expected value, EV) ved deltakelse kan beregnes med en enkel formel:
EV = Prize * WinRate + Future_Value - Costs der Premie â stĂžrrelsen pĂ„ premien (for enkelhets skyld antar vi at det bare er Ă©n premie);
WinRate â sannsynligheten for Ă„ vinne (for et nybegynnerlag vil dette tallet vĂŠre begrenset til 10%, for et mer erfarent lag â 50% eller mer; jeg har truffet folk som forlot hvert hackathon med en premie, men dette er snarere unntaket enn regelen, og over lang tid vil deres winrate vĂŠre under 100%);
Future_Value â et mĂ„l som viser den fremtidige fortjenesten fra deltakelse i et hackathon: dette kan vĂŠre fortjeneste fra tilegnet erfaring, nettverksbygging, informasjon mottatt, osv. Denne stĂžrrelsen er praktisk talt umulig Ă„ fastslĂ„ nĂžyaktig, men det er viktig Ă„ huske pĂ„;
Kostnader â utgifter til transport, overnatting, andre.
Beslutningen om deltakelse tas pĂ„ grunnlag av sammenligning av EV for hackathon med EV for aktiviteten du ville ha gjort dersom hackathonet ikke hadde skjedd: hvis du ville slappet av pĂ„ sofaen i helgen og plukket nesen, sĂ„ er det kanskje verdt Ă„ delta i hackathonet; hvis du vil tilbringe tid med foreldrene eller kjĂŠresten â ta dem med pĂ„ hackathon-teamet (bare tuller, avgjĂžr selv), hvis du vil frilanse â sammenlign dollar-per-time.
Etter mine beregninger, kan jeg si at i Russland for en gjennomsnittlig data scientist av junior-middels nivÄ, er deltakelse i hackathoner sammenlignbart med den Þkonomiske fortjenesten fra en vanlig arbeidsdag, men det er ogsÄ nyanser (stÞrrelsen pÄ teamet, type hackathon, premiepotten osv.). Generelt er hackathoner for Þyeblikket ikke en gullgruve, men de kan gi et hyggelig tilskudd til det personlige budsjettet.
Ansettelse i selskapet og nettverksbygging
For selskapet er hackathon en av mÄtene Ä ansette nye ansatte pÄ. Det vil vÊre mye lettere for deg Ä vise at du er en kompetent person og kan jobbe under hackathon enn Ä gjÞre det under et intervju, der du tegner et binÊrt tre pÄ tavlen (som for Þvrig ikke alltid stemmer overens med det du faktisk vil gjÞre i den virkelige jobben som data scientist, men tradisjoner mÄ respekteres). Denne testen under 'strid' kan erstatte en prÞve-dag.
Min fÞrste jobb fikk jeg takket vÊre et hackathon. PÄ hackathonet viste jeg at man kunne fÄ mer penger ut av dataene, og jeg fortalte hvordan jeg planla Ä gjÞre det. Jeg startet et prosjekt pÄ hackathonet, vant det, og fortsatte deretter prosjektet i selskapet som var sponsor. Dette var det fjerde hackathonet i mitt liv.
Mulighet til Ä fÄ et unikt datasett
Dette er et svÊrt relevant punkt for datavitenskaps hackathons, hvis betydning ikke alle forstÄr. Vanligvis gir sponsorbedrifter ekte datasett under arrangementet. Disse dataene er private og underlagt NDA, noe som ikke hindrer dem i Ä vise deg et proof of concept med et ekte datasett, og ikke et leketÞy som Titanic. Slike resultater vil etter hvert vÊre til stor hjelp nÄr du sÞker jobb i dette selskapet eller hos en konkurrent, eller ved Ä begrunne lignende prosjekter. Enig i at, alt annet likt, det er bedre Ä ha utfÞrte prosjekter som har fÄtt positive vurderinger enn ikke Ä ha dem? Generelt sett spiller slike gjennomfÞrte prosjekter en lignende rolle som medaljer og status pÄ Kaggle, men for industrien er deres verdi mer Äpenbar.
RĂ„d
Generelt sett er det Ä jobbe pÄ et hackathon en ganske variert erfaring, og det er vanskelig Ä formulere en spesifikk liste med regler. Men her vil jeg gjerne gi en liste med observasjoner som kan hjelpe nybegynnere:
- Ikke vÊr redd for Ä delta pÄ hackathons selv om du ikke har erfaring eller et team. Tenk pÄ hva du kan vÊre nyttig med. Kanskje har du en interessant idé, eller sÄ har du godt grep om et spesifikt omrÄde? Du kan bruke din domenekunnskap nÄr du formulerer problemet og finne ukonvensjonelle lÞsninger. Eller kanskje er du best i klassen til Ä sÞke pÄ Google? Dine ferdigheter vil spare deg for mye tid hvis du kan finne eksisterende implementasjoner pÄ GitHub. Eller er du veldig god pÄ tuning av parametere i LightGBM? I sÄ fall, ikke dra til hackathon, men bevis det i Kaggle-konkurranser.
- Taktikk er viktigere enn manÞvrer. Din oppgave pÄ hackathon er Ä lÞse et problem. Noen ganger mÄ du identifisere et problem fÞr du kan lÞse det. Sjekk at det problemet du har identifisert faktisk er relevant for selskapet. Vurder din lÞsning i henhold til problemet, still deg selv spÞrsmÄlet om hvor optimal lÞsningen din er. NÄr lÞsningen din vurderes, vil fokuset fÞrst og fremst vÊre pÄ relevansen av problemet og hensiktsmessigheten til den foreslÄtte lÞsningen. Arkitekturen pÄ ditt nevrale nettverk eller hvor mange armer-auksjoner du fikk er lite interessant for de fleste.
- BesÞk sÄ mange hackathons som mulig, men ikke vÊr redd for Ä forlate dÄrlig organiserte arrangementer.
- Legg til resultatene av arbeidet ditt pÄ hackathonet i CV-en din, og vÊr ikke redd for Ä skrive om det offentlig.
Essensen av hackathons. Kort fortalt
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish