Portfolio Projects for Machine Learning Engineer

Tienes tres certificados de machine learning y ningún entrevistador te pregunta por ellos. Es un patrón repetido: el certificado confirma que viste el curso, pero no que puedas resolver un problema con datos sucios, plazos reales y decisiones que nadie te dicta. Un portafolio bien armado sí transmite eso.

No necesitas veinte proyectos. Necesitas tres que muestren criterio técnico, capacidad de entrega y una explicación clara de por qué tomaste cada decisión.

Qué mira realmente quien revisa tu perfil#

El revisor dedica menos de un minuto a tu GitHub antes de decidir si sigue leyendo. No busca el modelo con la accuracy más alta. Busca señales concretas de que trabajas como ingeniero y no como alguien que copió un notebook.

Las señales que más pesan, en orden aproximado:

• Un README que explica el problema, los datos, las decisiones y los resultados en cinco minutos de lectura.
• Código reproducible: dependencias fijadas, instrucciones de ejecución, datos accesibles o un script para descargarlos.
• Evaluación honesta: métricas elegidas por una razón, comparación contra una baseline, y una discusión de dónde falla el modelo.
• Evidencia de criterio: por qué ese modelo y no otro, qué descartaste, qué harías con más tiempo.
• Señales de ingeniería: tests, estructura de carpetas, manejo de errores, algo de automatización.

Un proyecto sin README claro se descarta casi siempre, aunque el modelo sea bueno.

Tres proyectos que valen más que un certificado#

1. Un problema de negocio con datos desordenados

Elige un problema real y aburrido: predecir churn en una base de suscriptores, estimar demanda de un negocio local, detectar fraude en transacciones. Usa datos de Kaggle o del portal de datos abiertos de tu país, pero no te quedes con el dataset limpio.

Ensúcialo a propósito. Mezcla formatos de fecha, valores nulos, categorías con errores de tipeo, columnas redundantes. Luego construye un pipeline que lo limpie de forma reproducible. Eso demuestra que entiendes la parte que consume la mayoría del tiempo en un trabajo real.

Termina con una comparación contra una baseline simple y con un informe breve de errores: en qué segmentos falla el modelo y cuánto costaría ese fallo en dinero o en horas.

2. Un sistema de machine learning, no solo un modelo

Muchos candidatos entregan un notebook. Pocos entregan un sistema. La diferencia es enorme para un equipo que busca a alguien que pueda llevar código a producción.

Construye algo que se ejecute de punta a punta: ingesta de datos, entrenamiento, evaluación, guardado del modelo y una API que sirva predicciones. Puede ser FastAPI, puede ser un batch job con Airflow o Prefect, lo importante es que haya orquestación y no solo celdas sueltas.

Agrega monitoreo básico: un script que vigile drift en las features o una tabla que registre la precisión del modelo por semana. Con eso muestras que piensas en el modelo después del deploy, que es donde vive la mayor parte de su vida útil.

3. Un proyecto con LLM que resuelve algo concreto

Si quieres entrar en equipos que trabajan con modelos de lenguaje, evita el chatbot genérico. Construye un sistema RAG sobre un corpus específico: normativa laboral de tu país, documentación técnica de una librería que uses, o los manuales de una industria concreta.

Lo que convence es la evaluación. Define un set de preguntas con respuestas esperadas, mide cuántas veces el sistema recupera el documento correcto, y documenta los fallos. Menciona el costo aproximado de ejecutarlo por consulta, porque en producción eso se pregunta siempre.

Un proyecto así demuestra que entiendes embeddings, chunking, retrieval y límites del modelo, no solo que sabes pegar una API key.

Cómo presentarlos en el CV#

Un bullet de proyecto debe seguir la misma estructura que uno de experiencia: acción, contexto técnico, resultado medible. La fórmula es verbo de acción, problema, tecnología, métrica.

Ejemplo de un bullet débil: "Hice un proyecto de predicción de churn con Python".

Ejemplo reescrito: "Predije churn de 70 mil suscriptores con XGBoost y un pipeline de Scikit-learn, logrando un recall de 0.81 frente a 0.54 de la baseline, con inferencia batch semanal".

La diferencia no es solo longitud. El segundo dice qué hiciste, con qué, contra qué comparaste y cuánto mejoró. Eso es lo que un reclutador técnico puede citar en una reunión.

Si quieres verificar cómo se lee tu CV frente a una oferta concreta, usa el verificador de compatibilidad con ATS gratuito para detectar palabras clave que falten.

