No todos los proyectos de portfolio pesan igual. Un reclutador tech dedica entre 30 y 90 segundos a revisar tu perfil antes de decidir si te llama, y lo que busca en ese tiempo no es cantidad de repositorios: busca evidencia de que resolviste un problema real de punta a punta. Esta guía detalla qué proyectos generan llamadas según el perfil (desarrollo, data, UX) y cómo presentarlos.

La mayoría de los portfolios juniors se parecen entre sí: una to-do list, una calculadora, un clon de Netflix con datos de una API pública. No está mal como práctica, pero no diferencia. El Future of Jobs Report 2025 del World Economic Forum señala que el 63% de los empleadores identifica la brecha de habilidades como la principal barrera de transformación. Eso significa que el reclutador no busca a alguien que sepa la sintaxis: busca a alguien que demuestre criterio. Y el criterio se demuestra con proyectos que tienen contexto, decisiones y resultados.

Qué mira un reclutador tech en tu portfolio

Antes de pensar en qué construir, conviene entender el filtro. En la revisión inicial, un reclutador (o un técnico que hace el screening) busca cuatro señales concretas:

• Problema claro. Puede explicar en una frase qué resuelve el proyecto y para quién.

• Decisiones justificadas. Por qué elegíste esa base de datos, ese framework, ese flujo de navegación.

• Evidencia de funcionamiento. Un demo desplegado, un video corto o capturas. Un repositorio que no corre no cuenta.

• Resultado medible. Aunque sea aproximado: tiempo ahorrado, cantidad de registros procesados, mejora en una métrica de usabilidad.

El error más común no es técnico, es narrativo: proyectos sin README, sin explicación del problema y sin ninguna referencia a por qué se tomó cada decisión. Si querés profundizar en la estructura básica antes de seguir, la guía para armar un portfolio de programador que consiga entrevistas cubre el armado del repositorio y la presentación en GitHub.

Proyectos que funcionan para perfiles de desarrollo

1. Una aplicación con autenticación, roles y datos propios

No un CRUD genérico: una app donde definas al menos dos tipos de usuario con permisos distintos y una lógica de negocio que no sea obvia. Un sistema de reservas con cupos limitados, una plataforma de tickets con estados y SLA, un panel de gestión de inventario con alertas de stock. Lo que convence es la complejidad de las reglas, no el tamaño del código.

2. Una integración con una API externa que resuelva un problema tuyo

Los reclutadores valoran cuando el proyecto nació de una necesidad real. Un bot que te avisa cuando baja el precio de algo que seguís, un dashboard que consolida tus gastos desde el CSV del banco, un scraper que arma un digest diario de una fuente que leés. Este tipo de proyecto demuestra manejo de errores, rate limits y datos sucios: exactamente lo que vas a enfrentar en producción.

3. Un proyecto con tests y CI/CD básico

Muy pocos portfolios junior incluyen tests. Sumar un set de tests unitarios, un pipeline en GitHub Actions y un deploy automático te separa de inmediato del promedio. No hace falta cobertura completa: alcanza con demostrar que sabés que el código se verifica antes de salir.

Proyectos que funcionan para perfiles de data

1. Un análisis end-to-end con datos reales y sucios

Elegí un dataset abierto de tu región (portales de datos gubernamentales, precios, transporte, salud pública) y documentá el proceso completo: obtención, limpieza, exploración, visualización y conclusión. La parte que más pesa es la limpieza: mostrar que detectaste duplicados, nulos y outliers, y que explicaste qué hiciste con cada uno.

2. Un dashboard que responda una pregunta de negocio

Un dashboard sin pregunta es un conjunto de gráficos. Un dashboard con pregunta es un producto. En lugar de "análisis de ventas", planteá "qué categorías pierden margen y en qué meses". Herramientas como Power BI o Tableau alcanzan; lo que importa es que cada visual tenga un motivo de existir.

3. Un pipeline de datos automatizado

Un flujo que extraiga datos de una fuente, los transforme y los deje listos en una tabla o planilla, corriendo de forma programada. Es el proyecto que más se parece al trabajo real de un analista o ingeniero de datos junior, y casi nadie lo tiene en el portfolio.

Proyectos que funcionan para perfiles de UX/UI

1. Un rediseño con investigación documentada

Tomar un producto existente y rediseñarlo está bien visto solo si mostrás la investigación: entrevistas (aunque sean cinco), test de usabilidad con tareas concretas, hallazgos y cómo cada hallazgo cambió el diseño. Un rediseño "porque me gustaba más" no suma.

