Den afsluttende del af trilogien om hackathons. I talen om motivationen for at deltage i sådanne arrangementer. var dedikeret til fejlene fra arrangørerne og deres konsekvenser. Den afsluttende del vil besvare de spørgsmål, der ikke kunne rummes i de første to dele.
Fortæl, hvordan du begyndte at deltage i hackathons.
Jeg studerede på kandidatuddannelsen ved Lappeenranta Universitet, mens jeg deltog i datanalysekonkurrencer. Min typiske dag så sådan ud: op kl. 8, flere timer på universitetet, derefter konkurrencer og kurser indtil midnat (mens jeg ventede på submission, så jeg forelæsninger eller læste artikler). Denne strenge tidsplan gav resultater, og jeg vandt datanalysekonkurrencen MERC-2017 (om hvilket der endda var ). Sejren gav mig selvtillid, og da jeg tilfældigt stødte på information om hackathonet SkinHack 2 i Moskva, besluttede jeg at besøge mine forældre og samtidig finde ud af, hvad et hackathon egentlig er.
Selve hackathonet var ret sjovt. Der var to spor inden for datanalyse med klare metrikker og et datasæt med præmier på 100.000 rubler. Det tredje spor handlede om appudvikling med en præmie på 50.000, og der var ikke nogen deltagere i det spor. På et tidspunkt sagde arrangøren, at et vindue med en knap uden funktionalitet kunne vinde 50.000, fordi præmien ikke kunne gå tabt. Jeg besluttede mig for ikke at lære at programmere apps (jeg konkurrerer ikke dér, hvor jeg let kan blive “overhalet”), men for mig var det et klart budskab om, at felterne i hackathons ikke er fyldt.
Dengang arbejdede jeg på begge spor inden for datanalyse alene. Jeg fandt en løsning i dataene, som gjorde det muligt at opnå en perfekt score, men kolonnen med løsningen var ikke i testdataene, jeg modtog to timer før arrangementet sluttede (for øvrigt, dengang forstod jeg, at tilstedeværelsen af kolonnen “target” i træningsdataene ikke tæller som en løsning). Samtidig åbnede leaderboardet, mit submission uden løsning lå på tredjepladsen ud af fem, der var et stort gap til den første, og jeg besluttede at spare tid og tage afsted.
Efter at jeg har analyseret, hvad der skete, fandt jeg en masse fejl (et af mine behov er at gennemgå, hvad der er sket, mentalt notere fejlene, deres årsag og hvad der kunne have været ændret — en rar arv fra min halv-professionelle pokerkarriere). Men én ting var helt klart — der er meget værdi i hackathons, og jeg er simpelthen nødt til at udnytte det. Efter denne begivenhed begyndte jeg at overvåge arrangementer og grupper, og den næste hackathon lod ikke vente på sig. Så kom en til, og endnu en…
Hvorfor deltager du i hackathons og ikke Kaggle?
Lige nu er Kaggle ikke noget, jeg er interesseret i. På et bestemt færdighedsniveau, uden specifikke grunde til at deltage, bliver Kaggle mindre nyttigt end andre aktiviteter. Jeg har deltager meget tidligere, tydeligvis er jeg på en eller anden måde ”sluppet ud”.
Hvorfor hackathons og ikke arbejde på dit eget projekt?
Jeg kan godt lide ideen om at skabe noget fantastisk med mine egne hænder i et ikke så hurtigt tempo. Drenge fra ODS har organiseret for alle, der ønsker at arbejde på deres projekter i weekenden sammen med ligesindede. Jeg tænker, at jeg snart vil slutte mig til dem.
Hvordan finder du arrangementer?
Hovedkilden er hackathon.com (verden) og en gruppe i Telegram (Rusland). Desuden dukker annoncer for arrangementer op i sociale medier og LinkedIn. Hvis man ikke finder noget, kan man kigge her: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Forbereder du en løsningsplan før deltagelse, eller beslutter du alt på stedet? For eksempel, en uge før hackathonet overvejer du: “Her har vi brug for sådan og sådan en specialist, vi skal lede efter”?
Hvis hackathonet er produktbaseret — ja, så forbereder jeg mig. Et par uger før finder jeg ud af, hvad jeg vil lave, overvejer, hvem der kan være nyttig, og samler et team af venner eller deltagere fra tidligere hackathons.
Er det muligt at hacke et hackathon alene? Hvad skal man gøre, hvis man ikke har et team?
Data science hackathons er ægte (jeg er et levende eksempel), men jeg har ikke set produktbaserede; jeg tror dog, de også kan være gode. Desværre pålægger arrangørerne nogle gange en begrænsning på det mindste antal deltagere i et team. Jeg tror, at det skyldes, at ikke alle 'solotemere' når finalen (dvs. de giver op ved de første udfordringer), og deltagelse i et team holder strømmen. Derudover forventes det efter arrangementet, at du fortsætter arbejdet med projektet. Med et team vil det være lettere at færdiggøre projektet.
Generelt vil jeg altid anbefale at deltage med et team. Hvis du ikke har dit eget team, hjælper arrangørerne altid med at finde eller danne et.
Hvordan klarer man træthed under et hackathon?
Der er to dage til rådighed til at arbejde under hackathonet, det er 48 timer (30-48 timer, lad os tage 48 for enkelhedens skyld). Vi trækker tid til søvn (16-20 timer), så der er ikke mere end 30 timer tilbage. Af dem vil kun omkring 8 timer (i gennemsnit) være reelt produktiv arbejdstid. Hvis man organiserer arbejdet korrekt (søvn, ernæring, få frisk luft, motion, øjeblikke af bevidsthed, korrekt kommunikation med teamet og skiftende aktiviteter), kan de dybe arbejdstimer komme op på 12-14. Efter en sådan arbejdsdag vil man føle sig udmattet, men det vil være en behagelig træthed. At kode uden søvn og pauser ved hjælp af energidrikke er en vej til fiasko.
Har du dine egne færdige pipelines til hackathons? Hvordan kom de til dig, hvordan er de struktureret (ligger .py-filer i mapper, hver til sin opgave osv.) og hvordan kan man selv begynde at skabe sådanne?
Jeg bruger ikke helt færdige løsninger fra tidligere hackathons i nye, men jeg har et udvalg af modeller og pipelines fra tidligere konkurrencer. Jeg skal ikke genprogrammere standardstykker fra bunden (f.eks. korrekt target encoding eller en simpel netværksmodel til at identificere intentioner i tekst), hvilket sparer mig meget tid.
I øjeblikket ser det sådan ud: for hver konkurrence eller hackathon er der et eget opbevaringssted på GitHub, hvor der opbevares notebooks, scripts og lidt dokumentation om, hvad der foregår. Desuden er der et separat opbevaringssted til forskellige 'hacks' (som korrekt target encoding med cross-validation). Jeg tror ikke, det er den mest elegante løsning, men indtil videre er jeg tilfreds med det.
Jeg ville starte med at organisere al min kode i mapper og skrive en kort dokumentation (hvorfor, hvad, hvordan jeg gjorde det, og resultatet).
Er det realistisk at forberede et MVP fra bunden på så kort tid, eller kommer alle deltagere med færdige løsninger?
Jeg kan kun sige noget om projekter relateret til datascience — ja, det er muligt. Et MVP for mig er en kombination af to faktorer:
- En levedygtig idé præsenteret som et produkt (dvs. business canvas er beskrevet). Der skal altid være en klar forståelse af, hvorfor og for hvem vi laver produktet. Nogle gange vinder projekter med en godt begrundet idé, men uden prototype præmier, og der er intet overraskende i det. Desværre kan mange deltagere ikke abstrahere fra bitterheden over nederlaget og lægge deres fejltagelser på arrangørernes kortsynethed, mens de fortsætter med at lave modeller, som ingen forstår, til de næste hackathons.
- Et eller andet bevis på, at du kan lave dette produkt (app, kode, beskrivelse af pipelines).
Nogle gange kommer der et hold med en færdig løsning til hackathonen og prøver at "tilpasse" det til arrangørernes opgave. Sådanne hold bliver afvist ved den tekniske screening, eller kun den del, de lavede på stedet, "tæller". Jeg har ikke set sådanne hold blandt vinderne, men jeg tror, det stadig er rentabelt for dem at deltage på grund af future value ().
Er der eksempler på, at projekter skabt ved hackathons er blevet til produktion/startup?
Ja. Jeg har haft tre tilfælde, hvor vi førte til produktion. Én gang gjorde jeg det selv, to gange — med andres hænder baseret på mine idéer og koden, jeg skrev ved hackathonen. Jeg kender også et par hold, der fortsatte samarbejdet med virksomheden som konsulenter. Jeg kender ikke de endelige resultater, men det er sandsynligt, at noget blev gjort færdigt. Jeg har ikke organiseret start-ups selv og ved ikke, om nogen har gjort det, selvom jeg er sikker på, at der er eksempler.
Efter at have deltaget i mange hackathons, hvilke råd ville du give dig selv, hvis du kunne vende tilbage til fortiden?
- Takik er vigtigere end manøvrer. Tænk på hver beslutning som et færdigt produkt. Idéen, Jupyter-notebooken, algoritmen er intet værd, hvis det ikke er klart, hvem der vil betale for det.
- Før du designer noget, skal du stille spørgsmålet: ikke "hvad?", men "hvorfor?" og "hvordan?" Eksempel: når du designer en ML-løsning, skal du først overveje den ideelle algoritme: hvad får den som input, hvordan bruges dens forudsigelser senere?
- Deltag i teamet.
Hvad plejer man at spise til hackathons?
Normalt er maden til hackathons ikke så god: pizza, energidrikke, sodavand. Maden er næsten altid organiseret i form af buffet (eller udleveringsbord) med en lang menneskeskare. Om natten er der normalt ikke mad, skønt der var et tilfælde ved en konkurrence i Paris, hvor de efterlod snacks — chips, donuts og cola. Jeg kan forestille mig tankerne hos arrangørerne: “Hvad spiser programmører? Åh, lige præcis! Chips og donuts — det er det hele. Lad os give dem det skidt.” Næste dag spurgte jeg arrangørerne: “Kunne vi ikke finde på noget andet om natten? Måske grød?” Efter det så de på mig som om jeg var en idiot. Den berømte franske gæstfrihed.
Ved gode hackathons bestilles maden i bokse, der er opdeling i normal, vegetarisk og kosher kost. Derudover sættes der et køleskab med yoghurter og müsli til dem, der vil have en snack. Te, kaffe, vand — standart. Jeg husker hackathon Hack Moscow 2 — de serverede en dejlig portion borscht og kødboller med kartoffelmos i 1C-kontorets kantine.
Kvaliteten af hackathons afhænger, så at sige, af arrangørernes faglige baggrund (for eksempel, de bedste hackathons arrangeres af konsulenter)?
De bedste hackathons er blevet arrangeret af arrangører, der enten tidligere har organiseret hackathons eller har deltaget i dem. Det er nok den eneste faktor, der påvirker kvaliteten af arrangementet.
Hvordan kan man forstå, at man ikke er en noob, og at det er tid til at deltage i en hackathon?
Det bedste tidspunkt at gå til en hackathon var for et år siden. Det næstbedste tidspunkt er nu. Så gå i gang, lav fejl, lær — det er helt i orden. Selv det neurale netværk — menneskets største opfindelse siden hjulet og gradient boosting over træer — kan ikke skelne mellem en kat og en hund i den første læringsperiode.
Hvilke "røde flag" indikerer straks, at arrangementet ikke vil være særlig godt, og at man ikke skal spilde sin tid?
- Et klart beskrivelser af, hvad der skal gøres (gælder for produkt hackathons). Hvis der bliver givet en klar opgave ved registreringen, er det bedre at blive hjemme. Af min erfaring har der ikke været et eneste godt hackathon med en kravspecifikation. For sammenligning: Godt - lav venligst noget relateret til analyse af lydoptagelser. Dårligt - lav venligst en applikation, der kan adskille samtalen i to separate lydspor for hver person.
- Lille præmiepulje. Hvis du bliver bedt om at lave 'Tinder for onlinebutikker med AI' og præmien for førstepladsen er 500 euro med et minimumsteam på 5 personer - så er det nok ikke værd at bruge tid (ja, det er en reel hackathon, der blev afholdt i München).
- Manglende data (gælder for datavidenskab hackathons). Arrangørerne giver normalt grundlæggende information om arrangementet og nogle gange et eksempel på datasættet. Hvis det ikke er blevet givet - spørg. Det skader ikke. Hvis der efter 2-3 dage ikke er klart, hvilke data der vil blive givet, og om de overhovedet vil blive givet - er det et rødt flag.
- Nye arrangører. Vær ikke doven og søg information om arrangørerne af hackathonen. Hvis de afholder en sådan begivenhed for første gang - er der stor risiko for, at noget går galt. På den anden side, hvis arrangøren og dommerne tidligere har afholdt hackathons eller har deltaget aktivt før - er det et grønt flag.
Ved et hackathon sagde de til mig: „Du havde den bedste score, men undskyld, vi vurderer teamwork, og du arbejdede alene. Hvis du havde taget en studerende eller en pige med…”? Har du mødt en lignende uretfærdighed? Hvordan håndterede du det?
Ja, jeg har mødt det flere gange. Jeg har en stoisk tilgang til det, der sker: jeg gjorde alt, hvad jeg kunne; hvis det ikke lykkedes - så måtte det være sådan.
Hvorfor laver du alt dette?
Det hele er bare for at kede mig.
Kilde: habr.com
