QA : Hackathons

La dernière partie de la trilogie sur les hackathons. Dans de la première partie j'ai parlé de la motivation à participer à de tels événements. La deuxième partie était consacrée aux erreurs des organisateurs et leurs conséquences. La dernière partie répondra aux questions qui n'ont pas pu être traitées dans les deux premières parties.

Raconte comment tu as commencé à participer aux hackathons.
J'étais étudiant en master à l'Université de Lappeenranta tout en participant à des compétitions d'analyse de données. Ma journée typique se déroulait comme suit : réveil à 8 heures, quelques cours à l'université, puis des compétitions et des MOOCs jusqu'à minuit (pendant que mon soumission est considérée, je regarde des cours ou lis des articles). Ce programme exigeant a porté ses fruits et j'ai remporté la compétition d'analyse de données MERC-2017 (à ce sujet, il y a eu même un post sur Habr). La victoire m'a donné confiance en moi, et quand je suis tombé par hasard sur des informations concernant le hackathon SkinHack 2 à Moscou, j'ai décidé de rendre visite à mes parents et d'en apprendre davantage sur ce qu'est un hackathon.

Le hackathon en lui-même a été assez amusant. Il y avait deux pistes d'analyse de données avec des métriques claires et des ensembles de données, avec des prix de 100 000 roubles. La troisième piste était le développement d'applications, avec un prix de 50 000, et il n'y avait pas de participants. À un moment donné, l'organisateur a déclaré qu'une fenêtre avec un bouton non fonctionnel pouvait gagner 50 000, car le prix ne pouvait pas rester non attribué. Je n'ai pas voulu apprendre à programmer des applications (je ne me mesure pas là où je peux être facilement

surclassé”), mais pour moi, c'était un message clair que les champs dans les hackathons ne sont pas saturés. À ce moment-là, je travaillais seul sur les deux pistes d'analyse de données. J'ai trouvé un biais dans les données qui me permettait d'obtenir un score parfait, mais la colonne avec le biais n'était pas dans les données de test que j'ai reçues deux heures avant la fin de l'événement (à propos, à ce moment-là, je comprenais que la présence de la colonne "cible" dans l'entraînement n'était pas considérée comme un biais). En même temps, le tableau de classement s'est ouvert, ma soumission sans biais occupait la troisième place sur cinq, il y avait un grand écart avec le premier, et j'ai décidé de ne pas perdre de temps et je suis parti.

Après avoir analysé calmement ce qui s'est passé, j'ai trouvé de nombreuses erreurs (une de mes habitudes est de passer en revue mentalement ce qui s'est passé avec un carnet et d'analyser les erreurs, leur cause et ce qui aurait pu être changé - un joli vestige de mon jeu semi-professionnel au poker). Mais une chose était claire : les hackathons ont beaucoup de valeur, et je dois absolument en tirer parti. Après cet événement, j'ai commencé à suivre les événements et les groupes, et le prochain hackathon n'a pas tardé à arriver. Puis un autre, et encore un...

Pourquoi tu t'occupes des hackathons et pas des Kaggle?
En ce moment, je n'aime pas Kaggle. À un certain niveau de compétences, sans raisons spécifiques de participation, Kaggle devient moins utile que d'autres activités. J'ai beaucoup participé auparavant, il semblerait que j'ai réussi à 'me désaccoutumer'.

Pourquoi les hackathons et pas travailler sur ton propre projet?
L'idée de créer quelque chose de chouette de mes propres mains à un rythme tranquille me plaît. Les gars d'ODS ont organisé des projets personnels ODS pour tous ceux qui souhaitent travailler sur leur projet pendant le week-end avec des personnes partageant les mêmes idées. Je pense que je vais bientôt les rejoindre.

Comment trouves-tu les événements?
La principale source est hackathon.com (monde) et le chat Telegram Russian Hackers (Russie). De plus, des annonces d'événements apparaissent dans la publicité sur les réseaux sociaux et sur LinkedIn. Si tu ne trouves rien, tu peux regarder ici : mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.

Prépares-tu un plan de solution avant de participer ou tout se décide sur le tas ? Par exemple, une semaine avant le hackathon, tu envisages : « Je vais avoir besoin d'un tel et tel spécialiste, je dois chercher »?
Si le hackathon est orienté produit, oui, je me prépare. Quelques semaines avant, je conçois ce que je vais faire, je réfléchis à qui pourrait être utile, je forme une équipe avec des amis ou des participants de hackathons précédents.

Est-il vraiment possible de hacker un hackathon en solo ? Que faire si tu n'as pas d'équipe ?
Les hackathons de data science sont tout à fait réels (je suis un exemple vivant), mais je n'ai pas vu de hackathons produits, bien que je pense aussi que cela existe. Malheureusement, les organisateurs imposent parfois une limite au nombre minimum de participants dans une équipe. Je pense que cela est dû au fait que tous les "solitaires" ne parviennent pas à la finale (c'est-à-dire qu'ils abandonnent simplement aux premiers obstacles), la participation en équipe aide tout de même à maintenir l'engagement. De plus, après l'événement, il est prévu que vous continuiez à travailler sur le projet. Avec une équipe, il sera plus facile de peaufiner le projet.

