Den sista delen av hackathon-trilogin. I Jag pratade om motivationen att delta i sådana evenemang. var dedikerad till arrangörernas misstag och deras resultat. Den sista delen kommer att besvara frågor som inte passade in i de två första delarna.
Berätta för oss hur du började delta i hackathons.
Jag läste till magisterexamen vid Villmanstrands universitet samtidigt som jag löste tävlingar inom dataanalys. Min typiska dag såg ut så här: gå upp klockan 8, några par på universitetet, sedan tävlingar och kurser fram till midnatt (medan inlämningen räknas tittar jag på föreläsningar eller läser artiklar). Ett så strikt schema bar frukt, och jag vann MERC-2017 dataanalystävlingen (som till och med diskuterades ). Segern gav mig självförtroende, och när jag av misstag stötte på information om SkinHack 2 hackathon i Moskva bestämde jag mig för att besöka mina föräldrar och samtidigt ta reda på vad ett hackathon är.
Själva hackathonet visade sig vara ganska roligt. Det fanns två spår om dataanalys med tydliga mått och en datauppsättning med prispengar på 100 50 rubel. Det tredje spåret handlade om apputveckling med ett pris på 50k, och det fanns inga deltagare. Vid ett tillfälle sa arrangören att ett fönster med en knapp utan funktionalitet kunde vinna XNUMXk, eftersom priset inte kunde betalas ut. Jag började inte lära mig hur man programmerar applikationer (jag tävlar inte där jag lätt kan bli "vänd på mig"), men för mig var det ett tydligt budskap att fälten i hackathons inte är trånga.
Sedan löste jag båda dataanalysspåren ensam. Jag hittade en läcka i data som gjorde att jag kunde få den idealiska hastigheten, men kolumnen med läckan fanns inte i testdata som jag fick två timmar före slutet av händelsen (förresten, då förstod jag att närvaron av en "mål"-kolumn i tåget räknas inte som en läcka ). Samtidigt öppnade leaderboarden, min submission utan ansikte tog tredjeplatsen av fem, det var ett stort gap till den första och jag bestämde mig för att inte slösa tid och gick.
Efter att jag med ett nytt sinne analyserat vad som hände, hittade jag en massa fel (en av mina vanor är att mentalt bläddra igenom vad som hände med anteckningsblocket och analysera felen, deras orsak och vad som kunde ha ändrats - ett så trevligt arv av ett semiprofessionellt pokerspel). Men en sak var säker - det finns mycket värde i hackathons, och jag var helt enkelt tvungen att implementera det. Efter detta evenemang började jag övervaka evenemang och grupper, och det efterföljande hackathonet lät inte vänta på sig. Sedan en till och en till...
Varför gör du hackathons och inte Kaglo?
Jag gillar inte Kagle för tillfället. Från en viss färdighetsnivå, utan särskilda skäl för deltagande, blir kagle mindre användbar än andra aktiviteter. Jag deltog mycket förut, tydligen lyckades jag på något sätt "stiga av".
Varför hackathons och inte arbeta med ditt eget projekt?
Jag gillar tanken på att göra något coolt med mina egna händer i långsam takt. Killarna från ODS organiserade sig för alla som vill ägna helgen åt att jobba med sitt projekt med likasinnade. Jag tror att jag snart kommer att gå med dem.
Hur hittar du evenemang?
Huvudkälla - hackathon.com (världen) och telegramchatt (Ryssland). Dessutom visas meddelanden om händelser i reklam på sociala nätverk och på linkedin. Om du inte hittar något kan du titta här: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Förbereder du en lösningsplan innan du deltar eller bestäms allt i farten? Till exempel, en vecka före hackathon, tror du: "Vi kommer att behöva en sådan och en specialist här, vi kommer att behöva leta efter den"?
Om hackathon är för mat, ja, jag gör mig redo. Några veckor innan räknar jag ut vad jag ska göra, tar reda på vem som kan vara användbar och sätter ihop ett team av vänner eller deltagare från tidigare hackathons.
Är det verkligen möjligt att hacka ett hackathon ensam? Vad ska man göra om det inte finns något lag?
Datavetenskapshackathons är verkliga (jag är ett levande exempel på detta), jag har inte sett livsmedelshackathon, även om jag också tror det. Tyvärr sätter ibland arrangörer en gräns för det minsta antalet deltagare i ett lag. Jag tror att detta beror på det faktum att inte alla "ensamvargar" når finalen (det vill säga de går helt enkelt med de första svårigheterna); deltagandet i ett lag håller fortfarande tillbaka. Även efter evenemanget förväntas du fortsätta arbeta med projektet. Det blir lättare att få projektet att genomföras med ett team.
Generellt sett är mitt råd att alltid delta med ett lag. Om du inte har ett eget team hjälper arrangörerna dig alltid att hitta eller skapa ett.
Hur klarar du av trötthet under ett hackathon?
På hackathon får du 2 dagar på dig att arbeta, det är 48 timmar (30-48 timmar, låt oss ta 48 för att underlätta räkningen). Vi tar bort tid för sömn (16-20 timmar) och lämnar inte mer än 30. Av dessa kommer 8 timmar (i genomsnitt) faktiskt att läggas på produktivt arbete. Om du organiserar ditt arbete på rätt sätt (sömn, kost, gå ut i friska luften, övningar, minuter av mindfulness, korrekt kommunikation med teamet och byte av aktiviteter) kan djupa arbetstimmar ökas till 12-14. Efter sådant arbete kommer du att känna dig utmattad, men det kommer att vara trevlig trötthet. Kodning utan sömn och raster, avbruten av energidrycker, är ett recept på misslyckande.
Har du egna färdiga pipelines för hackathons? Hur fick du dem, hur är de organiserade (de finns i mappar med .py-filer, var och en för sin uppgift etc.) och hur börjar du skapa dessa själv?
Jag använder inte helt färdiga lösningar från tidigare hackathons i nya, men jag har en egen djurpark med modeller och pipelines från tidigare tävlingar. Jag behöver inte skriva om standardstycken från början (till exempel korrekt målkodning eller ett enkelt rutnät för att extrahera avsikter från text), vilket sparar mig mycket tid.
För tillfället ser det ut så här: för varje tävling eller hackathon finns en egen repo på GitHub, den lagrar anteckningsböcker, manus och liten dokumentation om vad som händer. Dessutom finns det en separat repo för alla möjliga "trick" (som korrekt målkodning med korsvalidering). Jag tycker inte att det här är den mest eleganta lösningen, men det passar mig just nu.
Jag skulle börja med att spara all min kod i mappar och skriva kort dokumentation (varför, vad, hur jag gjorde det och resultatet).
Är det realistiskt att förbereda en MVP från grunden på så kort tid eller kommer alla deltagare med färdiga lösningar?
Jag kan bara säga om projekt relaterade till datavetenskap - ja, det är möjligt. MVP för mig är en kombination av två faktorer:
- En livskraftig idé presenterad som en produkt (dvs målad på en företagsduk). Det ska alltid finnas en tydlig förståelse för varför och för vem vi gör en produkt. Ibland vinner projekt med en välgrundad design, men utan prototyp, priser, och det är inte förvånande. Tyvärr kan många deltagare inte ignorera nederlagets bitterhet och tillskriva sina misslyckanden till arrangörernas kortsiktighet, som fortsätter att skära modeller för någon okänd vid nästa hackathon.
- Någon indikator på att du kan göra denna produkt (applikation, kod, beskrivning av pipelines).
Det händer att ett lag kommer till ett hackathon med en färdig lösning och försöker "skräddarsy" den efter arrangörernas instruktioner. Sådana team stängs av under teknisk screening eller bara den del som de gjorde på webbplatsen "räknas". Jag har inte sett sådana lag som vinnare, men jag tror att det fortfarande är lönsamt för dem att spela på grund av det framtida värdet ().
Finns det några exempel på att ta med hantverk implementerat vid hackathons till produktion/startup?
Ja. Jag hade tre fall när de tog den till produktion. En gång själv, två gånger - med någon annans händer, baserat på mina idéer och kod som jag skrev på hackathonet. Jag känner också till ett par team som fortsatte att samarbeta med företaget som konsulter. Jag vet inte de slutliga resultaten, men troligtvis har något blivit klart. Jag har inte organiserat startups själv och jag vet inte att någon har det, även om jag är säker på att det finns exempel.
Efter att ha deltagit i många hackathons, vilka råd skulle du ge dig själv om du kunde gå tillbaka i tiden?
- Taktik är viktigare än manövrar. Se varje lösning som en färdig produkt. En idé, en Jupiter-laptop, en algoritm är ingenting värda om det inte är klart vem som ska betala för det.
- Innan du designar något, svara inte på frågan "vad?", utan "varför?" Och hur?". Exempel: när du designar en ML-lösning, tänk först på den ideala algoritmen: vad tar den emot som input, hur används dess förutsägelser i framtiden?
- Bli en del av ett team.
Vad brukar de mata med på hackathons?
Vanligtvis är maten på hackathons dålig: pizza, energidrycker, läsk. Nästan alltid ordnas maten i form av en buffé (eller serveringsbord) dit det är enorm kö. De tillhandahåller vanligtvis inte mat på natten, även om det fanns ett fall på en tävling i Paris där mat lämnades över natten - chips, munkar och cola. Jag kommer att föreställa mig arrangörernas tankeprocess: "Så vad äter programmerare där? Åh, precis! Chips, munkar - det är allt. Låt oss ge dem det här skräpet." Dagen efter frågade jag arrangörerna: ”Gubbar, är det möjligt att göra något annorlunda för natten? Nåja, kanske lite gröt?” Efter det tittade de på mig som om jag var en idiot. Berömd fransk gästfrihet.
På bra hackathons beställs mat i lådor, det är uppdelning i vanliga, vegetariska och koshermåltider. Plus att de ställer ett kylskåp med yoghurt och müsli - för den som vill ha ett mellanmål. Te, kaffe, vatten - standard. Jag minns Hack Moscow 2 hackathon - de matade mig hjärtligt med borsjtj och kotletter med potatismos i matsalen på 1C-kontoret.
Hackathons förnuft beror så att säga på arrangörernas professionella sfär (exempelvis genomförs de bästa hackathonen av konsulter)?
De bästa hackathonen kom från arrangörer som antingen hade anordnat hackathon tidigare eller deltagit i dem tidigare. Kanske är detta den enda faktorn som evenemangets kvalitet beror på.
Hur förstår man att man inte är en noob och att det är dags för ett hackathon?
Den bästa tiden att gå på ett hackathon är för ett år sedan. Den näst bästa tiden är nu. Så gör det, gör misstag, lär dig – det är okej. Inte ens ett neuralt nätverk - människans största uppfinning sedan hjulet och lutning boostar över träd - kan inte skilja en katt från en hund under den första träningsperioden.
Vilka "röda flaggor" indikerar omedelbart att evenemanget inte kommer att bli särskilt bra och att det inte finns något behov av att slösa tid?
- En tydlig beskrivning av vad som behöver göras (relevant för produkthackathons). Om du under registreringen får en tydlig uppgift, är det bättre att stanna hemma. I mitt minne fanns det inte ett enda bra hackathon med tekniska specifikationer. Som jämförelse: Okej - gör oss något relaterat till att analysera ljudkonversationer. Dåligt – gör oss till ett program som skulle kunna dela upp en konversation i två separata ljudspår för varje person.
- Liten prisfond. Om du blir ombedd att göra "Tinder för en onlinebutik med AI" och priset för förstaplatsen är 500 euro och en minsta lagstorlek på 5 personer, är det förmodligen inte värt att slösa bort din tid (ja, det här är ett riktigt hackathon som var hölls i München).
- Brist på data (relevant för datavetenskapshackathon). Arrangörer tillhandahåller vanligtvis grundläggande information om evenemanget och ibland ett exempel på dataset. Om de inte har tillhandahållit det, fråga, det kostar dig ingenting. Om det inom 2-3 är oklart vilken data som kommer att tillhandahållas och om den överhuvudtaget kommer att tillhandahållas är detta en röd flagga.
- Nya arrangörer. Var inte lat och Google information om hackathon-arrangörerna. Om de håller ett evenemang av det här slaget för första gången är sannolikheten stor att något går fel. Å andra sidan, om arrangören och jurymedlemmarna redan har hållit hackathon eller aktivt deltagit tidigare är detta en grön flagga.
Vid ett hackathon sa de till mig: "Du hade den bästa lösningen på kort tid, men förlåt, vi utvärderar lagarbete och du arbetade ensam. Nu, om du tog en student eller en tjej till ditt lag...”? Har du någonsin stött på sådan orättvisa? Hur klarade du dig?
Ja, jag har träffat det mer än en gång. Jag är stoisk om allt som händer: jag gjorde allt som stod i min makt, om det inte fungerade, så var det.
Varför gör du allt detta?
Allt detta är bara av tristess.
Källa: will.com