El problema del CV de ingeniero ML es concreto y muy reconocible: demasiadas herramientas, pocos resultados, ninguna prueba de que algo de lo que entrenaste haya llegado a producción. Los responsables de selección pasan de largo las listas de librerías para encontrar las dos o tres líneas que demuestran que sabes desplegar.

Este artículo va sobre escribir esas líneas — y sobre las tres decisiones de estructura que hacen que un CV de ML aterrice en vez de archivarse como «otro perfil de Kaggle más».

Para qué lee de verdad un responsable de selección de ML

En 90 segundos con tu CV, un ingeniero ML sénior o un hiring manager revisa tres cosas, en este orden:

1. ¿Has llevado un modelo a producción? No un notebook. No un hackathon. Un modelo que sirvió predicciones reales a usuarios reales y del que asumiste el mantenimiento.
2. ¿Entiendes la evaluación? En concreto — más allá de la accuracy. ¿Elegiste la métrica correcta para el problema? ¿Mediste en offline y en online? ¿Detectaste tú la degradación del modelo?
3. ¿Cuál era tu alcance? ¿Tenías el problema de punta a punta (datos, entrenamiento, despliegue, monitorización) o te entregaron un dataset etiquetado para maximizar una métrica?

Si las tres están claras en los primeros 90 segundos, avanzas. Si falta una, compites en listas de herramientas, una pelea que no te conviene ganar.

La frase de presentación — la primera línea que lo decide casi todo

La mayoría de los CV de ML abren con algo del estilo «Ingeniero de machine learning con X años de experiencia en deep learning y computer vision». Eso no dice nada que el lector no pueda deducir del título de la sección.

Una apertura mejor nombra un dominio, una escala y un resultado:

Ingeniero ML, 4 años construyendo sistemas de recomendación en producción. Lo más reciente: despliegue de un modelo de retrieval profundo que sirve a 12M de usuarios/día, +8 % de engagement vs. la baseline previa de factorización matricial.

Tres elementos: dominio (recomendación), escala (12M/día), resultado (+8 % de engagement, baseline nombrada). Una frase que ya respondió a las tres preguntas.

Si todavía no tienes un proyecto en producción al que apuntar, la apertura debería al menos nombrar un problema concreto en el que has trabajado en profundidad: «Ingeniero ML enfocado en detección de fraude sobre datos tabulares con bajo volumen (<100K ejemplos etiquetados), comparado contra baselines de XGBoost y CatBoost.» Concreto gana a grandilocuente.

La sección experiencia — la plantilla de línea que despliega un modelo

La plantilla que funciona para puestos ML:

[Verbo] [tipo de modelo] para [problema de negocio], entrenado sobre [escala + fuente de datos], evaluado en [métrica + baseline], desplegado en [stack de serving], entregó [resultado de negocio].

Rellena:

Construcción de un ranker secuencial para el feed principal, entrenado sobre 90 días de logs de interacción (1 200 M de eventos), evaluado en NDCG@10 offline (+12 % vs. la baseline LambdaMART) y en A/B online (+4,1 % de tiempo de sesión, p<0,01), desplegado vía TensorFlow Serving sobre GKE detrás de un SLO p95 de 30 ms.

Cada parte hace un trabajo real:

• Verbo + tipo de modelo: indica la superficie técnica (ranker secuencial, clasificador de fraude, segmentador de imagen).
• Escala + fuente: permite calibrar la dificultad de ingeniería.
• Métrica + baseline: muestra que sabes qué significa «mejor» en tu contexto y que te comparaste contra algo serio.
• Stack de serving: señala que tú llevaste el despliegue, no solo el notebook.
• Resultado de negocio: cierra el bucle. El trabajo técnico le importó a la empresa.

Tres o cuatro líneas así por puesto ganan a quince que listan librerías.

La sección de herramientas — corta, jerarquizada, actual

El instinto es listar todo. Resístelo. Una lista larga señala falta de foco y se descarta en segundos.

La estructura que funciona:

• Núcleo (uso diario): Python, PyTorch, scikit-learn, SQL, Docker, GCP.
• Buen manejo: TensorFlow, Spark, Airflow, FastAPI, Terraform.
• Conocidos: Ray, Triton, ONNX.

Tres niveles, entre seis y ocho ítems en el primero, no más. Quita lo que no hayas tocado en dos años — listar TensorFlow 1.x en 2026 es una señal.

No metas versiones de framework, no listes «IA» o «Machine Learning» como herramienta (es el campo, no la herramienta), no pongas un proveedor cloud como una sola línea sin decir qué has usado en él. «AWS» no significa nada; «AWS (SageMaker, S3, Lambda, IAM)» sí.

La sección de proyectos — solo si de verdad has desplegado u open-sourceado algo

Una sección de proyectos ayuda cuando:

• Estás empezando y tu experiencia es escasa.
• Has lanzado algo en paralelo que impresiona más que tu trabajo principal.
• Contribuyes a un proyecto open source de ML conocido.

