¿Por qué el reto es la parte que más se descuida?
En la mayoría de los eventos que revisamos, el reto se escribe la última semana, deprisa, y suele ser una versión edulcorada de un problema interno. El resultado es predecible: enunciados enormes, sin criterio de éxito y sin datos, que cada equipo interpreta de una manera distinta. Cuando llega la evaluación, el jurado compara peras con tractores.
El reto no es el envoltorio del evento: es el instrumento con el que se mide a las personas. Un termómetro mal calibrado no se arregla con una sala más bonita. Por eso, en el reparto de esfuerzo de la preparación, el diseño del reto debería ocupar el primer lugar y empezar seis semanas antes, en paralelo con la captación.
Hay una prueba rápida para saber si un reto está listo: dáselo a leer a dos personas del equipo por separado y pídeles que escriban en una línea qué hay que entregar. Si escriben cosas distintas, el enunciado no está terminado.
¿Qué condiciones cumple un reto bien diseñado?
Un reto útil para selección cumple cinco condiciones simultáneas. Fallar en una sola basta para arruinar la comparabilidad de las entregas:
- Resoluble: un equipo competente llega a algo defendible en el tiempo dado, con margen para pulir.
- Sobredimensionado a propósito: hay más trabajo posible que horas disponibles, para que haya que priorizar y renunciar.
- Con criterio de éxito explícito: qué se considera «bien» está escrito en el enunciado, no en la cabeza del jurado.
- Con materiales de partida: datos, API de prueba, guion de usuario o descripción del proceso. Sin materiales, la primera mitad del evento se va en inventar contexto.
- Auténtico: procede de un problema que la empresa tiene de verdad, aunque esté simplificado. Los participantes lo detectan en cinco minutos y su implicación cambia.
¿Cómo se traduce una vacante en un reto?
El camino correcto va de la conducta al reto, no del problema al reto. Primero se listan las cinco o seis conductas que predicen el éxito en el puesto: por ejemplo, «traduce un requisito de negocio ambiguo en una especificación técnica» o «detecta datos sucios antes de construir sobre ellos». Después se diseña un ejercicio que obligue a exhibirlas.
Un ejemplo concreto de un proceso de perfiles de datos: la conducta clave era detectar problemas de calidad del dato antes de modelar. El reto entregaba un conjunto de datos con duplicados sutiles y fechas incoherentes, y el criterio de éxito premiaba explícitamente documentar las anomalías encontradas. Los equipos que se lanzaron a entrenar modelos sin mirar los datos quedaron retratados sin necesidad de preguntarles nada.
Ese es el mecanismo: el reto contiene trampas honestas —problemas reales que quien sabe detecta y quien no, no— y el criterio de éxito recompensa detectarlas. No se trata de engañar al participante, sino de que el trabajo bien hecho se distinga solo, sin que dependa del brillo de la presentación final.
Cuando el puesto es no técnico, el mismo mecanismo funciona con otros materiales: un brief de cliente con un objetivo imposible y un presupuesto insuficiente mide, en un reto de marketing, exactamente la conducta de negociar el alcance.
¿Cuántos retos y con qué nivel de dificultad?
Un reto único con varios niveles de entrega funciona mejor que varios retos a elegir. Con retos distintos, la comparación entre equipos exige normalizar resultados y el jurado acaba discutiendo sobre la dificultad relativa de cada uno en lugar de sobre las personas.
La estructura que mejor nos ha funcionado es de tres capas: un mínimo obligatorio que todos deben alcanzar, un desarrollo esperado que separa al grueso del grupo y una capa opcional que solo tocan dos o tres equipos. Esa tercera capa no sirve para ganar el hackathon, sino para identificar techo técnico.
Sobre la dificultad: calíbrala con una prueba en seco. Alguien de tu equipo debe resolver el mínimo obligatorio en un tercio del tiempo asignado. Si tarda la mitad, el reto es demasiado grande para el formato y la mayoría de los equipos entregará algo incompleto e incomparable.
Hay una tentación recurrente que conviene resistir: subir la dificultad para «ver de qué son capaces los mejores». Un reto durísimo aplana la distribución por abajo —casi todos entregan poco— y destruye la información sobre el 80 % del grupo, que es donde suelen estar las contrataciones reales. Para medir techo basta la capa opcional.
¿Qué errores aparecen una y otra vez?
El enunciado infinito. Cuatro páginas de contexto corporativo que nadie lee entero y que hacen que los equipos empiecen con veinte minutos de retraso. Un reto cabe en una página, más anexos opcionales.
El reto que en realidad es trabajo gratis. Si el entregable es un módulo que la empresa va a poner en producción, el evento tiene un problema ético y de reputación, y la comunidad profesional lo comenta. Los retos deben ser representativos del trabajo real, no una externalización encubierta.
El criterio de éxito secreto. Cuando el jurado tiene en la cabeza una solución concreta y puntúa la cercanía a ella, se está evaluando adivinación. Si esa solución importa, escríbela como restricción del enunciado.
Y la dependencia de una tecnología concreta sin avisar. Si el reto exige una herramienta específica, tiene que constar en la convocatoria y en las bases: de lo contrario se está midiendo quién la usó en su último trabajo, no quién resuelve el problema.
Un quinto error, más sutil, es el reto que premia la velocidad por encima de todo. Los eventos de 48 horas ya presionan lo suficiente; si además el criterio de éxito solo mira cuánto se ha completado, el evento selecciona a quien acepta trabajar mal y rápido. En una contratación real eso se paga a los tres meses, cuando alguien tiene que mantener lo que esa persona escribió.
¿Cómo se valida el reto antes del evento?
Con un ensayo. Dos personas ajenas al diseño intentan resolverlo en condiciones parecidas y cronometran. Ese ensayo detecta ambigüedades, datos que faltan y estimaciones optimistas, y suele obligar a recortar entre un 20 % y un 30 % del alcance previsto.
Con una revisión de la rúbrica en paralelo. Cada criterio de evaluación debe poder puntuarse mirando la entrega y las notas de los mentores. Si un criterio solo se puede juzgar «por impresión general», sobra o hay que reescribirlo hasta que sea observable.
Y con una lectura legal de las bases: propiedad de lo entregado, tratamiento de datos personales, uso de imagen y condiciones del premio. Es media hora de trabajo que evita el único tipo de problema que puede estropear un evento entero.
Qué hacer esta semana
Coge la vacante que más te preocupa cubrir y escribe las cinco conductas que distinguirían a quien la va a hacer bien. Ese folio es el punto de partida de cualquier reto que funcione, y sirve igual si al final decides no hacer evento.
Después busca en tu operación un problema real que exija esas conductas y que puedas simplificar sin falsearlo. Si no lo encuentras, es señal de que la vacante está mal definida, y eso es un hallazgo valioso antes de gastar un euro.
Si quieres, mándanos ese folio. Lo revisamos y te decimos si el reto se sostiene, qué falta y cómo quedaría la rúbrica. Hemos diseñado retos para más de 50 hackathons y la mayoría de los problemas se ven en la primera lectura.
De dónde salen los datos de ONKLUB
Las cifras de operativa que aparecen en este artículo salen de los registros propios de ONKLUB, no de estimaciones de mercado. El proceso de referencia va de 248 perfiles evaluados a 3 decisiones entregadas, pasando por 80 señales válidas, 25 entrevistas en profundidad y 9 finalistas con valoración escrita, en un ciclo de 20 días naturales. Las cifras acumuladas de la agencia cubren de 2022 a 2026.
Qué NO demuestran estos datos: son la operativa de una agencia sobre sí misma, no una muestra representativa del mercado laboral español, y el embudo corresponde a un proceso de dificultad alta, no a la media de todos. No están auditados por un tercero independiente.
Metodología completa, desglose por fases y limitaciones en el Informe ONKLUB de talento joven, publicado bajo licencia CC BY 4.0: se puede citar y reproducir citando la fuente.