2. Un caso de estudio con métricas antes y después

Aunque sea un proyecto propio: tasa de finalización de una tarea, cantidad de clics para completar un flujo, tiempo promedio. Poder decir "la tarea pasaba de 7 pasos a 4" convierte una opinión estética en un argumento de producto.

3. Una contribución a un design system

Documentar componentes, estados, variantes y reglas de accesibilidad demuestra madurez de proceso. Es especialmente valorado en empresas de producto, donde la consistencia pesa más que la creatividad puntual.

Cómo presentar cada proyecto para que se entienda en 60 segundos

La estructura que mejor funciona es siempre la misma, sea un repositorio o un caso en Behance:

• Una línea de qué hace y para quién. Sin jerga.

• El problema. Dos o tres oraciones de contexto.

• Las decisiones. Qué elegíste y por qué, incluyendo lo que descartaste.

• El resultado. Captura, demo en vivo o video de 40 segundos.

• Lo que harías distinto. Esta sección generá más conversaciones en entrevistas que casi cualquier otra, porque muestra autocrítica.

Tres proyectos bien documentados superan a diez a medias. Si tenés que elegir, borrá lo que no podés defender en una entrevista.

Errores que hacen que un reclutador cierre la pestaña

• Links roto o demos que no cargan.

• Repositorios sin README o con el README del template.

• Proyectos idénticos a los de un tutorial popular, sin ninguna variación propia.

• Ausencia total de métricas o resultados.

• Portfolio que no dice a qué rol apuntás.

Un dato de contexto que conviene tener presente: según el análisis del World Economic Forum sobre los empleos del futuro, las habilidades que más crecen combinan dominio técnico con pensamiento analítico y resolución de problemas. Un portfolio que explica decisiones, y no solo muestra resultados, es la evidencia más directa de esa combinación.

Cursos recomendados de Coderhouse

Los proyectos que convencen salen de práctica guiada con devoluciones reales. Según el punto de partida, estas son tres rutas útiles:

• Si empezás desde cero en desarrollo: el Curso de Desarrollo Web te da la base de HTML, CSS y JavaScript para tener un primer proyecto desplegado.

• Si querés un portfolio de nivel profesional: la Carrera de Desarrollo Full Stack incluye proyectos integradores con backend, base de datos y deploy, que son los que mejor funcionan en entrevistas.

• Si tu perfil es data: el Curso de Data Analytics y el Curso de Power BI cubren análisis end-to-end y dashboards orientados a preguntas de negocio.

• Si vas por UX/UI: el Curso de UX Research aporta la parte de investigación que la mayoría de los casos de estudio no tiene.

Sumá un proyecto por vez y documentálo apenas lo terminás: escribir el caso una semana después siempre sale peor.

Preguntas frecuentes

¿Cuántos proyectos debería tener mi portfolio?

Entre tres y cinco, bien documentados. La cantidad no compensa la falta de profundidad: un reclutador va a mirar dos o tres como máximo, y va a preguntar por el que esté mejor explicado. Es mejor tener tres proyectos que podés defender a fondo que diez que apenas recordás.

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

Sirven, siempre que los modifiques. Si seguíste un proyecto guiado, agregale una funcionalidad que no estaba, cambiale la fuente de datos o resolvele un caso de uso distinto, y explicá en el README qué parte fue tuya. El problema no es el origen del proyecto: es que sea idéntico al de cientos de personas.

¿Necesito experiencia laboral para armar un portfolio que convenza?

No. Lo que necesitás es evidencia de resolución de problemas. Un proyecto propio bien documentado, con decisiones justificadas y un resultado medible, funciona como prueba de capacidad. Muchos perfiles juniors consiguen su primera entrevista con proyectos personales que resuelven una necesidad concreta.

¿Conviene tener el portfolio en GitHub, en un sitio propio o en los dos?

Depende del perfil. En desarrollo y data, GitHub es imprescindible porque el reclutador técnico quiere ver el código. Un sitio propio suma como vidriera y como demostración de que sabés desplegar algo. En UX/UI, el caso de estudio en un sitio o en Behance pesa más que el repositorio.

¿Qué hago si mis proyectos son de tecnologías que ya no se usan?

No los borres: reescribí el README explicando qué resolvían y qué harías distinto hoy. Además, priorizá migrar uno de ellos al stack que usá la empresa a la que apuntás. Ese ejercicio de migración es en sí mismo un proyecto interesante para contar en una entrevista.