Cómo crear un portafolio de datos que los reclutadores abren y leen

Un reclutador con decenas de candidaturas por revisar no va a leer tu portafolio con calma. Los sondeos de mercado y la experiencia de quienes contratan apuntan en la misma dirección: el primer vistazo dura segundos. En ese instante minúsculo, la persona decide si abre tu proyecto o pasa al siguiente candidato. Parece injusto, pero también es una oportunidad enorme: casi nadie arma su portafolio pensando en eso.

Un portafolio de datos no es un adorno ni una colección de certificados: es una prueba. Prueba de que sabes convertir una pregunta de negocio en análisis, y un análisis en decisión. En este artículo verás qué incluir, cómo estructurar cada proyecto, dónde alojar todo y qué errores hacen que el reclutador cierre la pestaña sin avisarte.

Tres proyectos buenos valen más que diez superficiales

El primer instinto de quien está empezando es acumular volumen: diez notebooks, quince repositorios, todos los ejercicios de curso que hizo. En la práctica, eso juega en tu contra. Quien evalúa juzga por el promedio de lo que ve, no por la suma. Un proyecto superficial junto a uno fuerte debilita al fuerte. La recomendación es curaduría: tres proyectos completos, cada uno cumpliendo un papel distinto.

• Un proyecto completo de punta a punta: desde la pregunta de negocio hasta la recomendación final, mostrando que recorres el ciclo entero de un análisis.
• Un proyecto del sector que buscas: si tu meta es trabajar en retail, salud o finanzas, ten un análisis con datos de ese mundo. Comunica intención y conocimiento del dominio.
• Un proyecto que muestre dominio técnico: un dashboard bien construido, un análisis en SQL, un script bien organizado. Aquí la estrella es la herramienta que pide la vacante.

La anatomía de un proyecto que convence

Lo que separa un proyecto de portafolio de un ejercicio de curso es la existencia de una pregunta que alguien pagaría por responder. Antes de abrir el editor de código, escribe la pregunta en una frase. Si no le interesaría a un gerente, empieza de nuevo. La estructura que funciona tiene tres ingredientes:

• Una pregunta de negocio real: "¿qué clientes tienen más probabilidad de cancelar?" o "¿qué región merece la próxima inversión?" son preguntas. "Análisis exploratorio de un dataset" no lo es.
• Datos públicos y verificables: portales de datos abiertos del gobierno, estadísticas oficiales, bases públicas conocidas. Datos que cualquiera puede revisar dan credibilidad y evitan problemas de confidencialidad.
• Una decisión al final: termina con una recomendación clara, del tipo "con base en estos resultados, priorizaría X". Un análisis que no señala un camino es un reporte, no un análisis.

El README que cuenta la historia

Aquí va una verdad incómoda: el reclutador rara vez lee tu código. Lo que lee es el README. Si el README no cuenta una historia clara en pocos párrafos, el código nunca será abierto. La estructura que funciona es una narrativa en cuatro actos:

1. Problema: qué pregunta de negocio motivó el proyecto y por qué importa.
2. Datos: de dónde vienen, qué contienen, qué limitaciones tienen.
3. Análisis: el camino recorrido en lenguaje simple, con uno o dos gráficos que resuman los hallazgos.
4. Conclusión: qué descubriste y qué decisión recomendarías a partir de eso.

Escribe pensando en alguien no técnico y con prisa. Si esa persona entiende el valor del proyecto en un minuto, el README cumplió su función.

Dónde alojarlo y cómo hacerlo circular

De nada sirve un portafolio impecable que nadie encuentra. Tres canales se complementan:

• GitHub: el estándar del mercado. Cuida el README de cada proyecto, fija tus mejores repositorios en el perfil y usa nombres descriptivos (nada de "proyecto-final-2").
• LinkedIn: donde el reclutador realmente vive. Publica un resumen corto de cada proyecto con el enlace, e incluye el portafolio en la sección destacada de tu perfil.
• Un sitio o página personal: opcional, pero te diferencia. Una página simple que reúna tus proyectos, con un párrafo sobre cada uno, transmite profesionalismo y facilita compartir.

Errores que hacen que el reclutador cierre la pestaña

Algunos patrones se repiten tanto que se volvieron señales de alerta para quienes contratan. Evita estos:

• Titanic sin contexto: el problema no es el dataset famoso, es repetir el tutorial sin una pregunta propia. Si usas una base conocida, aporta tu propio ángulo.
• Notebook sin narrativa: cuarenta celdas de código sin un texto que explique qué está pasando obligan al lector a descifrar. Nadie descifra: cierran la pestaña.
• Código sin explicación: scripts sueltos, sin comentarios y sin README, dicen "ejecuto comandos", no "resuelvo problemas".
• Volumen en lugar de calidad: quince repositorios de ejercicios diluyen los dos proyectos que de verdad muestran tu potencial.

La diferencia entre un proyecto que pasa desapercibido y uno que genera una entrevista suele estar en detalles de estructura, no de técnica. Compara:

Conclusión

Un buen portafolio no es el que tiene más proyectos: es el que demuestra, en pocos minutos, que piensas como alguien que resuelve problemas con datos. Elige tres proyectos, dale a cada uno una pregunta de verdad, cuenta la historia en el README y ponlo todo donde están los reclutadores. Si quieres construir ese portafolio con orientación, los cursos de Data Lover incluyen proyectos guiados pensados exactamente para eso: terminas la ruta con una prueba concreta de lo que sabes hacer.