Perjudica cuando:

• Los proyectos son competiciones de Kaggle sin ángulo de producción.
• Los proyectos son reproducciones de tutoriales («entrené una GAN en MNIST»).
• Los proyectos no tienen enlace público ni evidencia de uso.

Una línea de proyecto que funciona:

Contribuidor open source en [proyecto] (8 200 estrellas en GitHub) — implementación de [feature], integrada en v2.3, reducción de la latencia p95 de [operación] en un 34 % (benchmark en el README).

Una línea de proyecto que no:

Construcción de un chatbot con LangChain y la API de OpenAI.

Para la mayoría de puestos mid o sénior, quita la sección de proyectos si va a rellenarse con trabajo a nivel de tutorial. Es tu sección de experiencia la que debe hacer el trabajo pesado.

Rigor de evaluación — la señal que separa un júnior de un sénior

La forma más rápida de parecer sénior sobre el papel es hablar de evaluación como habla un sénior. Tres pequeños movimientos de escritura:

1. Nombra la métrica correcta para el problema. Un clasificador de fraude con 99 % de accuracy es un mal clasificador de fraude. Usa precision-recall, PR-AUC o métricas sensibles al coste según el problema. Mostrar que elegiste la métrica a propósito, no por defecto, es una señal sénior.
2. Compárate contra una baseline real. «Conseguí 0,91 de AUC» por sí solo no dice nada. «Conseguí 0,91 de AUC frente a 0,84 de la regresión logística ya en producción» lo dice todo.
3. Menciona la evaluación online cuando la tienes. Las mejoras offline que no se traducen online son la vergüenza más común en ML aplicado. Si hiciste A/B, nombra el resultado y la significación.

Tres pequeños movimientos. El CV se lee completamente distinto.

Qué quitar o restar protagonismo

• Listas de cursos online. Coursera, Udacity, fast.ai son buenas señales al principio; pasados los primeros años perjudican porque hacen pensar por qué sigues listando clases.
• Premios de hackathon de hace más de tres años. Un hackathon señala energía reciente, no logro antiguo.
• «Publiqué un artículo en Medium sobre X». Salvo que el artículo haya tirado de verdad (10K+ lecturas o citado por alguien notable), es relleno.
• Listas de papers leídos. Leer papers es el trabajo; listarlos no es el logro.

Es la misma trampa que ya cubrimos para puestos vecinos en CV de científico de datos: mostrar impacto, no solo una lista de herramientas y CV de analista de datos — el modo de fallo es el mismo en todos los perfiles data/ML, y la corrección también.

Extensión y estructura

• Una página si tienes menos de cinco años de experiencia, dos páginas como máximo por encima. Los ingenieros ML no ganan puntos por longitud.
• Experiencia en orden cronológico inverso. Los CV funcionales se leen como si estuvieras escondiendo algo.
• Sección de formación breve — titulación, escuela, año. Sin GPA pasada la primera mitad de la carrera. Si tienes doctorado con un buen historial de publicaciones, las publicaciones van en una sección aparte, no en formación.
• Sin foto. Incluso en mercados donde el CV tradicionalmente lleva foto, la selección tech/ML se ha globalizado y la versión sin foto viaja mejor.

Cómo encaja este CV con el perfil de LinkedIn

La mayoría de responsables de selección de ML va a abrir tu LinkedIn en el primer minuto desde que vea tu CV. Los dos tienen que contar la misma historia — mismos puestos, mismo alcance, mismo encuadre del titular. Un CV que dice «lideré el despliegue del retrieval profundo» y un LinkedIn que dice «Machine Learning Engineer, apasionado por la IA» señala una de dos cosas: o el CV exagera o el LinkedIn está abandonado. En ambos casos, pierdes terreno en los siguientes 30 segundos.

Postulit lleva datos estructurados de tu LinkedIn a un CV que cuadra con ellos, lo que resuelve el desajuste más común en selección de ML — la historia es coherente en las dos superficies, y el reclutador nunca tiene que decidir cuál creer.

Una autoevaluación de 60 segundos antes de enviar

• ¿Puede un ingeniero ML sénior responder a las tres preguntas (¿desplegaste? ¿evaluaste con rigor? ¿punta a punta?) leyendo solo la mitad superior de la primera página?
• ¿Hay al menos una línea de tu último puesto que nombre un stack de serving en producción?
• ¿Hay al menos una línea que nombre una baseline que batiste, en cuánto y con qué métrica?
• ¿Has reducido la lista de herramientas a tres niveles con como mucho ocho ítems en el superior?
• ¿Has quitado lo de hace más de tres años que ya no representa quién eres ahora?

Cinco síes y tienes un CV de ingeniero ML que no se archiva como genérico. Cuatro de cinco y sigues en la conversación. Tres o menos y la reescritura es más rápida de lo que crees — empieza por la plantilla de línea sobre un solo puesto, y el resto sale solo.