Ostatnia część trylogii o hackathonach. W opowiedziałem o motywacji do uczestnictwa w takich wydarzeniach. poświęcona była błędom organizatorów i ich skutkom. Ostatnia część odpowie na pytania, które nie zmieściły się w dwóch pierwszych częściach.
Opowiedz, jak zacząłeś uczestniczyć w hackathonach.
Uczyłem się na magisterskich studiach na Uniwersytecie Lappeenranta, jednocześnie biorąc udział w konkursach analizy danych. Mój typowy dzień wyglądał następująco: pobudka o 8, kilka zajęć na uczelni, a potem konkursy i kurs do północy (podczas gdy moja praca jest oceniana, oglądam wykłady lub czytam artykuły). Taki intensywny harmonogram przyniósł efekty, i wygrałem konkurs analizy danych MERC-2017 (o czym nawet był ). Zwycięstwo dodało mi pewności siebie, a gdy przypadkowo natknąłem się na informację o hackathonie SkinHack 2 w Moskwie, postanowiłem odwiedzić rodziców i jednocześnie sprawdzić, co to jest — hackathon.
Sam hackathon był dość zabawny. Były dwa tory analizy danych z wyraźnymi metrykami i zestawem danych z nagrodami po 100k rubli. Trzeci tor był poświęcony tworzeniu aplikacji z nagrodą 50k, w którym nie było uczestników. W pewnym momencie organizator powiedział, że okno z przyciskiem bez funkcjonalności może wygrać 50k, ponieważ nagroda nie może zostać niewypłacona. Nie zdecydowałem się uczyć programowania aplikacji (nie rywalizuję tam, gdzie mogę zostać łatwo "przewrócony"), ale dla mnie to była jasna wiadomość, że pola w hackathonach nie są zajęte.
Wtedy rozwiązywałem oba tory analizy danych sam. Znalazłem pretekst w danych, który pozwalał zdobyć idealny wynik, ale kolumny z pretekstem nie było w testowych danych, które otrzymałem na dwie godziny przed końcem wydarzenia (swoją drogą, wtedy rozumiałem, że obecność kolumny "target" w zbiorze treningowym nie jest uznawana za pretekst). W tym samym czasie otworzyła się tabela liderów, mój wynik bez pretekstu zajmował trzecie miejsce z pięciu, do pierwszego był duży dystans, więc postanowiłem nie tracić czasu i wyjechałem.
Po przeanalizowaniu tego, co się wydarzyło, znalazłem mnóstwo błędów (jedną z moich przyzwyczajeń jest mentalne przewijanie tego, co się wydarzyło, z notatnikiem i analizowanie błędów, ich przyczyn oraz tego, co można było zmienić — to miłe dziedzictwo półprofesjonalnej gry w pokera). Ale jedno było pewne — hackathony mają dużo wartości i po prostu muszę to zrealizować. Po tym zdarzeniu zacząłem monitorować wydarzenia i grupy, a kolejne hackathony nie kazały na siebie długo czekać. Potem jeszcze jeden, i jeszcze…
Dlaczego zajmujesz się hackathonami, a nie Kaggle?
W tej chwili nie interesuje mnie Kaggle. Z określonego poziomu umiejętności, bez specyficznych powodów uczestnictwa, Kaggle staje się mniej użyteczne niż inne aktywności. Dużo wcześniej w nim uczestniczyłem, najwyraźniej udało mi się jakoś „zdjąć się” z tego.
Dlaczego hackathony, a nie praca nad własnym projektem?
Podoba mi się idea stworzenia czegoś fajnego własnymi rękami w wolnym tempie. Chłopaki z ODS zorganizowali dla wszystkich, którzy chcą w weekendy pracować nad swoim projektem w gronie podobnie myślących. Myślę, że wkrótce do nich dołączę.
Jak znajdujesz wydarzenia?
Głównym źródłem jest hackathon.com (świat) i czat na Telegramie (Rosja). Ponadto zapowiedzi wydarzeń pojawiają się w reklamach w mediach społecznościowych i na LinkedIn. Jeśli nic nie znaleźliśmy, można spojrzeć tutaj: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Czy przygotowujesz plan rozwiązania przed uczestnictwem, czy wszystko rozwiązuje się na bieżąco? Na przykład tydzień przed hackathonem myślisz: „Będzie potrzebny taki a taki specjalista, trzeba poszukać”?
Jeśli hackathon jest produktowy — tak, przygotowuję się. Kilka tygodni przed wymyślam, co będę robić, przewiduję, kto może się przydać, zbieram zespół z przyjaciół lub uczestników poprzednich hackathonów.
Czy można naprawdę zhakować hackathon samotnie? Co robić, jeśli nie ma zespołu?
Hackathony Data Science są rzeczywiście — jestem żywym przykładem, jeśli chodzi o produktowe — nie widziałem, chociaż też tak myślę, że tak. Niestety, czasami organizatorzy nakładają ograniczenia dotyczące minimalnej liczby uczestników w zespole. Uważam, że wynika to z faktu, że nie wszyscy „samotnicy” docierają do finału (tzn. po prostu rezygnują przy pierwszych trudnościach), udział w zespole jednak zatrzymuje. Ponadto po wydarzeniu zakłada się, że nadal będziesz pracować nad projektem. Z zespołem będzie łatwiej doprowadzić projekt do perfekcji.
Ogólnie polecam zawsze brać udział w zespole. Jeśli nie masz własnego zespołu, organizatorzy zawsze pomogą znaleźć lub stworzyć jeden.
Jak radzić sobie z zmęczeniem podczas hackathonu?
Na hackathonie masz 2 dni na pracę, to 48 godzin (30-48 godzin, weźmy 48 dla uproszczenia rachunku). Odejmujemy czas na sen (16-20 godzin), zostaje nie więcej niż 30. Z tego na produktywną pracę przeznaczymy około 8 godzin (przeciętnie). Jeśli dobrze zorganizujesz pracę (sen, odżywianie, spacer na świeżym powietrzu, ćwiczenia, chwile uważności, prawidłowa komunikacja z zespołem i zmiana aktywności), to godziny intensywnej pracy można zwiększyć do 12-14. Po takiej pracy poczujesz się wyczerpany, ale to będzie przyjemne zmęczenie. Kodowanie bez snu i przerwy, opierając się na energetykach — to droga do porażki.
Czy masz swoje gotowe pipeline'y na hackathony? Jak one się u Ciebie pojawiły, jak są zorganizowane (czy pliki .py leżą w folderach, każdy dla swojego zadania itp.) i jak zacząć tworzyć takie samemu?
Nie używam w pełni gotowych rozwiązań z poprzednich hackathonów w nowych, ale mam swoje modele i pipe'y z minionych zawodów. Nie muszę przepisywać standardowych fragmentów od zera (na przykład właściwe target encoding czy prostą sieć do wyodrębniania intencji z tekstu), co oszczędza mi dużo czasu.
Obecnie wygląda to tak: dla każdego konkursu lub hackathonu mam swoje repozytorium na GitHubie, w którym przechowywane są notatniki, skrypty i krótka dokumentacja o tym, co się dzieje. Dodatkowo mam oddzielne repozytorium dla różnych pudełkowych „ficzerów” (jak właściwe target encoding z cross-validation). Nie sądzę, że to najbardziej eleganckie rozwiązanie, ale na razie mi odpowiada.
Zacząłbym od uporządkowania całego swojego kodu w folderach i napisania krótkiej dokumentacji (dlaczego, co, jak robiłem i jaki był wynik).
Czy w takim krótkim czasie rzeczywiście można przygotować MVP od zera, czy wszyscy uczestnicy przychodzą z gotowymi rozwiązaniami?
Mogę powiedzieć jedynie o projektach związanych z data science — tak, to możliwe. MVP dla mnie to połączenie dwóch czynników:
- Wykonalny pomysł przedstawiony jako produkt (tj. opisany model biznesowy). Zawsze musi istnieć jasne zrozumienie, dlaczego i dla kogo tworzymy produkt. Czasami projekty z dobrze uzasadnionym pomysłem, ale bez prototypu zdobywają nagrody, co nie jest niczym zaskakującym. Niestety, wielu uczestników nie potrafi oderwać się od goryczy porażki i obwinia swoje niepowodzenia o krótkowzroczność organizatorów, kontynuując tworzenie modeli, które są niejasne dla kogokolwiek na następnych hackathonach.
- Jakiegoś rodzaju wskaźnik na to, że możesz stworzyć ten produkt (aplikacja, kod, opis pipeline'ów).
Czasami zdarza się, że na hackathon przychodzi zespół z gotowym rozwiązaniem i stara się "podpiąć" je do zadania organizatorów. Takie zespoły są odrzucane podczas technicznej weryfikacji, lub "liczy się" tylko ta część, którą zrobili na miejscu. Nie widziałem takich zespołów wśród zwycięzców, ale myślę, że i tak opłaca im się brać udział ze względu na przyszłą wartość ().
Czy są przykłady doprowadzania projektów realizowanych na hackathonach do produkcji/startupów?
Tak. Miałem trzy przypadki, kiedy doprowadziliśmy do produkcji. Raz sam, dwa razy — cudzymi rękami na podstawie moich pomysłów i kodu, który napisałem na hackathonie. Znam też dwie drużyny, które kontynuowały współpracę z firmą jako konsultanci. Nie znam ostatecznych wyników, ale prawdopodobnie coś zostało zrealizowane do końca. Sam nie organizowałem startupów i nie wiem, czy ktoś coś takiego robił, chociaż jest kilka przykładów, których jestem pewien.
Po uczestnictwie w wielu hackathonach, jakie porady dałbyś sobie, gdybyś mógł wrócić do przeszłości?
- Taktyka jest ważniejsza niż manewry. Traktuj każde rozwiązanie jak gotowy produkt. Pomysł, notebook Jupiter, algorytm nic nie warte, jeśli nie wiadomo, kto za to zapłaci.
- Zanim zaprojektujesz cokolwiek, odpowiedz sobie na pytanie nie „co?”, lecz „dlaczego?” i „jak?”. Przykład: projektując jakieś rozwiązanie ML, najpierw pomyśl o idealnym algorytmie: co on otrzymuje na wejściu, jak jego prognozy są wykorzystywane dalej?
- Dołącz do zespołu.
Co zwykle podają do jedzenia na hackathonach?
Zazwyczaj na hackathonach jedzenie jest słabe: pizze, napoje energetyczne, gazowane. Prawie zawsze jedzenie organizowane jest w formie bufetu (lub stołu wydawczego), przy którym tworzy się ogromna kolejka. W nocy zazwyczaj nie ma jedzenia, chociaż zdarzył się przypadek na jednym z konkursów w Paryżu, gdzie na noc pozostawiono do jedzenia — chipsy, pączki i colę. Wyobrażam sobie myślenie organizatorów: „Hmm, co jedzą programiści? A, tak! Chipsy, pączki — to wszystko. Dajmy im tę marnotrawę.” Następnego dnia zapytałem organizatorów: „Ludzie, czy nie można byłoby na noc zorganizować czegoś innego? Na przykład, owsianki?” Po tym spojrzeli na mnie jak na idiotę. Słynna francuska gościnność.
Na dobrych hackathonach jedzenie zamawiane jest w boxach, istnieje podział na zwykłe, wegetariańskie i koszerne posiłki. Dodatkowo stawia się lodówkę z jogurtami, musli — dla tych, którzy chcą coś przekąsić. Herbata, kawa, woda — standard. Zapamiętałem hackathon Hack Moscow 2 — tam pysznie nakarmili barszczem i kotletami z puree w stołówce biura 1C.
Racjonalność hackathonów zależy, że tak powiem, od branży organizatorów (na przykład, najlepsze hackatony organizują konsultanci)?
Najlepsze hackathonów były od organizatorów, którzy albo wcześniej organizowali hackatony, albo wcześniej uczestniczyli. Chyba to jedyny czynnik, od którego zależy jakość wydarzenia.
Jak zrozumieć, że nie jesteś nowicjuszem i pora na hackathon?
Najlepszy czas, aby pójść na hackathon — rok temu. Drugim najlepszym czasem — jest teraz. Więc śmiało, popełniaj błędy, ucz się — to normalne. Nawet sieć neuronowa — największe wynalazek ludzkości po kole i gradientowym boosting w drzewach — nie potrafi odróżnić kota od psa w pierwszej epoce uczenia.
Jakie "czerwone flagi" od razu mówią, że wydarzenie nie będzie zbyt dobre i nie warto tracić czasu?
- Szczegółowy opis tego, co należy zrobić (aktualne dla hackathonów produktowych). Jeśli podczas rejestracji jasno określisz zadanie, lepiej pozostać w domu. Z mojej pamięci nie było ani jednego dobrego hackathonu z pełnym dokumentem wymagań. Dla porównania: Dobrze — zróbcie nam coś związanego z analizą rozmów audio. Źle — zróbcie nam aplikację, która byłaby w stanie rozdzielić rozmowę na dwie oddzielne ścieżki dźwiękowe dla każdej osoby.
- Mały fundusz nagród. Jeśli proszą Cię o zrobienie 'Tindera dla sklepu internetowego z AI', a nagroda za pierwsze miejsce wynosi 500 euro przy minimalnym składzie zespołu 5 osób — lepiej nie tracić na to czasu (tak, to realny hackathon, który odbył się w Monachium).
- Brak danych (aktualne dla hackathonów związanych z danymi). Organizatorzy zazwyczaj dostarczają podstawowe informacje o wydarzeniu oraz czasami próbki zestawów danych. Jeśli nie dostarczyli — zapytaj, niczego nie stracisz. Jeśli za 2-3 dni nie będzie wiadomo, jakie dane będą dostarczone i czy w ogóle będą — to czerwony alert.
- Nowi organizatorzy. Nie wahaj się i poszukaj informacji o organizatorach hackathonu. Jeśli organizują tego rodzaju wydarzenie po raz pierwszy — istnieje duże prawdopodobieństwo, że coś pójdzie nie tak. Z drugiej strony, jeśli organizator i członkowie jury już prowadzili hackathony lub w przeszłości aktywnie uczestniczyli — to zielony sygnał.
Na jednym hackathonie powiedziano mi: 'Miałeś najlepsze rozwiązanie, ale przepraszam, oceniamy pracę zespołową, a Ty pracowałeś samodzielnie. Gdybyś miał ze sobą studenta lub dziewczynę…'? Czy spotkałeś się z taką niesprawiedliwością? Jak sobie z tym radziłeś?
Tak, często się z tym spotykałem. Odnoszę się do wszystkiego stoikowo: zrobiłem wszystko, co w mojej mocy, a jeśli się nie udało — trudno.
Dlaczego zajmujesz się tym wszystkim?
Robię to wszystko po prostu z nudów.
Źródło: habr.com
