Currículum de ingeniero/a de machine learning: ejemplos y guía para redactarlo

Un currículum con material para dos páginas, recortado a lo esencial, de un ingeniero de machine learning con seis años de experiencia, la mitad de ellos desplegando modelos que atienden tráfico real. Los nombres son ficticios. Fíjate en que cada logro nombra el modelo, el volumen de datos, la restricción de servicio y el resultado de negocio, y en que el trabajo de infraestructura se trata como trabajo de verdad.

El equipo te contrata porque los modelos se siguen rompiendo después de desplegarse. Eso determina lo que busca.

• ¿Algo de lo que construiste atendió tráfico real? Las métricas offline sobre un dataset estático son baratas. Lo que cuenta son las peticiones por segundo, la latencia, los usuarios afectados y cuánto tiempo lleva el modelo en producción.
• ¿Eres responsable del camino de los datos? La mayoría de los fallos de ML vienen de los pipelines y del desajuste de features, no del modelo. La ingeniería de features, la orquestación y un feature store son señales potentes.
• ¿Sabes hacer ingeniería, no solo modelar? Tu estilo de código, tus hábitos de testing, los contenedores y la CI le dicen al responsable si vas a necesitar un ingeniero de software detrás de ti.
• ¿Mides lo correcto? Nombrar por separado la métrica offline y la online (F1 y conversión, AUC e ingresos por sesión) demuestra que has puesto algo en producción.
• Ámbito y actualidad. El trabajo con LLM y recuperación, el ranking clásico, la visión artificial y la previsión son trabajos bastante distintos. Ajusta el currículum al problema de la oferta.

“Enséñame un modelo que llevaste de un notebook a producción y mantuviste vivo un año. Qué se rompió, qué monitorizaste, qué tuviste que revertir. Esa historia me dice más que cinco medallas de Kaggle y una lista de todos los frameworks que has tocado.”

Tres o cuatro líneas: años, área de problemas, la cifra de producción más importante y el alcance del stack del que te encargas. Evita el formato de objetivo profesional salvo que acabes de terminar los estudios.

El problema habitual es un currículum lleno de frameworks y sin resultados. Asocia una cifra y una restricción a cada modelo.

Es uno de los pocos campos en los que los responsables de contratación abren tus enlaces. Una sección de proyectos ayuda al principio de tu carrera y puede seguir ayudando después si el proyecto demuestra algo que tus empleos no. Perjudica cuando es una carpeta de notebooks de tutoriales.

• Dos o tres proyectos como máximo. Cada uno con un título, una línea sobre el problema, otra sobre el enfoque y otra sobre el resultado, más un enlace.
• Incluye las partes aburridas: cómo recogiste los datos, cómo lo evaluaste, cómo se despliega o se reproduce. Un proyecto con Dockerfile, tests y README vale más que uno con un modelo más grande.
• Da una métrica real y una referencia. «F1 de 0,87 frente a 0,72 de una referencia por palabras clave sobre 30.000 reseñas etiquetadas» merece la pena leerse; «construí un modelo de análisis de sentimiento», no.
• Quita todo lo que use un dataset de tutorial famoso, salvo que hicieras algo poco habitual con él. Los responsables han visto el mismo proyecto de Titanic o MNIST cientos de veces.
• Enlaza solo un perfil de GitHub que quieras que abran. Si tus repositorios fijados están vacíos o a medias, arréglalos antes de enviar el currículum.
• Publicaciones, un buen puesto en el ranking de Kaggle o una contribución aceptada en una librería open source real merecen una línea cada una. Una buena clasificación en una competición no sustituye a una historia de producción.
• Si tu trabajo está bajo un acuerdo de confidencialidad, describe la forma sin los detalles: «modelo interno de fraude sobre unos 30 millones de transacciones al mes» es suficiente.

Agrupa la lista por capas para que el responsable vea hasta dónde llega tu responsabilidad. No la infles con todo lo que tocaste una vez, porque en las entrevistas preguntan por el tercer elemento de la lista.

