Ingeniería
Del Código al Podio: cómo los hackathons aceleran tu carrera en Ingeniería
Qué decisiones mueven de verdad la aguja en una competencia de innovación, y qué haces con el resultado cuando se apagan las luces. El contenido de la charla, en texto.
Jesús Barros · · 6 min de lectura
Esto es el contenido de la charla que doy en la Universidad Autónoma del Caribe. Lo dejo aquí en texto porque una charla dura una hora y se olvida, y esto se puede releer antes de tu próximo hackathon.
He estado en los tres lados de la mesa: compitiendo, mentoreando y juzgando. Desde el lado del jurado se ven cosas que desde el equipo no — por qué un proyecto brillante pierde contra uno correcto, o por qué una demo impecable se cae en el minuto dos.
Una advertencia: esto no es «cómo ganar un hackathon». Ganar depende de demasiadas cosas que no controlas. Es qué decisiones sí mueven la aguja.
1. Por qué entrar
Empiezo por lo que deja fuera a más gente, y no tiene nada que ver con la técnica: «yo no estoy listo». «Ahí van los que saben de verdad». «El año que viene, cuando controle más».
Casi siempre es falso. Nadie entra sabiéndolo todo, y los equipos que ganan también buscan en internet a mitad del reto. No se compite con lo que sabes: se compite con lo que resuelves.
Antes de hablar de táctica hay algo más grande de por medio: el ecosistema. Es la forma de aportar nuestro granito de arena al crecimiento empresarial, económico, emprendedor y tecnológico de la sociedad, y en Barranquilla se ve especialmente bien. Unos años atrás nadie habría dicho que la ciudad tendría comunidades de datos e inteligencia artificial, ni la cercanía que hoy tiene con empresas globales. Eso no aparece solo: lo sostienen las personas, las empresas y las comunidades que siguen apareciendo. Llenar una sala como esa charla ya es participar.
Lo que cambia en una hoja de vida
Imagina dos encima de la mesa. La primera tiene un título y una experiencia laboral. La segunda tiene voluntariado en comunidades, competencias —sin haber quedado primera— y proyectos propios, aunque no llegaran al mercado. Las dos personas saben programar parecido.
¿Cuál se lee mejor desde el otro lado de la mesa? Por eso la pregunta no es si estás listo: es qué vas a tener que contar dentro de un año.
Hasta dónde puede llegar esto
En Barranquilla hay un referente que lo resume bien: Jonathan Tarud, fundador de Koombea. Ingeniero aeroespacial formado en Estados Unidos, trabajó en el programa del Boeing 787 en Seattle, volvió a su ciudad y en 2007 abrió Koombea con sus ahorros.
Lo que consolidó la empresa fue una competencia: en 2009 ganaron Rails Rumble, un certamen global de desarrollo web. Y el premio no fue dinero ni una ronda de inversión —Koombea nunca levantó capital externo—, sino visibilidad en Silicon Valley. De ahí salieron sus primeros grandes clientes corporativos, y de ahí en adelante creció con su propio capital.
Hoy construyen producto para empresas del Fortune 2000. Todo eso empezó por presentarse a una competencia.
Y sin irnos tan lejos
Con FOMO entramos al Programa de Incubación de Five One Labs, que opera en Barranquilla: se trata de lanzar el prototipo para validar la idea de negocio con herramientas prácticas, y los emprendimientos elegibles compiten por 5.000, 10.000 o hasta 15.000 USD en capital. Fuimos uno de los ganadores, y ese capital volvió entero al producto.
Después vino Eureka 2.0, de Nuestra Barranquilla, que pedía aportar herramientas tecnológicas al crecimiento cultural de los grupos juveniles de la ciudad. Ganamos 36 millones de pesos.
Dos convocatorias, dos productos financiados. Ninguna de las dos empezó por un título.
2. Antes de inscribirte
Lo que de verdad se premia es entender el problema antes de programarlo, terminar algo aunque sea pequeño, y explicarlo de forma que se entienda. Nada de eso exige ser un superdotado. Exige cabeza.
La calma es una habilidad técnica. Todo el mundo se bloquea, todo el mundo rompe algo, y a todos les falla la demo alguna vez. La diferencia no está en no frustrarse: está en cuánto tardas en volver. Levantarse de la silla y respirar nunca es tiempo perdido — el equipo sereno acaba, el equipo tenso discute.
Dicho eso, hay tres cosas prácticas que conviene resolver antes.
Lee las bases como si fueran un contrato. Los criterios de evaluación te dicen literalmente qué construir, y casi nadie los lee. Un jurado técnico y uno de negocio premian cosas distintas. Y averigua qué puedes llevar hecho y qué no: enterarse tarde descalifica.
Prepara lo que no depende del reto. Repositorio, despliegue y dominio listos: eso no es innovación, es tiempo perdido cuando el reloj aprieta. Una plantilla de pitch que ya sepas usar. Y descansar — contraintuitivo, y probablemente la ventaja competitiva más barata que existe.
3. El equipo
Gana el equipo que se reparte bien, no el que más sabe.
Con quién te juntas pesa más que el currículum de cada uno. Mejor alguien con quien ya hayas trabajado. Busca quien cubra tu hueco, no quien confirme lo que ya sabes. Y tres o cuatro personas: cinco ya es una reunión.
Los acuerdos se cierran al principio, no cuando ya estáis cansados. Qué significa «terminado» para esta competencia. Quién decide cuando no hay consenso y el reloj corre. Cuándo se congela el código y empieza el ensayo.
4. Durante la competencia
Aquí el enemigo no es la dificultad: es el alcance.
Define el camino exacto que vas a enseñar y constrúyelo entero antes de tocar nada más. Lo que no aparece en la demo puede quedarse a medias — decidirlo a propósito no es hacer trampa, es priorizar. Y si algo no funciona cerca del cierre, se corta; no se arregla.
La demo se ensaya. Grábala como plan B, porque las redes del recinto se caen justo cuando te toca. Ensáyala en voz alta con cronómetro. Y decide de antemano qué haces si se rompe en directo: se nota muchísimo quién lo pensó antes.
El pitch va en este orden: problema, solución, prueba. Empieza por el problema, no por tu arquitectura. Enseña que funciona antes de explicar cómo funciona. Y responde a los criterios de evaluación con sus mismas palabras.
5. Después del podio
Red. Los jurados y mentores de hoy son quienes contratan e invierten mañana. Escribe a tres personas mientras todavía te recuerdan. Y vuelve a la siguiente: la red se construye por repetición, no por asistencia.
Tres cosas, si no te queda nada más
- Lee los criterios de evaluación antes de escribir una línea de código.
- Reparte roles, no tareas.
- La competencia termina; lo que haces después decide si sirvió.
La competencia dura poco. La red que construyes en ella te acompaña años.
Mi charla es el lunes 28 de septiembre, de 16:00 a 18:00, en el salón K510 del Edificio de Posgrados de la Universidad Autónoma del Caribe. Entrada gratuita. Si lees esto después, el enlace de arriba te sirve igual.