Lo que dicen quienes completaron los programas
Opiniones sobre el trabajo, la carga horaria y lo que se produce al terminar. Sin edición de los aspectos críticos.
← Ir al inicioTestimonios de participantes
Antes de este programa pensaba que "limpiar datos" era reemplazar nulos. Al terminar la cuarta semana ya entendía por qué ciertas decisiones de limpieza destruyen la señal que querés conservar. La retroalimentación del instructor en cada entrega fue lo que más valoré: no me decía qué estaba mal, me preguntaba por qué había hecho lo que hice.
El practicum fue más exigente de lo que esperaba. No en el sentido de que los temas fueran inaccesibles, sino en que no podías avanzar sin entender lo anterior. La revisión de código semanal me obligó a ser más ordenado de lo que acostumbraba. Lo que me resultó más útil fue aprender a escribir los resultados de manera que los límites sean visibles.
Hice los tres programas seguidos. El de ingeniería fue el que más tiempo me llevó, pero también el que más me aportó. Tener que escribir el runbook me obligó a pensar si realmente entendía lo que había construido. La respuesta inicial fue que no del todo. Eso, con la ayuda de las revisiones semanales, se fue resolviendo.
Venía de haber hecho varios cursos de ML online y sentía que algo me faltaba. Acá entendí qué era: no sabía construir un baseline que sirva de referencia real, ni escribir los resultados de manera que alguien más pueda evaluar si son creíbles. Eso cambió con el practicum.
Trabajo con datos de salud y el tema de licencias y permisos era algo que manejaba informalmente. El programa me dio un marco concreto para documentar las decisiones de uso. El entregable final —el datasheet del dataset— lo usé directamente en mi trabajo actual.
22 semanas es mucho tiempo y hay que ser honesto sobre eso. Pero la carga horaria declarada fue bastante precisa: entre las sesiones y la práctica, las semanas pesadas se notaron, igual que las más livianas. Lo que más me costó fue el monitoreo en producción, que en otros contextos se deja para después. Acá era parte del entregable.
Tres recorridos con su contexto completo
Investigadora de una universidad pública con datos recolectados durante dos años de trabajo de campo. Los datos estaban en planillas con formatos inconsistentes y sin documentación sobre el proceso de recolección.
Desarrolló un esquema de limpieza que documentaba cada decisión. Identificó que el 18% de los registros tenían una fuente diferente a la declarada originalmente. Creó una hoja de datos que describía los gaps identificados.
Dataset documentado con datasheet. El trabajo fue presentado en una jornada interna del grupo de investigación y derivó en un protocolo de recolección para las campañas siguientes.
"Lo más valioso fue entender que documentar no es trabajo extra: es parte del trabajo."
Analista de datos en una empresa de logística. Había construido modelos de clasificación antes, pero nunca había documentado el proceso de validación de manera que alguien más pudiera revisarlo.
Encuadró un problema de predicción de demanda. Construyó tres baselines antes de probar modelos más complejos. Identificó que el modelo que creía mejor tenía un leak de datos en la validación. Lo corrigió y el resultado cambió significativamente.
Análisis escrito de 14 páginas defendido en sesión. El documento describía qué funcionó, qué no y por qué. Fue compartido con el equipo técnico de su empresa como referencia interna.
"Detectar el leak fue incómodo porque implicaba reconocer que lo que había publicado antes tenía ese problema. Pero aprenderlo acá fue mucho mejor que aprenderlo después."
Desarrollador backend con experiencia en APIs y contenedores pero sin experiencia en ML en producción. Sabía servir modelos, pero no sabía cómo entrenarlos ni monitorearlos.
Construyó un sistema de clasificación de texto desde datos crudos hasta un endpoint monitoreado. El costo de cómputo durante el programa fue de USD 62. El harness de evaluación fue lo que más iteraciones requirió.
Sistema con su runbook entregado. Informe de ingeniería de 20 páginas. El tablero de monitoreo detectó degradación en la semana 20, que fue corregida como parte del trabajo final.
"Las 22 semanas son reales. No es relleno. Cada semana había algo concreto que producir."
Datos de contacto
¿Tiene sentido para tu punto de partida?
Consultanos. Contamos qué se asume como conocimiento previo en cada programa y cuándo abre la próxima cohorte.
Enviar una consulta