Parte final de la trilogía sobre hackatones. En compartí sobre la motivación para participar en tales eventos. estuvo dedicada a los errores de los organizadores y sus resultados. La parte final responderá a las preguntas que no se incluyeron en las dos primeras partes.
Cuéntame cómo comenzaste a participar en hackatones.
Estudié en la maestría de la Universidad de Lappeenranta mientras participaba en competiciones de análisis de datos. Mi día típico era así: despertarse a las 8, algunas clases en la universidad, luego competiciones y cursos hasta la medianoche (mientras se cuenta la entrega, veo conferencias o leo artículos). Este duro horario dio sus frutos, y gané la competición de análisis de datos MERC-2017 (de lo cual incluso hubo un ). La victoria aumentó mi confianza, y cuando me encontré por casualidad con información sobre el hackatón SkinHack 2 en Moscú, decidí visitar a mis padres y al mismo tiempo descubrir qué era eso — un hackatón.
El hackatón resultó ser bastante divertido. Hubo dos tracks de análisis de datos con métricas y un conjunto de datos claro, con premios de 100k rublos. El tercer track era de desarrollo de aplicaciones con un premio de 50k, pero no tuvo participantes. En un momento, el organizador dijo que una ventana con un botón sin funcionalidad podía ganar 50k, porque el premio no podía no ser entregado. No decidí aprender a programar aplicaciones (no compito donde fácilmente pueden 'voltearme'), pero para mí fue un mensaje claro de que los campos en los hackatones no estaban saturados.
En ese momento, estaba resolviendo ambos tracks de análisis de datos solo. Encontré un atajo en los datos que permitía obtener una puntuación perfecta, pero la columna con el atajo no estaba en los datos de prueba que recibí dos horas antes del final del evento (por cierto, en ese entonces entendí que la presencia de la columna 'target' en el entrenamiento no se considera un atajo). Al mismo tiempo, se abrió el leaderboard, mi entrega sin atajo ocupaba el tercer lugar de cinco, había una gran diferencia hasta el primero y decidí no perder tiempo y me fui.
Después de analizar con calma lo que sucedió, encontré un montón de errores (una de mis costumbres es repasar mentalmente lo que ocurrió con un cuaderno y analizar los errores, sus causas y qué se podría haber cambiado; un bonito legado de mi semi-profesionalismo en el póker). Pero una cosa estaba clara: en los hackatones hay mucho valor y simplemente debo aprovecharlo. Después de este evento, comencé a monitorear actividades y grupos, y el siguiente hackatón no se hizo esperar. Luego otro, y otro más...
¿Por qué te dedicas a los hackatones y no a Kaggle?
En este momento, no me gusta Kaggle. A partir de cierto nivel de habilidad, sin razones específicas para participar, Kaggle se vuelve menos útil que otras actividades. Participé mucho antes, parece que logré 'desengancharme' de alguna manera.
¿Por qué hackatones y no trabajar en tu propio proyecto?
Me atrae la idea de hacer algo genial con mis propias manos a un ritmo no tan acelerado. Los chicos de ODS organizaron para todos aquellos que quieren trabajar en su proyecto durante el fin de semana en compañía de personas afines. Creo que pronto me uniré a ellos.
¿Cómo encuentras eventos?
La fuente principal es hackathon.com (mundo) y un chat en Telegram (Rusia). Además, los anuncios de eventos aparecen en publicidad en redes sociales y en LinkedIn. Si no encuentras nada, puedes mirar aquí: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
¿Preparas un plan de solución antes de participar o todo se decide en el momento? Por ejemplo, ¿una semana antes del hackatón piensas: 'Necesitaré tal o cual especialista, tendré que buscar'?
Si el hackatón es de producto, sí, me preparo. Unas semanas antes, pienso en lo que voy a hacer, evalúo quién podría ser útil, y reúno un equipo de amigos o participantes de hackatones anteriores.
¿Es realmente posible hackear un hackatón solo? ¿Qué hacer si no tienes equipo?
Los hackatones de ciencia de datos son realmente efectivos (yo soy un ejemplo vivo), los productivos no los he visto, aunque también pienso que sí. Desafortunadamente, a veces los organizadores imponen un límite en el número mínimo de participantes por equipo. Creo que esto se debe a que no todos los 'solitarios' llegan a la final (es decir, simplemente se rinden ante las primeras dificultades), la participación en un equipo, no obstante, ayuda a mantener el compromiso. Además, se espera que después del evento sigas trabajando en el proyecto. Con un equipo, será más fácil llevar el proyecto a buen término.
En general, siempre aconsejo participar en equipo. Si no tienes tu propio equipo, los organizadores siempre ayudan a encontrar o formar uno.
¿Cómo logras sobrellevar la fatiga durante un hackatón?
En un hackatón se tienen 2 días para trabajar, lo que son 48 horas (30-48 horas, tomemos 48 para simplificar los cálculos). Restamos el tiempo para dormir (16-20 horas), así que quedan no más de 30. De estos, realmente se pueden utilizar unas 8 horas para trabajo productivo (en promedio). Si se organiza bien el trabajo (sueño, alimentación, salir al aire libre, ejercicios, momentos de conciencia, una buena comunicación con el equipo y variar actividades), se pueden alcanzar de 12 a 14 horas de trabajo profundo. Después de un trabajo así, te sentirás agotado, pero será una fatiga placentera. Programar sin dormir y sin pausas, bebiendo energizantes, es un camino hacia el fracaso.
¿Tienes tus propios pipelines listos para hackatones? ¿Cómo los has creado, cómo están organizados (los archivos .py guardados en carpetas, cada uno para su tarea, etc.) y cómo empezar a crear tales por tu cuenta?
No utilizo soluciones completamente listas de hackatones anteriores en nuevos, pero tengo mi propio zoológico de modelos y pipelines de competiciones anteriores. No tengo que reescribir partes estándar desde cero (por ejemplo, un correcto target encoding o una red simple para identificar la intención en el texto), lo que me ahorra mucho tiempo.
En este momento se ve así: para cada competición o hackatón hay su propio repositorio en GitHub, donde se almacenan cuadernos, scripts y una pequeña documentación sobre lo que está sucediendo. Además, hay un repositorio separado para varias 'peculiaridades' empaquetadas (como un correcto target encoding con validación cruzada). No creo que sea la solución más elegante, pero por ahora me funciona.
Comenzaría por guardar todo mi código en carpetas y escribir una breve documentación (por qué, qué, cómo lo hice y el resultado).
¿Es realmente posible preparar un MVP desde cero en tan poco tiempo o todos los participantes llegan con soluciones ya preparadas?
Solo puedo hablar sobre proyectos relacionados con ciencia de datos: sí, es posible. Para mí, un MVP es la combinación de dos factores:
- Una idea viable presentada como producto (es decir, con un business canvas elaborado). Siempre debe haber una comprensión clara del porqué y para quién estamos creando el producto. A veces, proyectos con una propuesta bien fundamentada, pero sin prototipo, ganan premios, y no hay nada sorprendente en ello. Desafortunadamente, muchos participantes no pueden abstraerse del amargo sabor de la derrota y atribuyen sus fracasos a la miopía de los organizadores, continuando con modelos que no son claros para nadie en hackatones posteriores.
- Un indicador de que puedes hacer este producto (aplicación, código, descripción de pipelines).
A veces, llega un equipo a un hackatón con una solución lista y trata de 'ajustarla' al desafío de los organizadores. Tales equipos son descartados en el screening técnico o solo se considera la parte que hicieron en el evento. No he visto tales equipos entre los ganadores, pero creo que aún les resulta beneficioso asistir por el valor futuro ().
¿Hay ejemplos de proyectos desarrollados en hackatones que llegaron a producción/startup?
Sí. He tenido tres casos en los que se llevaron a producción. Una vez lo hice yo mismo, dos veces lo realizaron otros basándose en mis ideas y el código que escribí en el hackatón. También conozco un par de equipos que continuaron colaborando con la empresa como consultores. No sé los resultados finales, pero probablemente se hizo algo hasta el final. No he organizado startups y no sé de alguien que lo haya hecho, aunque estoy seguro de que hay ejemplos.
Tras participar en muchos hackatones, ¿qué consejos te darías a ti mismo si pudieras regresar al pasado?
- La táctica es más importante que las maniobras. Presenta cada decisión como un producto terminado. La idea, el cuaderno Jupyter, el algoritmo no valen nada si no está claro quién pagará por ello.
- Antes de diseñar cualquier cosa, pregúntate no “qué?”, sino “¿por qué?” y “¿cómo?”. Por ejemplo: al diseñar una solución de ML, primero piensa en el algoritmo ideal: ¿qué recibe como entrada y cómo se utilizan sus predicciones después?
- Únete al equipo.
¿Qué suelen servir en los hackatones?
Normalmente, en los hackatones la comida es mala: pizzas, energéticos, refrescos. Casi siempre la comida se organiza en forma de buffet (o mesa de distribución) a la que se forma una larga cola. Por la noche, generalmente no sirven comida, aunque hubo un caso en una competencia en París donde dejaron snacks para la noche: papas fritas, donuts y cola. Imagino el proceso mental de los organizadores: “Bien, ¿qué comen los programadores? Ah, claro! Papas fritas, donuts — eso es todo. Les pondremos esta basura.” Al día siguiente, pregunté a los organizadores: “Chicos, ¿no se podría hacer algo diferente para la noche? Tal vez, un porridge?” Después de eso, me miraron como si fuera un idiota. La famosa hospitalidad francesa.
En buenos hackatones, la comida se pide en cajas, hay opciones de comida normal, vegetariana y kosher. Además, ponen una nevera con yogures y muesli — para aquellos que quieren un refrigerio. Té, café, agua — es estándar. Recuerdo el hackatón Hack Moscow 2 — allí nos alimentaron generosamente con borscht y croquetas con puré en la cafetería de la oficina de 1C.
La calidad de los hackatones depende, por así decirlo, del campo profesional de los organizadores (por ejemplo, ¿los mejores hackatones los organizan consultores)?
Los mejores hackatones fueron organizados por personas que previamente habían organizado hackatones o habían participado en ellos. Creo que este es el único factor que determina la calidad del evento.
¿Cómo saber que no eres un novato y es hora de ir a un hackatón?
El mejor momento para ir a un hackatón fue hace un año. El segundo mejor momento es ahora. Así que, ¡atreve! Comete errores, aprende — eso es normal. Ni siquiera una red neuronal — el mayor invento de la humanidad después de la rueda y el gradient boosting en árboles — puede diferenciar un gato de un perro en la primera época de entrenamiento.
¿Qué «banderas rojas» indican de inmediato que el evento no será muy bueno y no vale la pena perder tiempo?
- Una descripción clara de lo que se necesita hacer (relevante para los hackatones de productos). Si al registrarte se te plantea una tarea clara, es mejor quedarte en casa. En mi experiencia, no ha habido un solo hackatón bueno con un briefing. Para comparar: Bien — haznos algo relacionado con el análisis de conversaciones de audio. Mal — haznos una aplicación que sería capaz de separar la conversación en dos pistas de audio individuales para cada persona.
- Un pequeño fondo de premios. Si te piden hacer un “tinder para una tienda online con IA” y el premio por el primer lugar es de 500 euros con un tamaño mínimo de equipo de 5 personas, quizás no valga la pena perder el tiempo (sí, este es un hackatón real que se llevó a cabo en Múnich).
- Falta de datos (relevante para los hackatones de ciencia de datos). Los organizadores suelen proporcionar información básica sobre el evento y a veces una muestra del conjunto de datos. Si no lo han proporcionado, pregúntalo, no pierdes nada. Si a 2-3 días no está claro qué datos se proporcionarán y si se proporcionarán en absoluto, eso es una bandera roja.
- Nuevos organizadores. No te dé pereza y busca información sobre los organizadores del hackatón. Si están organizando un evento de este tipo por primera vez, hay una gran probabilidad de que algo salga mal. Por otro lado, si el organizador y los miembros del jurado ya han realizado hackatones o han participado activamente en el pasado, eso es una bandera verde.
En un hackatón me dijeron: «Tú tenías la mejor solución por puntaje, pero lo siento, evaluamos el trabajo en equipo, y tú trabajaste solo. Si hubieras llevado a un estudiante o a una chica en el equipo…?» ¿Has encontrado alguna vez una injusticia así? ¿Cómo lo manejaste?
Sí, me ha pasado y no una vez. Tomo todo lo que sucede con esto con estoicismo: hice todo lo que estaba en mis manos, si no funcionó, así es la vida.
¿Por qué te involucras en todo esto?
Todo esto simplemente por aburrimiento.
Fuente: habr.com
