Portfolio Projects for Data Scientist

Tu portafolio de ciencia de datos se parece demasiado a los proyectos que salen en los cursos. Ese es el problema. Quien revisa candidaturas ve los mismos notebooks una y otra vez: el dataset de viviendas de Boston, el de Titanic, el de Iris, el de predicción de churn con un CSV limpio que ya viene listo. Ninguno de esos proyectos dice nada sobre cómo trabajas.

Los certificados tampoco ayudan mucho. Un curso terminado demuestra que pagaste y que completaste videos. No demuestra que puedas resolver un problema real, con datos sucios y requisillos vagos. Un buen proyecto sí. Y hace falta menos tiempo del que crees.

Aquí van tres proyectos concretos que funcionan bien en un portafolio, qué miran los revisores de verdad, cómo presentarlos en el CV y en GitHub, y cómo hablar de ellos en una entrevista sin sonar a que leíste un guion.

Qué mira quien revisa tu portafolio#

Antes de los proyectos, aclaremos qué busca la persona que abre tu GitHub. Rara vez ejecuta tu código. Lee. Escanea el README en treinta segundos y decide si sigue o cierra la pestaña.

Buscan tres cosas. Primero, que el problema tenga contexto: de dónde salieron los datos, qué se intentaba decidir o predecir, y para quién. Segundo, que el proceso se vea completo: limpieza, decisiones, evaluación, límites. Tercero, que el resultado tenga algún uso posible, aunque sea hipotético.

Lo que casi nunca miran: cuántas líneas de código tienes, si usaste la librería de moda, o si tu modelo ganó un concurso de Kaggle. Miran si piensas.

Proyecto 1: un análisis con una decisión de negocio detrás#

Este es el proyecto más infravalorado y el que mejor funciona para perfiles junior. No hace falta un modelo de machine learning. Hace falta una pregunta clara.

Ejemplo concreto: una cadena de gimnasios con datos de altas y bajas de socios quiere decidir dónde invertir en retención. Usas un CSV público de suscripciones o construyes uno razonable a partir de datos abiertos, y respondes: qué segmentos se van más, en qué momento, y qué acción propondrías.

El entregable no es un notebook con veinte gráficos. Es un informe corto de cinco páginas más tres gráficos bien elegidos, con una recomendación al final. Eso demuestra que sabes traducir datos en algo que un manager puede usar.

Si no sabes si tu pregunta es concreta de verdad, prueba a decodificar una oferta de empleo real y mira qué problemas describen las empresas. Te da una idea del lenguaje que esperan. Puedes usar el decodificador de ofertas para eso.

Proyecto 2: un modelo con pipeline de datos sucios#

Aquí sí entra el machine learning, pero el truco está en los datos. Escoge un dataset que no venga limpio. Datos abiertos de gobiernos, de APIs públicas, de scraping permitido. Lo importante es que tengas que limpiarlo de verdad: fechas inconsistentes, columnas mal tipadas, valores imposibles, duplicados.

El proyecto se trata de construir un pipeline reproducible. Que alguien pueda clonar tu repo, correr un comando, y obtener los mismos resultados. Nada de notebooks con celdas ejecutadas fuera de orden y variables mágicas.

Un ejemplo que funciona bien: predecir retrasos de vuelos con datos públicos de la FAA o de aeropuertos europeos. Hay columnas sucias, hay desbalance de clases, y hay una métrica que importa de verdad: si predices retraso y no llega, el coste no es el mismo que si fallas al revés. Elegir bien la métrica ya te diferencia de la mitad de candidatos.

Proyecto 3: algo que se despliega, aunque sea mínimo#

Un modelo en un notebook es un ejercicio. Un modelo que alguien puede usar es un proyecto. No necesitas Kubernetes ni una factura de nube de trescientos euros al mes. Necesitas algo accesible.

Puede ser una app pequeña en Streamlit o Gradio, desplegada en un plan gratuito, donde alguien sube un CSV y recibe una predicción. Puede ser una API mínima con FastAPI en un servicio con capa gratuita. Lo que importa es que el enlace funcione cuando lo pongas en tu CV.

Este proyecto también te obliga a pensar en cosas que los cursos no enseñan: qué pasa si el usuario sube un archivo con columnas de más, cuánto tarda tu modelo en responder, qué mensaje de error ve la persona. Eso es trabajo real de data scientist, aunque no lo parezca.

Cómo presentar los proyectos en tu CV#

El error típico es una línea como "Proyecto de predicción de churn usando Python". No dice nada. Otra forma:

