Den siste delen av hackathon-trilogien. I Jeg snakket om motivasjonen for å delta på slike arrangementer. var dedikert til arrangørenes feil og deres resultater. Den siste delen vil svare på spørsmål som ikke passet inn i de to første delene.
Fortell oss hvordan du begynte å delta i hackathons.
Jeg studerte til en mastergrad ved Universitetet i Lappeenranta mens jeg løste konkurranser innen dataanalyse. Min typiske dag så slik ut: stå opp klokken 8, noen par på universitetet, så konkurranser og kurs til midnatt (mens innleveringen teller, ser jeg på forelesninger eller leser artikler). En så streng tidsplan bar frukter, og jeg vant MERC-2017 dataanalysekonkurransen (som til og med ble diskutert ). Seieren ga meg selvtillit, og da jeg ved et uhell kom over informasjon om SkinHack 2 hackathon i Moskva, bestemte jeg meg for å besøke foreldrene mine og samtidig finne ut hva et hackathon er.
Selve hackathonet viste seg å være ganske morsomt. Det var to spor på dataanalyse med klare beregninger og et datasett med premiepenger på 100 50 rubler. Det tredje sporet var på apputvikling med en premie på 50k, og det var ingen deltakere. På et tidspunkt sa arrangøren at et vindu med en knapp uten funksjonalitet kunne vinne XNUMXk, fordi premien ikke kunne utbetales. Jeg begynte ikke å lære å programmere applikasjoner (jeg konkurrerer ikke der jeg lett kan bli "snudd"), men for meg var det en klar beskjed om at feltene i hackathons ikke er overfylte.
Da løste jeg begge dataanalysesporene alene. Jeg fant en lekkasje i dataene som gjorde at jeg kunne få den ideelle hastigheten, men kolonnen med lekkasjen var ikke i testdataene jeg mottok to timer før slutten av arrangementet (forresten, da forsto jeg at tilstedeværelsen av en "mål"-kolonne i toget teller ikke som en lekkasje ). Samtidig åpnet ledertavlen, innleveringen min uten ansikt tok tredjeplassen av fem, det var et stort gap til den første og jeg bestemte meg for ikke å kaste bort tiden og dro.
Etter at jeg med et friskt sinn analyserte hva som skjedde, fant jeg en haug med feil (en av mine vaner er å mentalt bla gjennom hva som skjedde med notisblokken og analysere feilene, årsaken deres og hva som kunne blitt endret - en så hyggelig arv av et semiprofesjonelt pokerspill). Men en ting var helt sikkert – det er mye verdi i hackathons, og jeg måtte rett og slett implementere det. Etter dette arrangementet begynte jeg å overvåke arrangementer og grupper, og det påfølgende hackathonet lot ikke vente på seg. Så en til, og en til...
Hvorfor driver du med hackathons og ikke Kaglo?
Jeg liker ikke Kagle for øyeblikket. Fra et visst ferdighetsnivå, uten spesifikke grunner for deltakelse, blir kagle mindre nyttig enn andre aktiviteter. Jeg deltok mye før, tydeligvis klarte jeg å "gå av".
Hvorfor hackathons og ikke jobbe med ditt eget prosjekt?
Jeg liker ideen om å lage noe kult med mine egne hender i sakte tempo. Gutta fra ODS organiserte for alle som vil bruke helgen på å jobbe med prosjektet sitt med likesinnede. Jeg tror at jeg snart blir med dem.
Hvordan finner du arrangementer?
Hovedkilde - hackathon.com (verden) og telegramchat (Russland). I tillegg vises kunngjøringer om hendelser i reklame på sosiale nettverk og på linkedin. Hvis du ikke finner noe, kan du se her: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Utarbeider du en løsningsplan før du deltar eller er alt avgjort i farten? For eksempel, en uke før hackathon, tenker du: "Vi trenger en slik og en spesialist her, vi må se etter den"?
Hvis hackathonet er for mat, ja, jeg gjør meg klar. Noen uker før finner jeg ut hva jeg skal gjøre, finner ut hvem som kan være nyttig, og setter sammen et team med venner eller deltakere fra tidligere hackathons.
Er det virkelig mulig å hacke et hackathon alene? Hva skal jeg gjøre hvis det ikke er noe lag?
Datavitenskapshackaton er ekte (jeg er et levende eksempel på dette), jeg har ikke sett dagligvarehackaton, selv om jeg også tror det. Noen ganger setter arrangører dessverre en grense på minimum antall deltakere i et lag. Jeg tror dette skyldes det faktum at ikke alle "lonere" når finalen (det vil si at de bare drar med de første vanskelighetene); deltakelse i et lag holder fortsatt tilbake. Selv etter arrangementet forventes det at du fortsetter å jobbe med prosjektet. Det blir lettere å få prosjektet til å gjennomføres med et team.
Generelt er mitt råd å alltid delta med et lag. Hvis du ikke har ditt eget team, vil arrangørene alltid hjelpe deg med å finne eller opprette et.
Hvordan takler du tretthet under et hackathon?
På hackathon får du 2 dager til å jobbe, det er 48 timer (30-48 timer, la oss ta 48 for å lette tellingen). Vi fjerner tid til søvn (16-20 timer), og etterlater ikke mer enn 30. Av disse vil 8 timer (i gjennomsnitt) faktisk brukes på produktivt arbeid. Hvis du organiserer arbeidet ditt riktig (søvn, ernæring, gå ut i frisk luft, øvelser, minutter med mindfulness, riktig kommunikasjon med teamet og bytte aktiviteter), kan dype arbeidstimer økes til 12-14. Etter slikt arbeid vil du føle deg utslitt, men det vil være hyggelig tretthet. Koding uten søvn og pauser, avbrutt av energidrikker, er en oppskrift på feil.
Har du egne ferdige rørledninger for hackathons? Hvordan fikk du dem, hvordan er de organisert (de er i mapper med .py-filer, hver for sin oppgave osv.) og hvordan begynne å lage disse selv?
Jeg bruker ikke helt ferdige løsninger fra tidligere hackathons i nye, men jeg har min egen dyrehage med modeller og rørledninger fra tidligere konkurranser. Jeg trenger ikke å skrive om standardbiter fra bunnen av (for eksempel riktig målkoding eller et enkelt rutenett for å trekke ut intensjoner fra tekst), noe som sparer meg for mye tid.
For øyeblikket ser det slik ut: for hver konkurranse eller hackathon er det en egen repo på GitHub, den lagrer notatbøker, skript og liten dokumentasjon om hva som skjer. Pluss at det er en egen repo for alle slags boksede "triks" (som korrekt målkoding med kryssvalidering). Jeg synes ikke dette er den mest elegante løsningen, men det passer meg foreløpig.
Jeg ville starte med å lagre all koden min i mapper og skrive kort dokumentasjon (hvorfor, hva, hvordan jeg gjorde det og resultatet).
Er det realistisk å forberede en MVP fra bunnen av på så kort tid eller kommer alle deltakere med ferdige løsninger?
Jeg kan bare si om prosjekter relatert til datavitenskap - ja, det er mulig. MVP for meg er en kombinasjon av to faktorer:
- En levedyktig idé presentert som et produkt (dvs. malt på et forretningslerret). Det skal alltid være en klar forståelse av hvorfor og for hvem vi lager et produkt. Noen ganger vinner prosjekter med et velbegrunnet design, men uten prototype, premier, og dette er ikke overraskende. Dessverre kan mange deltakere ikke ignorere nederlagets bitterhet og tilskrive feilene deres til arrangørenes kortsynthet, og fortsetter å kutte modeller for noen ukjente ved neste hackathons.
- Noen indikatorer på at du kan lage dette produktet (applikasjon, kode, beskrivelse av rørledninger).
Det hender at et lag kommer til et hackathon med en ferdig løsning og prøver å "skreddersy" den til arrangørenes instruksjoner. Slike team blir avskåret under teknisk screening, eller bare delen de gjorde på nettstedet blir "telt". Jeg har ikke sett slike lag som vinnere, men jeg tror det fortsatt er lønnsomt for dem å spille på grunn av den fremtidige verdien ().
Finnes det noen eksempler på å bringe håndverk implementert på hackathons til produksjon/oppstart?
Ja. Jeg hadde tre saker da de brakte den til produksjon. En gang meg selv, to ganger - med noen andres hender, basert på ideene mine og koden jeg skrev på hackathonet. Jeg kjenner også et par team som fortsatte å samarbeide med selskapet som konsulenter. Jeg vet ikke de endelige resultatene, men mest sannsynlig ble noe fullført. Jeg har ikke organisert startups selv, og jeg vet ikke at noen har det, selv om jeg er sikker på at det finnes eksempler.
Etter å ha deltatt i mange hackathons, hvilke råd ville du gitt deg selv hvis du kunne gå tilbake i tid?
- Taktikk er viktigere enn manøvrer. Tenk på hver løsning som et ferdig produkt. En idé, en Jupiter-laptop, en algoritme er ingenting verdt hvis det ikke er klart hvem som skal betale for det.
- Før du designer noe, svar på spørsmålet ikke "hva?", men "hvorfor?" Og hvordan?". Eksempel: når du designer en hvilken som helst ML-løsning, tenk først på den ideelle algoritmen: hva mottar den som input, hvordan brukes spådommene i fremtiden?
- Vær en del av et team.
Hva mater de vanligvis på hackathons?
Vanligvis er maten på hackathons dårlig: pizza, energidrikker, brus. Nesten alltid er maten organisert i form av en buffet (eller serveringsbord) som det er stor kø til. De gir vanligvis ikke mat om natten, selv om det var et tilfelle på en konkurranse i Paris hvor mat ble stående over natten - chips, smultringer og cola. Jeg vil forestille meg tankeprosessen til arrangørene: «Så hva spiser programmerere der? Å, akkurat! Chips, smultringer - det er alt. La oss gi dem dette søppelet.» Dagen etter spurte jeg arrangørene: «Gutter, er det mulig å gjøre noe annerledes for natten? Vel, kanskje litt grøt?" Etter det så de på meg som om jeg var en idiot. Berømt fransk gjestfrihet.
På gode hackathons bestilles mat i bokser, det er en inndeling i vanlige, vegetariske og koshermåltider. Pluss at de setter et kjøleskap med yoghurt og mysli - for de som vil ha en matbit. Te, kaffe, vann - standard. Jeg husker Hack Moscow 2 hackathon - de matet meg hjertelig med borsjtsj og koteletter med potetmos i kantinen på 1C-kontoret.
Fornuften til hackathons avhenger så å si av arrangørenes faglige sfære (for eksempel blir de beste hackathonene utført av konsulenter)?
De beste hackathonene var fra arrangører som enten hadde arrangert hackathon før eller deltatt på dem før. Kanskje er dette den eneste faktoren som kvaliteten på arrangementet avhenger av.
Hvordan forstå at du ikke er en noob og at det er på tide med et hackathon?
Den beste tiden å gå på et hackathon er for et år siden. Den nest beste tiden er nå. Så gå for det, gjør feil, lær - det er greit. Selv et nevralt nettverk - menneskets største oppfinnelse siden hjulet og gradienten øker over trær - kan ikke skille en katt fra en hund i den første treningsepoken.
Hvilke "røde flagg" indikerer umiddelbart at arrangementet ikke vil være veldig bra og at det ikke er nødvendig å kaste bort tid?
- En tydelig beskrivelse av hva som må gjøres (relevant for produkthackathons). Hvis du under registreringen får en klar oppgave, er det bedre å holde seg hjemme. I mitt minne var det ikke et eneste bra hackathon med tekniske spesifikasjoner. Til sammenligning: Ok – gjør oss noe relatert til å analysere lydsamtaler. Dårlig - lag oss til en applikasjon som vil kunne dele en samtale i to separate lydspor for hver person.
- Liten premiefond. Hvis du blir bedt om å lage "Tinder for en nettbutikk med AI" og premien for førsteplassen er 500 euro og en minimum lagstørrelse på 5 personer, er det sannsynligvis ikke verdt å kaste bort tiden din (ja, dette er et skikkelig hackathon som var holdt i München).
- Mangel på data (relevant for datavitenskaplige hackathons). Arrangører gir vanligvis grunnleggende informasjon om arrangementet og noen ganger et eksempeldatasett. Hvis de ikke har gitt det, spør, det vil ikke koste deg noe. Hvis det innen 2-3 er uklart hvilke data som vil bli gitt og om de i det hele tatt vil bli gitt, er dette et rødt flagg.
- Nye arrangører. Ikke vær lat og Google informasjon om hackathon-arrangørene. Holder de et arrangement av denne typen for første gang, er det stor sannsynlighet for at noe går galt. På den annen side, hvis arrangør og jurymedlemmer allerede har holdt hackathon eller deltatt aktivt tidligere, er dette et grønt flagg.
På et hackathon fortalte de meg: «Du hadde den beste løsningen på kort tid, men beklager, vi evaluerer teamarbeid, og du jobbet alene. Nå, hvis du tok en student eller en jente til laget ditt...»? Har du noen gang vært borti slik urettferdighet? Hvordan klarte du deg?
Ja, jeg har møtt den mer enn en gang. Jeg er stoisk om alt som skjer: Jeg gjorde alt i min makt, hvis det ikke gikk, så får det være.
Hvorfor gjør du alt dette?
Alt dette er bare av kjedsomhet.
Kilde: www.habr.com