Un portafolio de data science no se evalúa por la cantidad de proyectos que tiene, sino por la claridad con la que demuestra que sabés resolver un problema con datos. Analizamos cinco portafolios de perfiles junior que consiguieron su primer trabajo y encontramos cinco patrones que se repiten en todos.

La mayoría de los portafolios que no funcionan tienen el mismo problema: son colecciones de notebooks de cursos. Titanic, iris, predicción de precios de casas en Boston. Técnicamente correctos, pero indistinguibles de los otros dos mil portafolios que un recruiter vio ese mes. Los cinco casos que revisamos hicieron lo contrario: eligieron menos proyectos, los llevaron más lejos y los explicaron mejor.

Esto importa ahora porque la demanda de perfiles de datos sigue creciendo. Según el Future of Jobs Report del World Economic Forum, los especialistas en big data son la ocupación de mayor crecimiento proyectado hacia 2030, con un aumento estimado del 110%. Más demanda no significa menos competencia: significa más gente entrando al mismo tiempo. El portafolio es lo que te diferencia.

Patrón 1: un problema real, no un dataset limpio

Los cinco portafolios tenían al menos un proyecto construido sobre datos que el propio autor consiguió: scraping de avisos de empleo, una API pública de transporte, exportaciones de su trabajo anterior anonimizadas, datos de un club deportivo local.

La diferencia no es técnica, es narrativa. Un dataset de Kaggle viene limpio y con la pregunta ya definida. Cuando conseguís los datos vos, tenés que decidir qué preguntar, limpiar registros inconsistentes, resolver duplicados y justificar cada decisión. Eso es exactamente el trabajo que hace un analista los primeros meses en una empresa.

Uno de los casos que revisamos armó un proyecto con datos de alquileres scrapeados durante ocho semanas. El modelo predictivo era simple, una regresión con feature engineering básico. Lo que le consiguió la entrevista fue el apartado donde explicaba cómo detectó y descartó avisos duplicados que inflaban la oferta real de la zona.

Cómo aplicarlo

• Elegí un tema que te interese de verdad: te vas a tener que defender hablando de eso en una entrevista.

• Documentá el proceso de obtención de datos, no solo el resultado.

• Si scrapeás, revisá los términos de uso del sitio y no publiques datos personales.

Patrón 2: entre tres y cinco proyectos, no quince

Ninguno de los cinco portafolios tenía más de cinco proyectos visibles. Tres tenían exactamente tres. La lógica es simple: un recruiter técnico dedica entre dos y cinco minutos a un portafolio en la primera pasada. Quince repos hacen que no mire ninguno con atención.

Lo que sí variaba era la profundidad. Cada proyecto tenía README propio, con el problema, los datos, el enfoque, los resultados y las limitaciones. Ese último punto aparecía en todos los casos y es contraintuitivo: los portafolios que decían "este modelo no sirve para predecir fuera del rango de datos observado" generaban más confianza que los que prometían 98% de accuracy sin contexto.

Si estás armando la estructura de tus repos, vale la pena revisar cómo organizar tu perfil de GitHub como portfolio de datos, porque el orden de los repos y el pinneo cambian mucho lo que un reclutador ve primero.

Patrón 3: cada proyecto respondía una pregunta de negocio

Los cinco portafolios traducían el resultado técnico a una consecuencia práctica. No "el modelo tiene un RMSE de 0.34" sino "el modelo permite estimar la demanda semanal con un error promedio de 12 unidades, suficiente para planificar reposición".

Esta es la habilidad que más se menciona en las descripciones de puestos junior y la que menos se practica en los cursos. Un modelo sin lectura de negocio es un ejercicio; un modelo con lectura de negocio es una propuesta.

Patrón 4: el stack mostrado coincidía con el stack pedido

Los cinco portafolios mostraban SQL en al menos un proyecto. No como línea suelta en un notebook, sino como consulta con joins, agregaciones y ventanas. Tiene sentido: SQL sigue siendo el filtro de entrada más frecuente en procesos de selección de datos, y muchos candidatos lo saltean porque lo dan por sabido. La Stack Overflow Developer Survey lo confirma año tras año: SQL sigue entre las tecnologías más usadas profesionalmente, muy por encima de las herramientas que suelen ocupar el centro de los portafolios junior.

El resto del stack era deliberadamente austero:

• Python con pandas para manipulación y limpieza.

• SQL para consultas sobre datos relacionales.

• Una herramienta de visualización — Power BI, Looker Studio o un dashboard propio.

• Git con commits legibles y no un único commit llamado "final".