Antes: "Análisis de datos de clientes con Python y pandas".

Después: "Analicé 45.000 registros de suscripciones para identificar los segmentos con mayor riesgo de baja; propuse tres acciones de retención priorizadas por impacto estimado y presenté los resultados a un equipo de cuatro personas".

La versión buena tiene acción, escala y resultado. Si no tienes equipo al que presentar, di que preparaste un informe con recomendaciones. No inventes audiencias que no tuviste.

Un consejo práctico: usa el verificador de ATS gratuito para comprobar que tus proyectos leen bien frente a la oferta que te interesa. Te ahorra sorpresas con el filtro automático.

Cómo montar el README de GitHub#

El README es tu carta de presentación. Estructúralo así, en este orden:

• Qué problema resuelve el proyecto y para quién, en dos frases máximo.
• De dónde vienen los datos y bajo qué licencia, con enlace a la fuente original.
• Cómo ejecutarlo, con los comandos exactos y la versión de Python.
• Qué decisiones tomaste y por qué, incluidas las que descartaste.
• Qué resultados obtuviste y qué limitaciones tiene el proyecto.
• Qué harías con más tiempo o más datos.

Nada de badges decorativos que no aportan. Nada de gifs de portada con animaciones. Un esquema simple del pipeline vale más que cualquier adorno.

Errores que hacen que tu proyecto parezca un tutorial#

Repasemos lo que delata un proyecto copiado de un curso. Si reconoces alguno de estos en tu portafolio, arréglalo antes de seguir acumulando proyectos.

• El dataset viene limpio desde el principio y no explicas cómo lo preparaste.
• Usas accuracy como única méctrica en un problema con clases desbalanceadas.
• El notebook tiene celdas ejecutadas en desorden o con variables que no se definen.
• No hay ni una frase sobre las limitaciones del modelo.
• El título del repo es "proyecto-curso-machine-learning-2" o similar.
• Copiaste la conclusión del tutorial sin cambiarla.
• El README solo dice qué librerías usaste, no qué resolviste.

Dos proyectos con criterio valen más que seis proyectos de plantilla. Este es el punto donde la gente sigue acumulando certificados en vez de arreglar lo que ya tiene. No cometas ese error.

Cómo hablar del proyecto en una entrevista#

Cuando te pregunten por un proyecto, no empieces por la librería. Empieza por el problema y por una decisión difícil que tomaste. El entrevistador quiere oír razonamiento, no un listado de tecnologías.

Un guion que funciona, adaptado al proyecto de gimnasios:

"El objetivo era reducir bajas de socios. Al revisar los datos encontré que las fechas de alta tenían dos formatos distintos, así que primero normalicé eso y perdí cerca de un cinco por ciento de registros que no pude reconciliar. Después segmenté por antigüedad y frecuencia de visitas. El hallazgo fue que las bajas se concentraban en el tercer mes, no al final del contrato. Recomendé enfocar la retención en ese periodo. Lo que no pude medir fue el efecto real de las acciones, porque no tenía datos de una campaña posterior".

Esa última frase es la que más confianza genera. Saber lo que no sabes te hace más creíble, no menos.

Prepara dos o tres variantes de esa historia según la empresa. Si buscas oportunidades, echa un vistazo a las ofertas publicadas y adapta qué proyecto destacas según lo que pida cada una.

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 necesita un portafolio de data scientist?

Tres bien hechos bastan para la mayoría de procesos. Uno de análisis, uno de modelado, uno desplegado. Seis proyectos a medias convencen menos que tres con contexto, decisiones y limitaciones claras.

¿Sirven los proyectos de Kaggle para el portafolio?

Sirven como práctica, poco como señal. El problema está definido por otros, los datos ya vienen limpios y la métrica la elige el concurso. Si incluyes uno, explica qué hiciste tú distinto y por qué.

¿Tengo que desplegar todos mis proyectos?

No, uno es suficiente. Lo importante es que ese enlace funcione el día de la entrevista y que no dependa de tu ordenador. El resto puede vivir como repositorios con un buen README.

¿Qué hago si no tengo experiencia laboral en datos?

Usa datos abiertos y plantea problemas de sectores que conozcas, aunque sea de otro trabajo. Entender el dominio compensa mucha falta de experiencia técnica y da contexto real a tus proyectos.

¿Cómo elijo el dataset para el proyecto de modelado?

Busca datos con al menos cincuenta mil filas, columnas sucias y una pregunta de negocio detrás. Evita los datasets de juguete que usan todos los cursos. Los portales de datos abiertos de gobiernos son una fuente fiable para empezar.