Dans l'ensemble, je conseille toujours de participer en équipe. Si vous n'avez pas votre propre équipe, les organisateurs vous aideront toujours à en trouver une ou à en créer une.

Comment gérez-vous la fatigue pendant un hackathon ?
Un hackathon dure 2 jours, soit 48 heures (30-48 heures, prenons 48 pour simplifier le calcul). Enlevons le temps de sommeil (16-20 heures), il vous reste pas plus de 30. Parmi ceux-ci, vous pourrez réellement travailler de manière productive environ 8 heures (en moyenne). Si vous organisez correctement votre travail (sommeil, alimentation, sortie à l'air frais, pauses, moments de pleine conscience, bonne communication avec l'équipe et changement d'activité), vous pouvez porter vos heures de travail intense à 12-14. Après un tel travail, vous vous sentirez épuisé, mais ce sera une fatigue agréable. Coder sans sommeil et sans pauses en se gavant d'énergétiques mène à l'échec.

As-tu tes propres pipelines prêts pour les hackathons ? Comment sont-ils apparus, comment sont-ils organisés (les fichiers .py sont rangés dans des dossiers, chacun pour sa propre tâche, etc.) et comment commencer à en créer soi-même ?
Je n'utilise pas entièrement les solutions prêtes des hackathons précédents pour les nouveaux, mais j'ai mon propre zoo de modèles et de pipelines issus de concours passés. Je n'ai pas besoin de réécrire des morceaux standards depuis le début (par exemple, un encodage correct des cibles ou un simple modèle pour extraire des intentions du texte), ce qui me fait gagner beaucoup de temps.

Actuellement, cela ressemble à ceci : pour chaque compétition ou hackathon, il y a un dépôt spécifique sur GitHub, où sont stockés des notebooks, des scripts et une petite documentation sur ce qui se passe. De plus, il y a un dépôt séparé pour diverses "caractéristiques" prêtes à l'emploi (comme l'encodage correct des cibles avec validation croisée). Je ne pense pas que ce soit la solution la plus élégante, mais pour l'instant, cela me convient.

