El despertador sonó a las 4:40 a. m. Afuera, Santo Domingo seguía a oscuras; adentro, solo el zumbido del aire y la luz azul de la laptop. Me serví un café, abrí la cola de ayuda del evento y refresqué. Tres tickets esperando. Al otro lado de la pantalla, a miles de kilómetros, había equipos que llevaban casi veinte horas sin dormir peleando con su código, y para los próximos minutos yo era su salvavidas. Así empezó mi turno en HackMIT 2024.
Quiero contar esta experiencia no para presumir un certificado, sino porque esas seis horas de madrugada, ponerme al lado de alguien atascado y ayudarlo a destrabarse, me recordaron con fuerza por qué enseño. Y porque dejaron lecciones técnicas y humanas que aplico cada semana en el aula.
A las 5 de la mañana nadie quiere teoría. Quieren entender por qué su API devuelve 401 y cómo arreglarlo antes de que se acabe el reloj.
¿Qué es HackMIT y cómo terminé mentoreando ahí?
HackMIT es uno de los hackathones universitarios más prestigiosos del mundo, organizado cada año por estudiantes del Massachusetts Institute of Technology (MIT). Reúne a cientos de "hackers" (estudiantes y desarrolladores) que durante un fin de semana forman equipos y construyen proyectos de software desde cero, normalmente alrededor de un tema o reto. La edición 2024 se celebró el 14 y 15 de septiembre, con el inicio del hacking el sábado a las 11:00 a. m.
Los mentores somos una pieza clave de esa experiencia. No estamos para construir el proyecto por los participantes, sino para desbloquearlos: una API que no autentica, un despliegue que falla, una arquitectura que no termina de cuadrar, o simplemente una idea que necesita aterrizarse. Me sumé como mentor virtual, lo que me permitió aportar desde República Dominicana a través de la plataforma de cola de ayuda del evento y del Discord oficial, donde ocurría toda la comunicación del día.
Mentoría virtual, compromiso real: ser mentor no fue solo "estar disponible". Implicó confirmar asistencia de forma vinculante, completar una orientación obligatoria previa al evento y comprometerme con turnos asignados. Los hackers cuentan contigo, y esa responsabilidad se siente.
Mis turnos: la madrugada del lado correcto
Me asignaron tres bloques consecutivos en horario del este (EDT), todos de la madrugada hacia la mañana del domingo: de 5:00 a 7:00, de 7:00 a 9:00 y de 9:00 a 11:00. Para muchos sería una franja incómoda; para mí fue perfecta. La madrugada es cuando los equipos llevan horas peleando con un bug, la energía baja y un par de ojos frescos pueden marcar la diferencia entre abandonar una función o terminarla.
El trabajo real: tres tickets de una madrugada
La mentoría en un hackathon es un ejercicio de diagnóstico rápido. Cada conversación empieza casi igual: "estamos atascados con…". A partir de ahí toca escuchar, hacer la pregunta que destraba y guiar sin quitarle nunca el teclado al equipo. Para que se entienda de qué hablo, déjame reconstruir tres de los casos típicos de esa madrugada. Son representativos de lo que se vive ticket tras ticket en un evento así.
Ticket 1: "Nuestra API nos devuelve 401 y juramos que el token está bien"
Un equipo intentaba consumir una API externa directamente desde el frontend. En la consola del navegador veían un 401 y, peor aún, un error de CORS intermitente. Estaban convencidos de que el problema era la clave.
El diagnóstico real era doble. Primero, estaban poniendo el token en el lugar equivocado (un parámetro de query en lugar del header Authorization: Bearer). Y segundo, el problema de fondo, estaban llamando una API de servidor desde el navegador, exponiendo su clave secreta a cualquiera que abriera el DevTools y chocando con CORS. La pregunta que lo destrabó no fue "¿qué dice la doc?", sino "¿por qué el navegador necesita ver esa clave?".
Diez minutos. La clave dejó de viajar al cliente, CORS desapareció (ahora el frontend hablaba con su propio backend) y el 401 se resolvió solo. Pero lo importante no fue el parche: fue que entendieran por qué un secreto no se pone en el frontend. Esa lección les va a servir mucho después del hackathon.
Ticket 2: "Funciona en mi máquina pero la demo desplegada está en blanco"
Otro equipo tenía todo corriendo en localhost, pero al desplegar para tener la URL pública (ese paso que muchos dejan para el final y casi siempre muerde) la página cargaba en blanco. La consola contaba la historia:
Dos cosas a la vez, las dos clásicas de despliegue. El frontend tenía la URL del backend escrita a mano como http://localhost:3000, así que la demo pública seguía buscando el servidor en la máquina del estudiante. Y como la página estaba en HTTPS llamando a un recurso HTTP, el navegador bloqueaba la petición por mixed content. Encima, la clave de la API que en local vivía en su .env nunca se configuró en el panel del proveedor, así que ni existía en producción.
El acompañamiento aquí fue de método, no de código: mover toda URL y secreto a variables de entorno, configurarlas en el panel de despliegue y entender que "en mi máquina" y "en producción" son dos mundos distintos que hay que mantener en paridad. A las 6 de la mañana, ver su demo cargar en una URL pública les devolvió el alma al cuerpo.
Ticket 3: "Queremos entrenar nuestro propio modelo… faltan 5 horas"
El tercero no era un bug, era ambición. Un equipo con muchísima energía quería, en lo que quedaba del evento, recolectar un dataset, entrenar un modelo de clasificación desde cero, montar autenticación de usuarios y un dashboard. Cualquiera de esas cuatro cosas, sola, se come las cinco horas restantes.
Aquí la mentoría es casi de producto: ayudarlos a separar lo que impresiona en la demo de lo que se ve bonito en el papel. Les hice una sola pregunta: "de aquí a la presentación, ¿qué tiene que funcionar en pantalla para que el jurado entienda la idea?". La respuesta no incluía entrenar nada.
- Recortamos el alcance: en vez de entrenar un modelo, usar una API de IA ya existente para la parte inteligente. El "qué" de su idea seguía intacto.
- Mockearon lo pesado: el dataset gigante se volvió un JSON de ejemplos curados, suficiente para una demo convincente.
- Definieron el "happy path": un solo flujo, de principio a fin, que funcionara sin fallos en vivo. Nada de casos borde a las 5 a. m.
Pasaron de un plan imposible a un demo presentable. No construyeron todo lo que soñaron, pero construyeron algo que se podía enseñar, y eso en un hackathon lo es todo.
Tres tickets, tres mundos: seguridad de credenciales, paridad entre entornos y disciplina de alcance. Ninguno se resolvía escribiendo código por ellos; todos se resolvían con la pregunta correcta en el momento correcto.
Tres lecciones que me llevé
Pasé seis horas ayudando, pero salí del evento sintiendo que el que más aprendió fui yo. Estas son las tres ideas que me quedaron y que llevo a mi salón de clases en la UNAD.
El mejor mentor no es el que tiene todas las respuestas, sino el que hace la pregunta que destraba. Cuando le das el pez, avanzan una vez; cuando les enseñas a leer el error, avanzan toda la vida. La meta siempre es que el equipo se quede con la capacidad, no con la solución.
Cada equipo traía un stack, un enfoque y una creatividad distinta. Ayudar a resolver sus problemas me expuso a herramientas y combinaciones que yo no usaba. La mentoría es una calle de doble vía: enseñar es la forma más rápida de seguir aprendiendo.
En entornos de ritmo rápido y alta presión, la gente toma decisiones, recorta lo superfluo y colabora como pocas veces. Ese ambiente de "construir o construir" es un laboratorio brutal de resolución de problemas. Vale la pena recrearlo, a menor escala, en cualquier aula o equipo.
Por qué esto importa, también desde República Dominicana
Participar en un evento del MIT desde Santo Domingo es un recordatorio de que el talento y la voluntad de aportar no tienen fronteras. No necesité estar en Cambridge para sumar valor; necesité presencia, conocimiento y ganas de ayudar a las 5 de la mañana. Para mis estudiantes, ese es justamente el mensaje: las puertas de las comunidades tecnológicas globales están más abiertas de lo que parece, y se entra aportando, no solo pidiendo.
La mentoría, dentro y fuera del aula, sigue siendo una de las formas más poderosas de generar impacto. Un buen empujón en el momento correcto puede cambiar el rumbo de un proyecto… y a veces, de una carrera.
Para llevar: si tienes experiencia técnica, busca un hackathon, un grupo de estudio o una comunidad donde mentorear. Darás menos de lo que recibes. Y si eres estudiante, postúlate a estos eventos: la curva de aprendizaje de un fin de semana de hackathon equivale a semanas de clase.
Agradecimientos
Gracias al equipo organizador de HackMIT 2024, en especial a Susan Hong y a todo el equipo de voluntariado, por la impecable logística y por confiar en mentores de todas partes del mundo. Gracias también a los participantes por su creatividad y energía, y a los patrocinadores que hacen posible un evento así. Fue un honor aportar mi granito de arena. No veo la hora de ver hacia dónde llegan esos proyectos. 🚀