Nadie mostraba Spark, Kubernetes o arquitecturas de streaming. Mostrar herramientas que no vas a poder explicar en profundidad juega en contra: si aparece en el portafolio, en la entrevista te van a preguntar. Si querés sumar una capa más avanzada con sentido, empezá por entender qué es un data pipeline y para qué sirve antes de agregar tecnología nueva al repo.

Patrón 5: eran fáciles de recorrer

Los cinco tenían una página de entrada — un GitHub Pages simple, un Notion público o un README de perfil — con los proyectos listados, una línea de descripción cada uno y el link directo. Sin animaciones, sin dark mode, sin scroll infinito.

Tres de los cinco incluían además un demo desplegado. No hace falta infraestructura: un dashboard en Streamlit Community Cloud o un reporte en Looker Studio hacen que el reclutador vea el resultado sin clonar el repo ni instalar dependencias. Es la diferencia entre "confío en que funciona" y "lo estoy usando".

Lo que ninguno de los cinco tenía

• Certificados como sección principal. Aparecían al final o en LinkedIn, nunca como el primer bloque.

• Notebooks sin narrativa. Cero repos con celdas de código y nada más.

• Proyectos sin terminar. Mejor tres cerrados que ocho a medias.

• Autoevaluaciones infladas. Nadie se declaraba "experto" en algo con seis meses de práctica.

Cómo empezar si todavía no tenés nada

Un plan realista de seis a ocho semanas:

1. Semanas 1-2: elegí un tema y conseguí los datos. Definí una sola pregunta clara.

2. Semanas 3-4: limpieza y análisis exploratorio. Documentá cada decisión de limpieza mientras la tomás, no después.

3. Semanas 5-6: modelo o visualización, según el tipo de pregunta. Escribí las limitaciones.

4. Semanas 7-8: README, página de entrada y demo desplegado si aplica.

Repetí el ciclo dos veces más con problemas distintos y tenés los tres proyectos que se repetían en los casos que analizamos. Si estás arrancando desde cero y no sabés qué roles apuntar mientras armás el portafolio, este panorama de trabajos en data sin experiencia te ayuda a definir el objetivo antes de elegir los proyectos.

Cursos recomendados de Coderhouse

Si querés construir estos proyectos con acompañamiento y feedback sobre tu portafolio, hay tres caminos según tu punto de partida:

• Curso de Introducción a la Inteligencia Artificial — para empezar desde cero y entender qué problemas se resuelven con datos y modelos antes de elegir el stack.

• Diplomatura en Data — el recorrido completo de SQL, Python y visualización, con proyectos que podés llevar directo al portafolio.

• Curso de AI Engineering — para el nivel siguiente, si ya manejás Python y querés sumar modelos y despliegue a tus proyectos.

Preguntas frecuentes

¿Cuántos proyectos necesito en un portafolio de data science?

Entre tres y cinco, bien documentados. Los cinco portafolios que analizamos no pasaban de cinco proyectos visibles y tres tenían exactamente tres. La profundidad de cada uno pesa más que la cantidad total.

¿Sirven los proyectos de cursos o tienen que ser propios?

Sirven como práctica, pero no como diferencial en el portafolio. Si vas a usar un proyecto de curso, modificalo: cambiá el dataset por uno que consigas vos, agregá una pregunta nueva o llevalo hasta un dashboard desplegado. Lo que un recruiter valora es la decisión propia, no el ejercicio guiado.

¿Necesito saber machine learning para tener un portafolio válido?

No para roles de análisis de datos. Muchas posiciones junior valoran más un análisis sólido con SQL, limpieza cuidadosa y una visualización clara que un modelo mal justificado. Si apuntás a data science o ML, sí necesitás al menos un proyecto con un modelo bien explicado, incluyendo sus limitaciones.

¿GitHub, Notion o un sitio propio?

Lo que puedas mantener actualizado. GitHub es el mínimo indispensable porque ahí se ve el código y el historial de commits. Sumar una página de entrada — GitHub Pages o Notion público — ayuda a que el recruiter no técnico entienda qué hiciste. Un sitio propio es opcional y solo suma si no te distrae de terminar los proyectos.

¿Cuánto tiempo lleva armar un portafolio desde cero?

Entre cuatro y seis meses dedicando de seis a ocho horas semanales, si contás el tiempo de aprender las herramientas en paralelo. Cada proyecto completo — datos, análisis, documentación y demo — lleva entre seis y ocho semanas las primeras veces, y bastante menos cuando ya tenés el flujo armado.