For rundt halvannet år siden begynte jeg å delta i hackathons. I løpet av denne tidsperioden klarte jeg å delta i mer enn 20 arrangementer av ulike størrelser og temaer i Moskva, Helsingfors, Berlin, München, Amsterdam, Zürich og Paris. I alle aktiviteter var jeg involvert i dataanalyse i en eller annen form. Jeg liker å komme til nye byer, knytte nye kontakter, komme med friske ideer, implementere gamle ideer på kort tid og adrenalinrushet under fremføringen og kunngjøringen av resultatene.
Dette innlegget er det første av tre innlegg om temaet hackathons, der jeg vil fortelle deg hva hackathons er og hvorfor du bør begynne å delta i hackathons. Det andre innlegget vil handle om den mørke siden ved disse arrangementene – om hvordan arrangørene gjorde feil under arrangementet, og hva de førte til. Det tredje innlegget vil være viet til å svare på spørsmål om hackathon-relaterte emner.
Hva er et hackathon?
Et hackathon er et arrangement som holdes over flere dager, og målet er å løse et problem. Vanligvis er det flere problemer på et hackathon, hver presentert som et eget spor. Sponsorselskapet gir en beskrivelse av oppgaven, suksessberegninger (beregninger kan være subjektive som "nyhet og kreativitet", eller de kan være objektive - klassifiseringsnøyaktighet på et utsatt datasett) og ressurser for å oppnå suksess (selskaps-APIer, datasett, maskinvare) . Deltakerne må formulere et problem, foreslå en løsning og vise en prototype av produktet sitt innen den tildelte tiden. De beste løsningene får premier fra selskapet og mulighet for videre samarbeid.
Hackathon-etapper
Etter at oppgavene er kunngjort, forenes hackathon-deltakerne i lag: hver "loner" mottar en mikrofon og snakker om den valgte oppgaven, hans erfaring, ideen og hva slags spesialister han trenger for implementering. Noen ganger kan et team bestå av én person som er i stand til å fullføre alt arbeidet med prosjektet selvstendig på et ganske høyt nivå. Dette er aktuelt for hackathons på dataanalyse, men er ofte forbudt eller uønsket for produktarrangementer – arrangørene er rettet mot å fortsette arbeidet med prosjektet, men allerede i bedriften; det dannede teamet har en rekke fordeler fremfor deltakere som ønsket å lage produktet alene. Det optimale teamet består vanligvis av 4 personer og inkluderer: front-end, back-end, dataforsker og forretningsperson. For øvrig er inndelingen mellom datavitenskap og produkthackathons ganske enkel – hvis det er et datasett med tydelige beregninger og en ledertavle, eller du kan vinne med kode i jupyter notebook – er dette et datavitenskapshackathon; alt annet - der du trenger å lage en søknad, nettside eller noe klissete - dagligvare.
Vanligvis starter arbeidet med et prosjekt klokken 9 på fredag, og fristen er klokken 10 på søndag. Noe av denne tiden må brukes på å sove (å holde seg våken og kode er en oppskrift på feil, sjekket jeg), noe som gjør at deltakerne ikke har mye tid til å produsere noe av kvalitet. For å hjelpe deltakere er bedriftsrepresentanter og mentorer tilstede på siden.
Arbeid med et prosjekt begynner med kommunikasjon med bedriftsrepresentanter, ettersom de bedre forstår detaljene i oppgaven, beregninger, og mest sannsynlig vil de bedømme arbeidet ditt til slutt. Hensikten med denne kommunikasjonen er å forstå hvilke områder som er mest relevante og hvor du bør fokusere din oppmerksomhet og tid.
På ett hackathon ble oppgaven satt til å utføre regresjon på et datasett med tabelldata og bilder og en tydelig metrikk – RMSE. Etter at jeg snakket med selskapets dataforsker, innså jeg at de ikke trengte regresjon, men klassifisering, men noen fra ledelsen bestemte rett og slett at det var best å løse problemet på denne måten. Og de trenger klassifisering ikke for å få en økning i monetære beregninger, men for å forstå hvilke parametere som er viktigst når du tar en beslutning og deretter behandle dem manuelt. Det vil si at det første problemet (regresjon med RMSE) endres til klassifisering; Prioriteten til vurderingen endres fra oppnådd nøyaktighet til evnen til å forklare resultatet. Dette eliminerer i sin tur muligheten for å bruke stabling og black box-algoritmer. Denne dialogen sparte meg for mye tid og økte vinnersjansene mine.
Etter at du har forstått hva du må gjøre, begynner selve arbeidet med prosjektet. Du må sette sjekkpunkter - tidspunktet for når de tildelte oppgavene må være fullført; Underveis er det en god idé å fortsette å kommunisere med mentorer - bedriftsrepresentanter og tekniske spesialister - dette er nyttig for å justere ruten til prosjektet ditt. Et nytt blikk på et problem kan foreslå en interessant løsning.
Siden et stort antall nybegynnere deltar i hackathon, er det god praksis fra arrangørenes side å holde forelesninger og mesterklasser. Vanligvis er det tre forelesninger - om hvordan du presenterer ideen din som et produkt, et foredrag om tekniske emner (for eksempel om bruk av åpne APIer i maskinlæring, slik at du slipper å skrive speech2text på to dager, men bruk en ferdig en), et foredrag om pitching (hvordan presentere produktet ditt, hvordan vifter med armene riktig på scenen slik at publikum ikke kjeder seg). Det er ulike aktiviteter for å puste opp deltakerne - en yogaøkt, bordfotball og tennis, eller et konsollspill.
Søndag morgen må du presentere resultatene av arbeidet ditt for juryen. Ved gode hackathons starter det hele med teknisk ekspertise – fungerer det du hevder virkelig? Hensikten med denne sjekken er å luke ut lag med en vakker presentasjon og buzzwords, men uten et produkt, fra gutta som faktisk gjorde noe. Dessverre er teknisk ekspertise ikke til stede på alle hackathons, og det er tilfeller der et team med 12 lysbilder og tankesettet "... blockchain, quantum computing, and then AI will finish it..." vinner førsteplassen. Slike presedenser er ikke så vanlige, men siden de er de mest minneverdige, tror mange at en god presentasjon er 99 % av seier i et hackathon. Presentasjonen er forresten veldig viktig, men bidraget er ikke mer enn 30%.
Etter deltakernes opptredener bestemmer juryen seg for å premiere vinnerne. Dette avslutter den offisielle delen av hackathonet.
Motivasjon for å delta i hackathons
Erfaring
Når det gjelder erfaringene, er hackathon et unikt arrangement. Det er ikke mange steder i naturen hvor du kan implementere en idé ut av ingenting på 2 dager og få umiddelbar tilbakemelding på arbeidet ditt. I løpet av hackathonet forbedres kritisk tenkning, teamarbeidsevner, tidsstyring, evnen til å jobbe i en stressende situasjon, evnen til å presentere resultatene av arbeidet ditt i en forståelig form, presentasjonsevner og mange andre. Dette er grunnen til at hackathons er et flott sted for folk med teoretisk kunnskap som ønsker å få erfaring fra den virkelige verden.
premier
Vanligvis er hackathon-premiefondet omtrent 1.5 10 - 100 300 euro for førsteplassen (i Russland - XNUMX-XNUMX tusen rubler). Den forventede fordelen (forventet verdi, EV) fra deltakelse kan beregnes ved hjelp av 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 — sannsynlighet for å vinne (for et nybegynnerlag vil denne verdien være begrenset til 10 %, for et mer erfarent lag - 50 % og høyere; Jeg har møtt folk som forlot hvert hackathon med en premie, men dette er snarere et unntak fra regelen og på lang sikt vil gevinstraten deres være lavere 100 %);
Fremtidig_verdi - en verdi som viser fremtidig fortjeneste ved å delta i et hackathon: dette kan være profitt fra erfaringen, etablerte forbindelser, mottatt informasjon, etc. Denne verdien er nesten umulig å bestemme nøyaktig, men den må huskes;
Kostnader — kostnader til transport, overnatting osv.
Beslutningen om å delta er tatt basert på en sammenligning av EV for hackathon med EV for aktiviteten du ønsker å gjøre hvis det ikke var noe hackathon: hvis du ville ligge på sofaen i helgen og plukke nese, da bør du nok delta i hackathon; hvis du tilbringer tid med foreldrene eller kjæresten din, så ta dem med på et lag for et hackathon (bare tuller, avgjør selv), hvis du frilanser, sammenlign dollar-time.
I henhold til mine beregninger kan jeg si at i Russland for den gjennomsnittlige dataforskeren på junior-middelnivå, er deltakelse i hackathons i forhold til det økonomiske overskuddet fra en vanlig arbeidsdag, men det er også nyanser (størrelse på laget, type av hackathon, premiefond, etc.). Generelt sett er ikke hackathons en bonanza for øyeblikket, men de kan gi et fint løft til ditt personlige budsjett.
Bedriftsrekruttering og nettverksbygging
For en bedrift er et hackathon en av måtene å ansette nye medarbeidere på. Det vil være mye lettere for deg å vise at du er en adekvat person og vet hvordan du jobber på et hackathon enn ved et intervju, og snurrer et binært tre på brettet (som forresten ikke alltid samsvarer med det du vil gjøre i en ekte jobb som dataforsker, men tradisjoner må respekteres). En slik test under "kamp"-forhold kan erstatte en testdag.
Jeg fikk min første jobb takket være et hackathon. På hackathonet viste jeg at mer penger kan presses ut av data, og jeg fortalte hvordan jeg skulle gjøre dette. Jeg startet et prosjekt på et hackathon, vant det, og fortsatte deretter prosjektet med sponsorselskapet. Dette var det fjerde hackathonet i livet mitt.
Mulighet for å få et unikt datasett
Dette er et veldig relevant punkt for datavitenskaplige hackathons, hvor viktigheten ikke alle forstår. Vanligvis leverer sponsorselskaper ekte datasett under arrangementet. Disse dataene er private, de er under NDA, som ikke hindrer oss i å vise deg proof of concept på et ekte datasett, og ikke på et leketøy Titanic. I fremtiden vil slike resultater være til stor hjelp når man søker jobb i denne bedriften eller en konkurrentbedrift, eller for å rettferdiggjøre lignende prosjekter. Enig i at alt annet likt er det bedre å ha gjennomført prosjekter som ble positivt vurdert enn å ikke ha dem. Generelt spiller slike fullførte prosjekter en lignende rolle som medaljer og statuser, men for bransjen er deres verdi mer åpenbar.
Советы
Generelt er det å jobbe på et hackathon en ganske mangfoldig opplevelse, og det er vanskelig å formulere en liste over regler. Men her vil jeg gjerne gi en liste over observasjoner som kan hjelpe en nybegynner:
- Ikke vær redd for å gå på hackathons selv om du ikke har erfaring eller et lag. Tenk på hvordan du kan være nyttig. For eksempel, kanskje du har en interessant idé eller er du godt kjent med et område? Du kan bruke domenekunnskapen din når du skal formulere et problem og finne ikke-trivielle løsninger. Eller kanskje du er best på Google? Dine ferdigheter vil spare mye tid hvis du kan finne ferdige implementeringer i Github. Eller er du veldig flink til å stille inn lightgbm-parametere? I dette tilfellet, ikke gå til hackathon, men bevis det i kagla-konkurransen.
- Taktikk er viktigere enn manøvrer. Målet ditt på hackathon er å løse et problem. Noen ganger, for å løse et problem, må du identifisere det. Sjekk at ditt identifiserte problem virkelig er relevant for selskapet. Sjekk løsningen din mot problemet, spør deg selv om løsningen din er optimal. Når de vurderer løsningen din, vil de først se på relevansen av problemet og tilstrekkeligheten til den foreslåtte løsningen. Få mennesker er interessert i arkitekturen til ditt nevrale nettverk eller hvor mange hender du har mottatt.
- Delta på så mange hackathons som mulig, men ikke vær sjenert for å gå bort fra dårlig organiserte arrangementer.
- Legg til resultatene av arbeidet ditt på hackathon til CV-en din, og ikke vær redd for å skrive om det offentlig.
Essensen av hackathons. Kort
Kilde: www.habr.com