Je commencerais par organiser tout mon code en dossiers et en rédigeant une documentation succincte (pourquoi, quoi, comment j'ai fait et le résultat).

Est-il vraiment possible de préparer un MVP à partir de zéro en si peu de temps, ou tous les participants viennent-ils avec des solutions déjà prêtes ?
Je ne peux parler que des projets liés à la data science — oui, c'est possible. Pour moi, un MVP est une combinaison de deux facteurs :

• Une idée viable présentée sous forme de produit (c'est-à-dire un business canvas établi). Il doit toujours y avoir une compréhension claire de pourquoi et pour qui nous créons le produit. Parfois, des projets avec un concept bien élaboré, mais sans prototype, remportent des prix, et ce n'est pas surprenant. Malheureusement, de nombreux participants ne peuvent pas s'abstraire de l'amertume de la défaite et attribuent leurs échecs à la myopie des organisateurs, continuant à développer des modèles pour un public indéfini lors des prochains hackathons.
• Une certaine preuve que vous pouvez réaliser ce produit (application, code, description des pipelines).

Il arrive qu'une équipe arrive avec une solution prête et essaie de l'adapter à la tâche des organisateurs. Ces équipes sont écartées lors du screening technique, ou seule la partie qu'elles ont réalisée sur place compte. Je n'ai pas vu ces équipes parmi les gagnants, mais je pense qu'elles continuent quand même à participer à cause de la valeur future (contacts, ensembles de données, etc.).

Y a-t-il des exemples de projets réalisés lors de hackathons qui sont devenus des productions/startups ?
Oui. J'ai eu trois cas où des projets ont été menés à terme. Une fois moi-même, deux fois — par d'autres personnes sur la base de mes idées et du code que j'ai écrit lors du hackathon. Je connais aussi quelques équipes qui ont continué à collaborer avec une entreprise en tant que consultants. Je ne connais pas les résultats finaux, mais il est probable que quelque chose a été réalisé jusqu'à la fin. Je n'ai jamais organisé de startups et je ne sais pas si d'autres l'ont fait, bien que je sois sûr qu'il existe des exemples.

Après avoir participé à de nombreux hackathons, quels conseils te donnerais-tu si tu pouvais revenir dans le passé ?

1. La tactique est plus importante que les manœuvres. Considère chaque décision comme un produit prêt. Une idée, un notebook Jupyter, un algorithme ne valent rien si on ne sait pas qui va payer pour cela.
2. Avant de concevoir quoi que ce soit, pose-toi les questions non pas « quoi ? », mais « pourquoi ? » et « comment ? ». Par exemple : en concevant une solution ML, réfléchis d'abord à l'algorithme idéal : que reçoit-il en entrée, comment ses prédictions sont-elles utilisées par la suite ?
3. Participe à l'équipe.

Qu'est-ce qu'on sert généralement lors des hackathons ?
En général, la nourriture lors des hackathons est médiocre : pizzas, boissons énergétiques, sodas. La nourriture est presque toujours présentée sous forme de buffet (ou de table de distribution) devant laquelle se forme une longue file d'attente. La nuit, il n'y a généralement pas de nourriture, bien qu'il y ait eu un cas lors d'une compétition à Paris où ils avaient laissé des collations pour la nuit — chips, beignets et cola. Je peux imaginer le processus de réflexion des organisateurs : « Alors, qu'est-ce que mangent les programmeurs ? Ah, bien sûr ! Chips, beignets — voilà qui leur plaira. Mettons-leur ça. » Le lendemain, j'ai demandé aux organisateurs : « Les gars, ne pourrait-on pas prévoir autre chose pour la nuit ? Par exemple, de la bouillie ? » Après cela, ils m'ont regardé comme un idiot. Le célèbre accueil français.

Lors des bons hackathons, la nourriture est commandée dans des box, avec des options pour les régimes standard, végétarien et casher. De plus, ils installent un réfrigérateur avec des yaourts, des mueslis — pour ceux qui veulent grignoter. Thé, café, eau — c'est standard. Je me souviens d'un hackathon, Hack Moscow 2 — là-bas, ils nous ont bien nourris avec de la soupe borscht et des boulettes de viande avec de la purée dans la cantine du bureau 1C.

La pertinence des hackathons dépend, en quelque sorte, du domaine professionnel des organisateurs (par exemple, les meilleurs hackathons sont organisés par des consultants) ?
Les meilleurs hackathons étaient organisés par ceux qui avaient soit déjà organisé des hackathons auparavant, soit avaient déjà participé. C'est probablement le seul facteur qui conditionne la qualité de l'événement.

Comment savoir que tu n'es pas un débutant et qu'il est temps de te rendre à un hackathon ?
Le meilleur moment pour participer à un hackathon était il y a un an. Le deuxième meilleur moment, c'est maintenant. Alors n'hésite pas, fais des erreurs, apprends — c'est normal. Même un réseau de neurones — la plus grande invention de l'homme après la roue et le gradient boosting sur arbres — ne peut pas différencier un chat d'un chien lors de la première époque d'apprentissage.

Quels « drapeaux rouges » indiquent immédiatement que l'événement ne sera pas très bon et qu'il ne vaut pas la peine d'y consacrer du temps ?

• Une description claire de ce qu'il faut faire (pertinente pour les hackathons de produit). Si, lors de l'inscription, un objectif est clairement défini pour vous, il vaut mieux rester chez soi. À ma connaissance, il n'y a pas eu un seul bon hackathon avec un cahier des charges. Pour comparer : Bien — faites-nous quelque chose lié à l'analyse de conversations audio. Mal — faites-nous une application capable de séparer une conversation en deux pistes audio distinctes pour chaque personne.
• Petit prix de récompense. Si on vous demande de créer un "Tinder pour une boutique en ligne avec de l'IA" et que le prix pour la première place est de 500 euros avec une taille minimale d'équipe de 5 personnes, il vaut mieux ne pas perdre de temps (oui, c'est un hackathon réel qui s'est tenu à Munich).
• Absence de données (pertinent pour les hackathons de data science). Les organisateurs fournissent généralement des informations de base sur l'événement et parfois un échantillon de jeu de données. S'ils ne l'ont pas fourni, demandez-le, cela ne vous coûtera rien. Si pendant 2-3 jours, les données à fournir ne sont pas claires et s'il y en aura réellement — c'est un drapeau rouge.
• Nouveaux organisateurs. Ne vous laissez pas décourager et faites des recherches sur les organisateurs du hackathon. S'ils organisent ce type d'événement pour la première fois, il y a de fortes chances que quelque chose ne se passe pas bien. En revanche, si l'organisateur et les membres du jury ont déjà organisé des hackathons ou y ont participé activement dans le passé — c'est un drapeau vert.

Lors d'un hackathon, on m'a dit : « Tu avais la meilleure solution en termes de score, mais désolé, nous évaluons le travail en équipe, et tu as travaillé seul. Si seulement tu avais pris un étudiant ou une fille dans ton équipe… » As-tu déjà rencontré une telle injustice ? Comment t'en es-tu sorti ?
Oui, j'en ai rencontré et pas qu'une fois. J'aborde tout cela avec stoïcisme : j'ai fait tout ce qui était en mon pouvoir, si cela n'a pas fonctionné — tant pis.

Pourquoi t'engages-tu dans tout ça ?
Tout cela, c'est simplement par ennui.

Source : habr.com