Cómo ordenar el repositorio de GitHub#

El orden de tus repositorios importa. Fija los tres proyectos principales arriba y deja los ejercicios de curso abajo o archívalos.

Cada repositorio debería tener:

• Un README con el problema, la fuente de datos, el enfoque, los resultados y cómo ejecutarlo.
• Un archivo de dependencias fijado: requirements.txt con versiones o un pyproject.toml.
• Un script de reproducción: make train o python run.py que entrene y evalue sin pasos manuales.
• Una carpeta de notebooks separada del código de producción, marcada como exploración.
• Tests mínimos para las funciones de preprocesado y para la carga del modelo.

Los badges de CI ayudan poco si el código no corre. Prioriza que alguien pueda clonar el repo y obtener el mismo resultado en diez minutos.

Errores que convierten tu proyecto en un tutorial#

El error más común es entregar el notebook del curso con otro nombre. Si el dataset es Iris, Titanic o MNIST sin ninguna variación, el revisor asume que seguiste instrucciones.

Otros errores que restan puntos:

• Reportar solo accuracy en un dataset desbalanceado, donde una baseline tonta ya acierta el 95 por ciento.
• No mencionar limitaciones ni casos de fallo, lo que sugiere que no evaluaste de verdad.
• Subir los datos pesados al repo en lugar de un script de descarga.
• Dejar celdas sin ejecutar, prints de depuración o rutas absolutas de tu máquina local.
• Prometer "99 por ciento de precisión" sin contexto, lo que delata que no entiendes la métrica.

La honestidad técnica pesa más que la cifra más alta. Un proyecto que reconoce sus límites parece escrito por alguien que ya trabajó con datos reales.

Cómo hablar de los proyectos en la entrevista#

Prepara una narrativa corta para cada proyecto: el problema, una decisión difícil, el resultado y lo que harías distinto. Practícala hasta que dure dos minutos.

Ejemplo de respuesta: "El dataset tenía un 12 por ciento de nulos en la variable más predictiva. Probé imputación por mediana y un modelo que maneja nativos los nulos, y el segundo ganó tres puntos de recall. Lo que mejoraría es añadir validación temporal, porque ahora mismo la validación es aleatoria y puede estar inflando el resultado".

Esa respuesta muestra criterio, humildad técnica y conocimiento de tus propios sesgos. Es exactamente lo que busca un entrevistador senior.

Si la entrevista es técnica, espera preguntas sobre por qué elegiste esa métrica, cómo manejarías datos en producción o qué harías si la distribución cambiara. Ten una respuesta preparada para cada una, con un ejemplo concreto de tu proyecto.

Dónde encontrar ideas y ofertas#

Si te quedas sin ideas, busca ofertas abiertas en el buscador de empleos de jobrise y lee qué problemas mencionan las empresas. Ahí aparecen temas como detección de anomalías, forecasting de demanda o sistemas de recomendación, que son buenos disparadores para proyectos.

Para más material sobre cómo construir tu perfil técnico y preparar entrevistas, revisa el blog de jobrise, donde encontrarás guías sobre CV técnico y procesos de selección en datos.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántos proyectos necesito en el portafolio?

Tres bien terminados superan a diez incompletos. Lo ideal es que los tres muestren facetas distintas: trabajo con datos sucios, ingeniería de sistemas y algo de modelado avanzado o LLM.

¿Sirven los proyectos de cursos si los personalizo?

Sí, si cambias el problema, los datos o el enfoque y documentas tus decisiones. El problema aparece cuando entregas el notebook exacto del curso sin ninguna variación ni reflexión propia.

¿Debo publicar el código de proyectos de mi empleo actual?

No, salvo que tengas autorización explícita. En su lugar, reconstruye un problema parecido con datos sintéticos o públicos y explica la metodología sin revelar información confidencial.

¿Qué tan detallado debe ser el README?

Lo suficiente para que alguien entienda el proyecto en cinco minutos y pueda ejecutarlo en diez. Incluye problema, datos, enfoque, resultados, limitaciones y pasos de reproducción, sin convertirlo en un ensayo.

¿Cómo muestro proyectos si estoy empezando desde cero?

Empieza por el proyecto de datos desordenados con un dataset público, porque no requiere infraestructura. Luego ve subiendo la complejidad hacia un sistema completo y, si te interesa, hacia un proyecto con LLM.