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
