A trilógia záró része a hackathonokról. Az eseményeken való részvételhez való motivációmról szól. a szervezők hibáira és következményeikre volt szentelve. A záró rész válaszol azon kérdésekre, amelyek nem fértek el az első két részben.
Mesélj, hogyan kezdtél el részt venni hackathonokon.
A Lappeenranta Egyetem mesterképzésén tanultam, miközben adatelemző versenyeken indultam. A tipikus napom így nézett ki: 8-kor kelés, néhány óra az egyetemen, majd versenyek és internetes kurzusok éjfélig (amíg a beküldést számolják, addig előadásokat nézek vagy cikkeket olvasok). Ez a kemény időbeosztás meghozta a gyümölcsét, és megnyertem a MERC-2017 adatelemző versenyt (melyről még A győzelem növelte az önbizalmamat, és amikor véletlenül rátaláltam a SkinHack 2 hackathonra Moszkvában, úgy döntöttem, meglátogatom a szüleimet, és közben szeretném megtudni, mi ez — hackathon.
Magának a hackathonnak elég mulatságos volt. Két adatelemző pályázat volt világos metrikával és nyereménnyel 100 ezer rubel. A harmadik pályázat alkalmazásfejlesztés volt 50 ezer forint nyereménnyel, azonban abban nem volt résztvevő. Egy pillanatban a szervező azt mondta, hogy egy funkció nélküli gombbal ellátott ablak is nyerhet 50 ezer forintot, mert a díjat nem lehet kifizetetlenül hagyni. Nem akartam alkalmazásokat tanulni programozni (nem versenyzek ott, ahol könnyen
meglehetfordítani a helyzetem), de világos üzenet volt számomra, hogy a hackathonokban nincsenek telítve a területek. Akkor két adatelemző pályázaton indultam egyedül. Találtam egy csúszópontot az adatokban, ami lehetővé tette a tökéletes pontszámot, de a kulcsoszlop nem szerepelt a tesztadatokban, amelyeket két órával a verseny vége előtt kaptam (mellesleg akkor már tudtam, hogy a „target” oszlop megléte a tréning során nem számít csúszópontnak). Eközben megnyílt a ranglista, a csúszpont nélküli beküldésem az ötödikből a harmadik helyen állt, a elsőtől nagy lemaradás volt, és úgy döntöttem, hogy nem pazarolom az időt, és elmentem.
Miután friss fejjel elemeztem, hogy mi történt, rengeteg hibát találtam (az egyik szokásom az, hogy mentálisan végigjárom, mi történt a jegyzetfüzetemmel, és elemezni a hibákat, azok okát, és hogy mit lehetett volna megváltoztatni — ez egy kellemes örökség a fél-professzionális pókerjátékból). De egy dolog biztos volt — a hackathonokban rengeteg érték rejlik, és ezt valóra kell váltanom. Ezt követően elkezdtem figyelni az eseményeket és csoportokat, és a következő hackathon nem váratott sokáig magára. Aztán jött még egy, és még egy…
Miért foglalkozol hackathonokkal, nem pedig Kaggle-lel?
Jelenleg nem tetszik a Kaggle. Egy bizonyos készségi szint után, speciális részvételi okok nélkül, a Kaggle kevésbé hasznos, mint más tevékenységek. Korábban sokat részt vettem, lehet, hogy valahogy sikerült „leszoknom”.
Miért hackathonok, nem pedig a saját projekteden való munka?
Tetszik az ötlet, hogy valami menőt csináljak a saját kezemmel, nem túl gyors tempóban. Az ODS srácai szervezték mindenki számára, aki a hétvégén szeretne a saját projektjén dolgozni hasonló gondolkodású emberek társaságában. Azt hiszem, hamarosan csatlakozni fogok hozzájuk.
Hogyan találod meg az eseményeket?
Fő forrásom a hackathon.com (világszerte) és a Telegram csoport (Oroszország). Plusz az események bejelentései megjelennek a közösségi média hirdetéseiben és a LinkedIn-en. Ha semmit sem találsz, megnézheted itt: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Készítesz tervet a részvétel előtt, vagy minden a helyszínen dől el? Például a hackathon előtt egy héttel átgondolod, hogy: „Itt szükség lesz egy ilyen és ilyen szakemberre, keresnem kell majd”?
Ha a hackathon termékorientált — igen, készülök. Néhány héttel előtte kitalálom, mit fogok csinálni, átgondolom, ki lehet hasznos, és csapatot gyűjtök a barátokból vagy a korábbi hackathonok résztvevőiből.
Valóban meg lehet hackelni a hackathont egyedül? Mit tegyek, ha nincs csapatom?
A datascience hackathon is real (I am a living example), I haven't seen product ones, though I also think it's possible. Unfortunately, sometimes the organizers impose a minimum number of participants in a team. I think this is due to the fact that not all “lone wolves” make it to the finals (i.e., they simply drop out at the first difficulties), participation in a team keeps them in check. Also, after the event, you are expected to continue working on the project. It will be easier to refine the project with a team.
Overall, I recommend always participating with a team. If you don't have your own team, the organizers will always help find or create one.
How do you manage fatigue during a hackathon?
You get 2 days to work at a hackathon, which is 48 hours (let's take 48 for simple calculations, usually it's 30-48 hours). Subtracting sleep time (16-20 hours), you have no more than 30 hours left. Out of these, realistically, only about 8 hours can be spent on productive work (on average). If you organize your work properly (sleep, nutrition, fresh air breaks, short exercises, mindfulness minutes, proper communication with the team, and switching activities), you can bump deep work hours up to 12-14. After such work, you'll feel exhausted, but it will be a pleasant kind of fatigue. Coding without sleep and breaks, fueled by energy drinks, leads to failure.
Do you have your own ready-made pipelines for hackathons? How did they come about, how are they organized (are .py files categorized into folders, each for its own task, etc.) and how to start creating such ones yourself?
I don't use fully ready-made solutions from past hackathons in new ones, but I have my own collection of models and pipelines from past competitions. I don’t have to rewrite standard pieces from scratch (like proper target encoding or a simple neural network for intent extraction from text), which saves me a lot of time.
At the moment, it looks like this: for each competition or hackathon, there is a separate repo on GitHub, where notebooks, scripts, and some documentation about what is happening are stored. Plus, there is a separate repo for various packaged “features” (like proper target encoding with cross-validation). I don’t think this is the most elegant solution, but for now, it works for me.
Kezdeném azzal, hogy minden kódomat mappákba rendezném és írnám egy rövid dokumentációt (miért, mit, hogyan csináltam és az eredmény).
Lehetséges egy ilyen rövid idő alatt elkészíteni egy MVP-t nulláról, vagy minden résztvevő kész megoldásokkal érkezik?
Csak a datascience projektekre tudok vonatkoztatni — igen, lehetséges. Az MVP számomra két tényező összességét jelenti:
- Egy életképes ötlet, amely termékként van bemutatva (azaz van egy kidolgozott üzleti modell). Mindig világos megértése kell lennie annak, hogy miért és kinek készítjük a terméket. Néha a jól megalapozott projektek, de prototípus nélkül nyerik a díjakat, és ebben nincs semmi meglepő. Sajnos sok résztvevő nem tudja leválasztani magát a vereség keserűségéről, és a kudarcukat a szervezők rövidlátására hárítja, miközben értelmetlen modellekre dolgoznak a következő hackathonokon.
- Valamilyen jelzés arra, hogy ezt a terméket meg tudjátok valósítani (alkalmazás, kód, a folyamatok leírása).
Előfordul, hogy a hackathonra érkező csapat kész megoldással érkezik, és azt próbálja "igazítani" a szervezők feladatához. Az ilyen csapatokat a technikai szűrés során elutasítják, vagy csak az kerül elszámolásra, amit a helyszínen készítettek el. Nem láttam az ilyen csapatokat a győztesek között, de azt gondolom, nekik így is megéri menni, a jövőbeli érték miatt ().
Vannak példák arra, hogy a hackathonokon készült dolgokat eljuttatták a termelésig/startupig?
Igen. Három olyan esetem volt, amikor eljutottak a termelésig. Egyszer én magam, két alkalommal — mások keze által a saját ötleteim és az általam a hackathonon írt kód alapján. Tudok még néhány csapatról, akik konzultációs szolgáltatásokkal folytatták a céggel a kapcsolatot. A végső eredményeket nem ismerem, de valószínűleg valami elkészült. Magam nem alapítottam startupokat, de tudom, hogy valaki csinált ilyet, bár biztos vagyok benne, hogy vannak példák.
Miután sok hackathonon részt vettem, milyen tanácsot adnál magadnak, ha visszamehetnél az időben?
- A taktika fontosabb a manővereknél. Minden döntést úgy képzelj el, mint kész terméket. Az ötlet, a Jupiter notebook, az algoritmus semmit sem ér, ha nem világos, ki fog ezért fizetni.
- Mielőtt bármilyen tervezéssel foglalkozol, ne azt kérdezd, hogy "mi?", hanem azt, hogy "miért?" és "hogyan?" Példa: egy ML megoldás tervezésekor először gondolj az ideális algoritmusra: mit kap bemenetként, és hogyan használják fel a továbbiakban a predikcióit?
- Csatlakozz a csapathoz.
Általában mivel etetik a hackathonokon?
A hackathonokon általában rossz minőségű ételt szolgálnak fel: pizza, energiaitalok, üdítők. Szinte mindig büfé formájában kínálják az ételt, amelyhez óriási sorok alakulnak ki. Éjszaka általában nincs étkezés, bár volt egy eset Párizsban, ahol éjszakára hátrahagytak valamit — chipset, fánkot és kólát. El tudom képzelni a szervezők gondolkodását: "Na, mit esznek a programozók? Igen, persze! Csipsz, fánk — ez pont elég lesz. Adjuk nekik ezt a vacakot." Másnap megkérdeztem a szervezőket: "Srácok, nem lehetne éjszakára valami mást csinálni? Mondjuk kását?" Ekkor idiótának néztek. A francia vendégszeretet híres.
A jó hackathonokon ételt rendelnek dobozokban, van különbség a normál, vegetáriánus és kóser étrend között. Plusz, hűtőt állítanak fel joghurtokkal, müzlivel — azok számára, akik szeretnének nasizni. Tea, kávé, víz — alapvető ellátmány. Emlékezetes hackathon volt a Hack Moscow 2, ahol szívélyesen tápláltak borscsot és húsgombócokat pürével az 1C iroda éttermében.
A hackathonok észlelhetősége, úgy mondanám, a szervezők szakmai szférájától függ (például a legjobb hackathonokat tanácsadók szervezik)?
A legjobban azoktól a szervezőktől rendeztek hackathonokat, akik előzőleg már szerveztek hackathonokat, vagy korábban részt vettek rajtuk. Azt hiszem, ez az egyetlen tényező, ami meghatározza az esemény minőségét.
Hogyan tudhatod, hogy nem kezdő vagy, és itt az ideje egy hackathonra?
A legjobb időpont, hogy elindulj egy hackatonra — egy évvel ezelőtt volt. A második legjobb időpont — most van. Szóval menj neki, hibázz, tanulj — ez normális. Még a neurális hálózat — az ember legnagyobb találmánya a kerék és a döntési fák felett álló gradiens növelés után — sem tudja megkülönböztetni a macskát a kutyától az első tanulási korszakban.
Mik azok a "piros zászlók", amelyek azonnal jelzik, hogy az esemény nem lesz túl jó, és nem érdemes időt tölteni vele?
- Pontos világos leírás arról, mit kell tenni (aktuális produktív hackathonok számára). Ha a regisztráció során egyértelműen megfogalmazzák a feladatot, akkor jobb, ha otthon maradsz. A tapasztalataim alapján nem volt egyetlen jó hackathon sem, ahol volt előre meghatározott feladat. Például: Jól van — csinálj nekünk valamit, ami az audio beszélgetések elemzésével kapcsolatos. Rosszul van — csinálj egy alkalmazást, amely képes a beszélgetést két külön hangcsatornára osztani, minden ember számára.
- Kicsi nyereményalap. Ha azt kérik, hogy készíts “tindert online bolt számára AI támogatással” és az első helyezett díja 500 euró, valamint minimális csapatlétszám 5 fő — akkor valószínűleg nem érdemes időt pazarolni (igen, ez egy valós hackathon volt, amit Münchenben tartottak).
- Adatok hiánya (aktuális adat tudományos hackathonok számára). A szervezők általában alapvető információkat adnak meg a rendezvényről és néha egy minta adatállományt. Ha nem biztosítják — kérdezd meg, nem veszítesz vele. Ha 2-3 különböző, nem világos adatot ígérnek, és azt sem tudni, hogy kapunk-e egyáltalán valamit — ez piros zászló.
- Új szervezők. Ne légy lusták, és keress rá az hackathon szervezőire. Ha először csinálnak ilyen jellegű eseményt — nagy valószínűséggel valami el fog romlani. Másrészről, ha a szervező és a zsűri tagjai már szerveztek hackathonokat, vagy a múltban aktívan részt vettek — ez zöld zászló.
Egy hackathonon azt mondták nekem: „Neked volt a legjobb megoldás a pontozás alapján, de sajnálom, a csapatmunkát értékeljük, te pedig egyedül dolgoztál. Ha hoztál volna a csapatba egy diákot vagy egy lányt...” Megtapasztaltad ilyen igazságtalanságot? Hogyan birkóztál meg vele?
Igen, tapasztaltam, és nem egyszer. Stoikus módon viszonyulok az eseményekhez: megtettem, ami tőlem tellett, ha nem sikerült — hát így jártunk.
Miért foglalkozol mindezzel?
Mindössze unalomból.
Forrás: habr.com
