Het laatste deel van de trilogie over hackathons. In deze heb ik gesproken over de motivatie om aan dergelijke evenementen deel te nemen. was gewijd aan de fouten van de organisatoren en de gevolgen daarvan. Het laatste deel zal ingaan op vragen die niet in de eerste twee delen aan bod zijn gekomen.
Vertel hoe je begon met deelnemen aan hackathons.
Ik studeerde aan de masteropleiding van de Universiteit van Lappeenranta en deed ondertussen mee aan datanalysewedstrijden. Mijn typische dag zag eruit als volgt: opstaan om 8 uur, een paar colleges aan de universiteit, daarna wedstrijden en cursussen tot middernacht (terwijl de inzending wordt beoordeeld, kijk ik colleges of lees ik artikelen). Dit strakke schema heeft zijn vruchten afgeworpen en ik won de datanalysewedstrijd MERC-2017 (waarover er zelfs een ). De overwinning gaf me zelfvertrouwen, en toen ik toevallig informatie tegenkwam over de hackathon SkinHack 2 in Moskou, besloot ik mijn ouders te bezoeken en tegelijkertijd te ontdekken wat een hackathon is.
De hackathon zelf was behoorlijk leuk. Er waren twee tracks voor datanalyse met duidelijke metrics en datasets, met prijzen van 100k roebel. De derde track was voor applicatieontwikkeling met een prijs van 50k, en daar waren geen deelnemers voor. Op een gegeven moment zei de organisator dat een venster met een knop zonder functionaliteit 50k kon winnen, omdat de prijs niet kon worden onthouden. Ik besloot niet te leren programmeren voor applicaties (ik doe niet mee waar ik gemakkelijk kan worden 'verkeerd' gemaakt), maar voor mij was dit een duidelijke boodschap dat de velden in hackathons niet vol zijn.
Toen probeerde ik beide tracks voor datanalyse alleen. Ik vond een lek in de gegevens dat het mogelijk maakte een perfecte score te behalen, maar de kolom met het lek was niet aanwezig in de testgegevens die ik twee uur voor het einde van het evenement ontving (terzijde, toen begreep ik dat de aanwezigheid van de kolom 'doel' in de training niet wordt beschouwd als een lek). Tegelijkertijd werd het leaderboard geopend, mijn inzending zonder het lek stond op de derde plaats van de vijf, er was een grote achterstand tot de eerste plek, en ik besloot mijn tijd niet te verspillen en ging weg.
Nadat ik alles rustig had geanalyseerd, ontdekte ik een hoop fouten (Ć©Ć©n van mijn gewoonten is om mentaal door te lopen wat er is gebeurd met een notitieboekje en de fouten, hun oorzaken en wat ik had kunnen veranderen te analyseren - zo'n aangename nalatenschap van semi-professioneel pokeren). Maar Ć©Ć©n ding was zeker - hackathons bieden veel waarde en ik moet deze waarde gewoon realiseren. Na dit evenement begon ik evenementen en groepen te monitoren, en de volgende hackathon liet niet lang op zich wachten. Toen nog een, en nog een...
Waarom doe je hackathons en geen Kaggle?
Op dit moment geeft Kaggle me geen voldoening. Vanaf een bepaald niveau van vaardigheden, zonder specifieke redenen om deel te nemen, wordt Kaggle minder nuttig dan andere activiteiten. Ik heb er vroeger veel aan deelgenomen, blijkbaar heb ik het op de een of andere manier kunnen 'afbouwen'.
Waarom hackathons en niet werken aan je eigen project?
Ik vind het idee aantrekkelijk om iets moois met mijn eigen handen in een rustig tempo te maken. De jongens van ODS organiseerden voor iedereen die in het weekend met hun project bezig wil zijn in het gezelschap van gelijkgestemden. Ik denk dat ik me binnenkort bij hen zal voegen.
Hoe vind je evenementen?
De belangrijkste bron is hackathon.com (wereldwijd) en de chat in Telegram (Rusland). Daarnaast komen aankondigingen van evenementen voorbij in advertenties op sociale media en op LinkedIn. Als je niets kunt vinden, kun je hier kijken: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Bereid je een plan voor de oplossing voor voordat je deelneemt of wordt alles ter plaatse besloten? Bijvoorbeeld, een week voor de hackathon overweeg je: 'We hebben deze en deze specialist nodig, daar moet ik naar op zoek gaan'?
Als het een producthackathon is - ja, dan bereid ik me voor. Enkele weken van tevoren bedenk ik wat ik ga doen, overweeg ik wie van pas kan komen en stel ik een team samen van vrienden of deelnemers van eerdere hackathons.
Is het mogelijk om een hackathon in je eentje te hacken? Wat te doen als je geen team hebt?
Data science hackathons zijn echt (ik ben een levend voorbeeld), producthackathons heb ik niet gezien, hoewel ik denk dat dat ook klopt. Helaas leggen de organisatoren soms een beperking op het minimale aantal deelnemers in een team. Ik denk dat dit komt doordat niet alle āeenlingenā de finale halen (d.w.z. ze stappen gewoon op bij de eerste moeilijkheden), deelname in een team helpt wel om dat te voorkomen. Na het evenement wordt bovendien verwacht dat je verderwerkt aan het project. Met een team is het gemakkelijker om het project tot een goed einde te brengen.
Over het algemeen raad ik aan om altijd met een team deel te nemen. Als je geen eigen team hebt, helpen de organisatoren je altijd om er een te vinden of te creƫren.
Hoe manage je de vermoeidheid tijdens een hackathon?
Tijdens een hackathon krijg je 2 dagen om te werken, dat is 48 uur (30-48 uur, laten we voor de eenvoud 48 uur nemen). We halen de tijd voor slaap eraf (16-20 uur), dus blijven er maximaal 30 over. Van deze tijd kun je gemiddeld slechts 8 uur productief werken. Als je het werk goed organiseert (slaap, voeding, frisse lucht, oefeningen, momenten van mindfulness, goede communicatie met het team en afwisseling van activiteiten), kun je de deep work uren verhogen naar 12-14. Na zo'n werkperiode voel je je uitgeput, maar het is een aangename vermoeidheid. Coderen zonder slaap en pauzes, onderbroken door energiedrankjes - dat is de weg naar mislukking.
Heb je je eigen kant-en-klare pipelines voor hackathons? Hoe zijn die ontstaan, hoe zijn ze georganiseerd (liggen .py-bestanden in mappen, elk voor zijn eigen taak enz.) en hoe begin je zelf met het creƫren van zulke pipelines?
Ik gebruik geen volledig kant-en-klare oplossingen van vorige hackathons in nieuwe, maar ik heb wel mijn eigen verzameling modellen en pipelines van eerdere wedstrijden. Ik hoef geen standaardcodes vanaf nul opnieuw te schrijven (bijvoorbeeld de juiste target encoding of een eenvoudige netwerk voor het extraheren van intentie uit tekst), wat me veel tijd bespaart.
Momenteel ziet het er als volgt uit: voor elke wedstrijd of hackathon is er een eigen repo op GitHub, waarin notebooks, scripts en kleine documentatie staan over wat er gaande is. Daarnaast is er een aparte repo voor allerlei kant-en-klare āsnufjesā (zoals de juiste target encoding met cross-validatie). Ik denk niet dat dit de meest elegante oplossing is, maar voorlopig ben ik er tevreden mee.
Ik zou beginnen met het opslaan van al mijn code in mappen en het schrijven van een korte documentatie (waarom, wat, hoe ik het deed en het resultaat).
Is het echt mogelijk om in zo'n korte tijd een MVP vanaf nul voor te bereiden, of komen alle deelnemers met kant-en-klare oplossingen?
Ik kan alleen iets zeggen over projecten gerelateerd aan data science ā ja, het is mogelijk. Voor mij is een MVP de samenvoeging van twee factoren:
- Een levensvatbaar idee gepresenteerd als product (d.w.z. een business canvas is uitgewerkt). Er moet altijd een duidelijk begrip zijn van waarom en voor wie we het product maken. Soms winnen projecten met een goed onderbouwd idee, maar zonder prototype prijswinsten, en daar is niets verrassends aan. Helaas kunnen veel deelnemers zich niet losmaken van de bitterheid van verlies en schrijven ze hun mislukkingen af op de kortzichtigheid van de organisatoren, terwijl ze doorgaan met het maken van modellen voor onbekenden op de volgende hackathons.
- Een indicatie dat je dit product kunt maken (applicatie, code, beschrijving van pipelines).
Het gebeurt dat een team met een kant-en-klaar oplossing naar een hackathon komt en probeert deze aan te passen aan de opdracht van de organisatoren. Dergelijke teams worden afgevallen bij technische screening of alleen het deel wat zij op de locatie hebben gedaan wordt geteld. Ik heb dergelijke teams nooit bij de winnaars gezien, maar ik denk dat het nog steeds voordelig voor hen is om te gaan vanwege de toekomstige waarde ().
Zijn er voorbeelden van het brengen van projecten die tijdens hackathons zijn gerealiseerd naar productie/startup?
Ja. Ik heb drie gevallen gehad waarin we naar productie gingen. EƩn keer zelf, twee keer met de ideeƫn en de code die ik tijdens de hackathon schreef. Ik ken ook een paar teams die de samenwerking met een bedrijf als consultants voortzetten. Ik weet de uiteindelijke resultaten niet, maar het lijkt erop dat er waarschijnlijk iets tot een eind is gebracht. Ik heb zelf geen startups georganiseerd en weet niet of iemand dat deed, hoewel ik zeker weet dat er voorbeelden zijn.
Na deelname aan veel hackathons, welke adviezen zou je jezelf geven als je terug in de tijd kon gaan?
- Tactiek is belangrijker dan manoeuvres. Zie elke beslissing als een kant-en-klaar product. Ideeƫn, een Jupyter-notebook, algoritmes zijn niets waard als niet duidelijk is wie ervoor zal betalen.
- Voordat je iets ontwerpt, vraag jezelf niet 'wat?', maar 'waarom?' en 'hoe?'. Bijvoorbeeld: bij het ontwerpen van een ML-oplossing, denk in het begin na over het ideale algoritme: wat ontvangt het als invoer, hoe worden de voorspellingen later gebruikt?
- Doe mee met het team.
Wat wordt er meestal geserveerd op hackathons?
Op hackathons is het eten meestal niet goed: pizza's, energiedrankjes, frisdrank. Eten wordt bijna altijd georganiseerd in de vorm van een buffet (of een uitdeelpunt) waar een enorme rij voor staat. 's Nachts is er meestal geen eten, hoewel er een keer op een wedstrijd in Parijs wat snacks werden achtergelaten ā chips, donuts en cola. Ik stel me het denkproces van de organisatoren voor: 'Wat eten programmeurs? Oh ja, chips, donuts ā laten we ze dat geven.' De volgende dag vroeg ik de organisatoren: 'Jongens, kunnen we niet iets anders maken voor 's nachts? Bijvoorbeeld pap?' Toen keken ze me aan alsof ik gek was. Het beroemde Franse gastheerschap.
Op goede hackathons wordt het eten besteld in dozen, met een keuze uit regulier, vegetarisch en kosher. Daarnaast zetten ze een koelkast met yoghurt en muesli voor degenen die willen bijsnacken. Thee, koffie, water ā dat is standaard. Ik herinner me hackathon Hack Moscow 2 ā daar waren ze erg vriendelijk en gaven ze borsjt en gehaktballen met puree in de kantine van het kantoor van 1C.
De kwaliteit van hackathons hangt af, laten we zeggen, van de professionele achtergrond van de organisatoren (bijvoorbeeld, de beste hackathons worden georganiseerd door consultants)?
De beste hackathons kwamen van organisatoren die ofwel eerder hackathons hadden georganiseerd of eerder hadden deelgenomen. Dit is waarschijnlijk de enige factor die de kwaliteit van het evenement bepaalt.
Hoe weet je dat je geen newbie meer bent en dat het tijd is voor een hackathon?
De beste tijd om naar een hackathon te gaan was een jaar geleden. De op Ć©Ć©n na beste tijd is nu. Dus ga ervoor, maak fouten, leer ā dat is normaal. Zelfs een neuraal netwerk ā de grootste uitvinding van de mensheid na het wiel en gradient boosting boven bomen ā kan een kat niet van een hond onderscheiden in het eerste leerproces.
Welke 'rode vlaggen' geven meteen aan dat het evenement niet zal voldoen en dat je je tijd niet moet verspillen?
- Een duidelijke beschrijving van wat er moet worden gedaan (relevant voor producthackathons). Als er bij je registratie duidelijk een taak wordt gesteld, kun je beter thuisblijven. Voor zover ik me herinner, is er geen enkele goede hackathon geweest met een duidelijke opdracht. Ter vergelijking: Goed - maak iets dat gerelateerd is aan de analyse van spraakopnames. Slecht - maak een applicatie die in staat is om gesprekken te splitsen in twee aparte audiotracks voor elke persoon.
- Een kleine prijzenpot. Als je gevraagd wordt om een 'Tinder voor online winkels met AI' te maken en de prijs voor de eerste plaats is 500 euro met een minimaal teamgrootte van 5 personen - dan kun je beter geen tijd verspillen (ja, dit is een echte hackathon die in MĆ¼nchen werd gehouden).
- Ontbreken van gegevens (relevant voor data science-hackathons). Organisatoren bieden meestal basisinformatie over het evenement en soms een monster van de dataset. Als dit niet is verstrekt - vraag erom, het kost je niks. Als in 2-3 dagen onduidelijk is welke gegevens zullen worden verstrekt en of ze Ć¼berhaupt beschikbaar zullen zijn - dat is een rode vlag.
- Nieuwe organisatoren. Neem de moeite om informatie over de organisatoren van de hackathon op te zoeken. Als ze dit soort evenement voor het eerst organiseren, is de kans groot dat er iets misgaat. Aan de andere kant, als de organisator en de juryleden al hackathons hebben georganiseerd of in het verleden actief hebben deelgenomen - dat is een groene vlag.
Bij een hackathon werd me gezegd: 'Je had de beste score, maar sorry, we beoordelen teamwork, en je hebt alleen gewerkt. Als je een student of een meisje had meegenomen...' Heb je ooit zo'n onrechtvaardigheid ervaren? Hoe ben je daarmee omgegaan?
Ja, ik heb dat vaker meegemaakt. Ik ben stoĆÆcijns over alles wat er gebeurt: ik heb alles gedaan wat binnen mijn macht lag, als het niet gelukt is - dan is dat maar zo.
Waarom doe je dit allemaal?
Simpelweg uit verveling.
Bron: habr.com