• Lenguajes: Python primero, SQL siempre, y el lenguaje en el que escribas el código de servicio (Go, Java, C++ para trabajo en edge y visión).
• Modelado: PyTorch, scikit-learn, XGBoost o LightGBM, Hugging Face Transformers, TensorFlow si aún lo usas. Nombra también los tipos de problema: ranking, recuperación, clasificación, previsión, detección.
• Datos: Spark, pandas o Polars, Kafka, dbt, Airflow o Dagster, un feature store como Feast y el data warehouse que consultas (Snowflake, BigQuery, Redshift).
• Servicio e inferencia: FastAPI, Triton, ONNX, TensorRT, vLLM para modelos de lenguaje, batching y cuantización, decisiones de coste entre GPU y CPU.
• Plataforma: Docker, Kubernetes, Terraform, GitHub Actions y una nube a fondo (SageMaker en AWS, Vertex AI en GCP, Azure ML).
• Seguimiento y evaluación: MLflow o Weights & Biases, diseño de experimentos, tests A/B, pares de métricas offline y online, análisis por segmentos, despliegues en sombra.
• Recuperación y vectores, si aplica: embeddings, FAISS, pgvector o una base de datos vectorial gestionada, chunking y reranking para generación aumentada por recuperación.
• El criterio por el que preguntan en las entrevistas: saber cuándo un modelo más sencillo es la respuesta correcta, cuándo comprar en lugar de construir y cómo decir que no a un problema que no necesita machine learning.

La mayoría de las ofertas de ingeniería de ML piden una experiencia que nadie tiene al empezar. Se entra normalmente por un puesto cercano (científico/a de datos, ingeniero/a de datos, ingeniero/a back-end, becario/a de ML) o con proyectos que parecen trabajo de producción.

1. 1Empieza con un proyecto sustancial, no con cinco pequeños. Elige el que incluya recogida de datos, evaluación y despliegue.
2. 2Demuestra ingeniería, no solo modelado. Un endpoint desplegado, tests, un contenedor y un README te separan de la mayoría de candidatos de este nivel.
3. 3Pon asignaturas solo si son concretas y recientes: sistemas distribuidos, optimización, deep learning, estadística. No enumeres diez asignaturas.
4. 4Aprovecha bien las prácticas y las colaboraciones de investigación: tamaño del dataset, qué mediste y si alguien usó el resultado.
5. 5Preséntate también a los puestos cercanos. Los puestos de ingeniería de datos y back-end en empresas con equipos de ML son una vía más rápida hacia la ingeniería de ML que esperar una oferta junior de ML.
6. 6Las certificaciones de nube ayudan un poco a este nivel, sobre todo como prueba de que conoces la plataforma. No sustituyen a un proyecto que alguien pueda ejecutar.

• Una página al principio y dos cuando tengas tres o más años y trabajo real en producción. En este campo, quien selecciona sí lee la segunda página.
• Pon los enlaces (GitHub, web personal, publicaciones) en la cabecera, donde se hace clic, y comprueba que funcionan en el PDF.
• Nada de barras de nivel en las competencias. Nadie se cree un cuatro de cinco en PyTorch, y el ATS no las lee.
• La foto es opcional en España y la fecha de nacimiento no hace falta. Usa una sola columna para que el ATS lo lea en orden.
• Copia la oferta: si dice «MLOps», «LLM», «sistemas de recomendación» o «visión artificial», usa esas mismas palabras cuando sean ciertas. Los filtros buscan los nombres de los frameworks de forma literal, así que escribe «PyTorch» y también la librería concreta cuando importe.
• Merece la pena incluir, si es cierto: producción, despliegue, inferencia, latencia, throughput, feature store, drift, test A/B, fine-tuning, embeddings, Kubernetes, Spark, Airflow, MLflow, SageMaker o Vertex AI.

Una última comprobación antes de enviarlo: en cada logro, pregúntate si un científico de datos, un ingeniero back-end y un ingeniero de ML habrían escrito la misma línea. Si es así, no está trabajando para ti. Reescríbela con la restricción que tuviste que cumplir.