Parte finale della trilogia sui hackathon. In ho parlato della motivazione a partecipare a questi eventi. era dedicata agli errori degli organizzatori e ai loro risultati. La parte conclusiva risponderà alle domande che non sono rientrate nelle prime due parti.
Racconta come hai iniziato a partecipare agli hackathon.
Studiavo nel Master dell'Università di Lappeenranta mentre partecipavo a competizioni di analisi dei dati. La mia giornata tipica era così: sveglia alle 8, alcune lezioni all'università, poi competizioni e corsi fino a mezzanotte (mentre aspetto la scadenza, guardo lezioni o leggo articoli). Questa dura programmazione ha dato i suoi frutti, e ho vinto la competizione di analisi dei dati MERC-2017 (di cui c'era anche un ). La vittoria mi ha dato fiducia in me stesso, e quando mi sono casualmente imbattuto nelle informazioni sul hackathon SkinHack 2 a Mosca, ho deciso di andare a trovare i miei genitori e allo stesso tempo scoprire di cosa si trattasse — un hackathon.
L'hackathon in sé è stato piuttosto divertente. C'erano due tracce di analisi dei dati con metriche chiare e un dataset con premi di 100k rubli. La terza traccia riguardava lo sviluppo di applicazioni con un premio di 50k, e in essa non c'erano partecipanti. A un certo punto, l'organizzatore ha detto che una finestra con un pulsante senza funzionalità poteva vincere 50k, perché il premio non poteva non essere pagato. Non ho voluto imparare a programmare applicazioni (non gareggio dove potrei essere facilmente 'sbaragliato'), ma per me questo è stato un chiaro messaggio che i campi negli hackathon non erano affollati.
Allora stavo affrontando entrambe le tracce di analisi dei dati da solo. Ho trovato un loophole nei dati che permetteva di ottenere un punteggio ideale, ma la colonna con il loophole non era nei dati di test, che ho ricevuto due ore prima della fine dell'evento (a proposito, allora capivo che la presenza di una colonna 'target' nel training non viene considerata un loophole). Nel frattempo si è aperta la leaderboard, il mio submission senza loophole occupava il terzo posto su cinque, c'era un grande distacco dal primo e ho deciso di non perdere tempo e sono partito.
Dopo aver analizzato con calma cosa è successo, ho trovato un sacco di errori (una delle mie abitudini è rivedere mentalmente ciò che è accaduto con un blocco note e analizzare gli errori, le loro cause e cosa avrei potuto cambiare — un'eredità piacevole del gioco semi-professionale a poker). Ma una cosa era chiara: nei hackathon c'è molto valore, e devo assolutamente realizzarlo. Dopo questo evento, ho iniziato a monitorare eventi e gruppi, e il successivo hackathon non ha tardato ad arrivare. Poi un altro, e un altro ancora…
Perché partecipi agli hackathon e non a Kaggle?
Al momento non mi interessa Kaggle. A un certo livello di abilità, senza motivazioni specifiche per partecipare, Kaggle diventa meno utile rispetto ad altre attività. Ho partecipato molto in passato, a quanto pare, sono riuscito a "staccarmi" in qualche modo.
Perché hackathon e non lavorare al proprio progetto?
Mi piace l'idea di creare qualcosa di straordinario con le mie mani a un ritmo non frenetico. I ragazzi di ODS hanno organizzato per tutti coloro che vogliono lavorare ai propri progetti durante il fine settimana con persone che la pensano allo stesso modo. Penso che presto mi unirò a loro.
Come trovi gli eventi?
La mia fonte principale è hackathon.com (globale) e il gruppo su Telegram (Russia). Inoltre, gli annunci degli eventi compaiono nella pubblicità sui social e su LinkedIn. Se non trovi nulla, puoi dare un'occhiata qui: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Prepara un piano di soluzione prima di partecipare o decidi tutto al momento? Ad esempio, una settimana prima dell'hackathon pensi: «Avremo bisogno di uno specialista di questo tipo, dobbiamo cercare»?
Se l'hackathon è orientato al prodotto — sì, mi preparo. Diverse settimane prima penso a cosa farò, prendo in considerazione chi potrebbe essere utile, compongo un team di amici o partecipanti a hackathon precedenti.
È realmente possibile vincere un hackathon da solo? Cosa fare se non si ha una squadra?
I hackathon di data science sono reali (io sono un esempio vivente), quelli di prodotto — non ne ho visti, anche se penso di sì. Sfortunatamente, a volte gli organizzatori pongono un limite al numero minimo di partecipanti per team. Penso che questo sia dovuto al fatto che non tutti i 'solisti' arrivano in finale (cioè, semplicemente si ritirano alle prime difficoltà), la partecipazione in team però aiuta a mantenere alta la motivazione. Inoltre, dopo l'evento ci si aspetta che tu continui a lavorare sul progetto. Con un team è più facile portare il progetto a buon fine.
In generale, consiglio di partecipare sempre con un team. Se non hai il tuo team, gli organizzatori ti aiuteranno sempre a trovarne uno o a crearne uno.
Come riesci a gestire la stanchezza durante un hackathon?
In un hackathon hai 2 giorni per lavorare, cioè 48 ore (30-48 ore, prendiamo 48 per semplicità). Dobbiamo sottrarre il tempo per dormire (16-20 ore), quindi rimangono non più di 30 ore. Di queste, realmente per lavoro produttivo se ne utilizzeranno circa 8 (in media). Se organizzi bene il lavoro (sonno, alimentazione, uscire all'aria aperta, fare pause, momenti di consapevolezza, comunicazione corretta con il team e cambi di attività), puoi arrivare a 12-14 ore di lavoro concentrato. Dopo un lavoro del genere ti sentirai esausto, ma sarà una stanchezza piacevole. Scrivere codice senza dormire e senza pause, solo con energy drink, è un cammino verso il fallimento.
Hai dei tuoi pipeline pronti per gli hackathon? Come sono nati, come sono strutturati (file .py organizzati in cartelle, ognuno per il suo compito, ecc.) e come posso iniziare a crearne di miei?
Non utilizzo soluzioni già pronte da hackathon precedenti in quelli nuovi, ma ho il mio zoo di modelli e pipeline da competizioni passate. Non devo riscrivere pezzi standard da zero (come il corretto encoding targeting o una semplice rete per identificare l'intento nel testo), il che mi fa risparmiare molto tempo.
Attualmente sembra così: per ogni competizione o hackathon ho un proprio repository su GitHub, in cui sono conservati i notebook, gli script e una piccola documentazione su ciò che sta accadendo. Inoltre, ho un repository separato per varie 'chicche' confezionate (come il corretto encoding targeting con cross-validazione). Non penso sia la soluzione più elegante, ma per ora mi va bene.
Inizierei con l'organizzazione di tutto il mio codice in cartelle e con la scrittura di una breve documentazione (perché, cosa, come ho fatto e il risultato).
È possibile preparare un MVP da zero in un tempo così breve o tutti i partecipanti arrivano con soluzioni pronte?
Posso parlare solo dei progetti legati al data science — sì, è possibile. Per me, l'MVP è un insieme di due fattori:
- Un'idea valida presentata come prodotto (cioè con un business canvas). Deve sempre esserci una chiara comprensione del perché e per chi stiamo creando il prodotto. A volte, progetti con una proposta ben argomentata, ma senza prototipo, vincono premi, e non c'è nulla di sorprendente. Purtroppo, molti partecipanti non riescono a distaccarsi dall'amarezza della sconfitta e attribuiscono i loro insuccessi alla mancanza di visione degli organizzatori, continuando a lavorare su modelli incomprensibili per chiunque nei successivi hackathon.
- Un certo indicatore che puoi realizzare questo prodotto (applicazione, codice, descrizione dei pipeline).
A volte, al hackathon arriva un team con una soluzione pronta e cerca di "adattarla" al compito degli organizzatori. Questi team vengono eliminati durante lo screening tecnico oppure si considera solo quella parte che hanno realizzato sul posto. Non ho visto team del genere tra i vincitori, ma penso che sia comunque vantaggioso per loro partecipare a causa del valore futuro ().
Ci sono esempi di progetti realizzati durante hackathon che sono stati portati in produzione/startup?
Sì. Ho avuto tre casi in cui sono stati portati in produzione. Una volta ho fatto tutto da solo, due volte - con il lavoro di altri basato sulle mie idee e sul codice che ho scritto all'hackathon. Conosco anche un paio di team che hanno continuato a collaborare con l'azienda in qualità di consulenti. Non conosco i risultati finali, ma probabilmente qualcosa è stato fatto fino alla fine. Non ho organizzato startup e non so di qualcuno che lo abbia fatto, anche se sono sicuro che ci siano esempi.
Dopo aver partecipato a molti hackathon, quali consigli daresti a te stesso se potessi tornare indietro nel tempo?
- La tattica è più importante delle manovre. Presenta ogni decisione come un prodotto finito. L'idea, il notebook Jupiter, l'algoritmo non valgono nulla se non è chiaro chi pagherà per tutto ciò.
- Prima di progettare qualcosa, rispondi alla domanda non “cosa?”, ma “perché?” e “come?”. Esempio: progettando una soluzione ML, prima di tutto pensa all'algoritmo ideale: quali dati riceve in input, come vengono utilizzate le sue previsioni successivamente?
- Partecipa al team.
Cosa si mangia di solito agli hackathon?
Di solito, il cibo agli hackathon è scarso: pizze, bevande energetiche, bibite. Quasi sempre il cibo è organizzato in stile buffet (o tavolo di distribuzione) con una lunga coda. Di notte di solito non si mangia, anche se c'è stato un caso in una competizione a Parigi in cui hanno lasciato da mangiare durante la notte — patatine, ciambelle e cola. Immagino il processo mentale degli organizzatori: “Ehi, cosa mangiano i programmatori? Ah, giusto! Patatine, ciambelle — questo basta. Mettiamo loro questa roba.” Il giorno dopo ho chiesto agli organizzatori: “Ragazzi, non si può fare qualcosa di diverso per la notte? Ad esempio, una zuppa?” Dopo di che mi hanno guardato come se fossi un idiota. Il famoso ospitalità francese.
Negli hackathon di qualità il cibo viene ordinato in scatole, con opzioni per pasti normali, vegetariani e kosher. Inoltre, mettono un frigorifero con yogurt e muesli — per chi desidera uno spuntino. Tè, caffè, acqua — sono standard. Ricordo l'hackathon Hack Moscow 2 — lì ci hanno sfamato bene con borscht e polpette con purè nella mensa dell'ufficio 1C.
La qualità degli hackathon dipende, potremmo dire, dal settore professionale degli organizzatori (ad esempio, i migliori hackathon sono organizzati dai consulenti)?
I migliori hackathon sono stati organizzati da persone che avevano già organizzato hackathon in precedenza o che avevano partecipato. Forse, questo è l'unico fattore che influisce sulla qualità dell'evento.
Come capire che non sei un principiante e che è ora di andare a un hackathon?
Il momento migliore per andare a un hackathon era un anno fa. Il secondo momento migliore è adesso. Quindi, agisci, sbaglia, impara — è normale. Anche una rete neurale — la più grande invenzione dell'umanità dopo la ruota e il boosting del gradiente sugli alberi — non riesce a distinguere un gatto da un cane durante la prima epoca di apprendimento.
Quali sono i “segnali rossi” che indicano subito che l'evento non sarà molto buono e che non vale la pena perdere tempo?
- Una chiara descrizione di cosa bisogna fare (rilevante per i hackathon di prodotto). Se al momento della registrazione ti viene posta chiaramente una missione, è meglio rimanere a casa. Non ricordo un solo hackathon di successo con un brief. Per confronto: Bene — fateci qualcosa relativo all'analisi delle conversazioni audio. Male — createci un'applicazione in grado di separare una conversazione in due tracce audio distinte per ogni persona.
- Un piccolo montepremi. Se ti chiedono di creare un "tinder per negozi online con AI" e il premio per il primo posto è di 500 euro con una squadra minima di 5 persone, probabilmente non vale la pena perdere tempo (sì, questo è un hackathon reale che si è svolto a Monaco).
- Mancanza di dati (rilevante per gli hackathon di data science). Gli organizzatori di solito forniscono le informazioni di base sull'evento e a volte un campione di dataset. Se non lo forniscono, chiedi, non hai nulla da perdere. Se in 2-3 nessuno sa quali dati saranno forniti e se saranno forniti affatto — è un segnale rosso.
- Nuovi organizzatori. Non essere pigro e cerca informazioni sugli organizzatori dell'hackathon. Se stanno organizzando un evento di questo tipo per la prima volta, c'è una grande possibilità che qualcosa vada storto. D'altra parte, se l'organizzatore e i membri della giuria hanno già condotto hackathon o hanno partecipato attivamente in passato — è un segnale verde.
A un hackathon mi hanno detto: «Avevi la migliore soluzione per punteggio, ma scusa, noi valutiamo il lavoro di squadra, e tu hai lavorato da solo. Se avessi portato un collaboratore o una ragazza...?». Hai mai trovato un'ingiustizia simile? Come hai reagito?
Sì, l'ho trovata e non solo una volta. Affronto tutto con stoicismo: ho fatto tutto ciò che era in mio potere, se non ha funzionato — così sia.
Perché ti interessi di tutto questo?
Tutto questo è semplicemente per noia.
Fonte: habr.com
