Qué mira un reclutador en un portfolio junior

Cuando todavía no tuviste un trabajo formal en tecnología, el CV se queda corto: la sección de experiencia está vacía o tiene puestos que no se relacionan con el rol al que postulás. El portfolio es la forma de llenar ese hueco con evidencia. No reemplaza la experiencia, pero le da a quien te evalúa algo concreto para mirar en lugar de tener que creerte. Esta lección explica qué buscan las personas que revisan portfolios junior y qué cosas pesan menos de lo que parece.

Para qué sirve un portfolio cuando no tenés experiencia

Un reclutador que lee el CV de alguien sin experiencia laboral tiene una duda central: ¿esta persona puede hacer el trabajo, o solo terminó un curso? El portfolio responde esa pregunta con hechos. Muestra que pudiste tomar un problema, decidir cómo resolverlo, terminarlo y explicarlo.

Eso es distinto de mostrar que sabés una tecnología. Una lista de herramientas en el CV ("HTML, CSS, JavaScript, React, SQL, Python") no prueba nada: cualquiera puede escribirla. Un proyecto terminado, con su explicación, prueba que usaste esas herramientas para algo y que entendés por qué.

Por eso el portfolio sirve para dos momentos del proceso:

• Antes de la entrevista, para que alguien decida llamarte aunque tu CV no tenga experiencia en el rol.
• Durante la entrevista, como tema de conversación. Es mucho más fácil hablar de algo que hiciste que responder preguntas en abstracto.

La revisión real: poco tiempo y tres preguntas

Es habitual que la primera mirada a un portfolio dure pocos minutos. Quien revisa abre el enlace, mira el primer proyecto, quizás un segundo, y decide si vale la pena profundizar. En ese tiempo intenta responder tres preguntas:

1. ¿Qué problema resuelve esto? Si no lo entiende en las primeras líneas, pasa al siguiente.
2. ¿Funciona y está terminado? Una demo que no carga o un repositorio con el último commit de hace dos años y un "TODO: terminar" transmiten abandono.
3. ¿Qué hizo esta persona y cómo lo pensó? Le interesa tu criterio: por qué elegiste una herramienta, qué descartaste, qué harías distinto.

Fijate que ninguna de las tres preguntas es "¿qué tan complejo es?". Un proyecto chico, claro y terminado le gana a uno ambicioso que nadie puede correr.

También importa quién revisa. En muchas empresas el primer filtro lo hace una persona de recursos humanos o de selección que no programa. Esa persona mira si el proyecto se entiende, si está prolijo y si se relaciona con el puesto. Después, alguien del equipo técnico abre el código, lee el README y mira cómo está organizado. Tu portfolio tiene que funcionar para los dos lectores.

Señales que suman

Estas son las cosas que, en general, hacen que un portfolio junior se destaque:

• Pocos proyectos, bien elegidos. Dos o tres que se relacionen con el tipo de trabajo que buscás.
• Un problema concreto. "Una app para que la verdulería de mi barrio tome pedidos por WhatsApp y los vea en una planilla" se entiende mejor que "una app de e-commerce".
• Documentación. Un README que explique qué hace, cómo correrlo, qué decisiones tomaste y qué aprendiste.
• Algo que se pueda ver. Una demo desplegada, capturas de pantalla, un video corto o, si es un análisis de datos, los gráficos con sus conclusiones.
• Historial de trabajo. Commits con mensajes que se entienden, distribuidos en el tiempo, que muestran que el proyecto avanzó por etapas.
• Honestidad sobre los límites. Una sección de "qué falta" o "qué mejoraría" demuestra criterio, no debilidad.

Señales que restan

Y estas son las que suelen jugar en contra:

• Clones de tutoriales sin cambios. La lista de tareas, la calculadora, el clon de una red social siguiendo un video paso a paso. No están mal como práctica, pero quien revisa ya vio cientos iguales y no le dicen nada sobre vos.
• Proyectos sin explicación. Un repositorio con el README que generó la herramienta por defecto, o directamente sin README.
• Enlaces rotos. La demo que ya no existe, el link al portfolio que da error.
• Demasiados proyectos a medio hacer. Veinte repositorios con nombres como "prueba", "test2" o "proyecto-final-v3" diluyen los buenos.
• Información personal o claves expuestas. Contraseñas, tokens de APIs o datos de personas reales subidos al repositorio. Es un error que un equipo técnico detecta enseguida y que dice mucho sobre tus hábitos.

Un ejemplo: dos portfolios para el mismo aviso

Imaginá un aviso para un puesto de desarrollo web junior en una empresa que hace sistemas de gestión para comercios. Llegan dos candidatos sin experiencia laboral.

Candidato A tiene doce repositorios públicos: una calculadora, un clon de una plataforma de streaming hecho con un curso en video, una página de recetas, varios ejercicios de un bootcamp y algunos proyectos sin nombre claro. Ninguno tiene README propio. El enlace a la demo del clon devuelve un error.

Candidata B tiene tres proyectos fijados en su perfil. El primero es un sistema de turnos para la peluquería de una amiga, con una demo funcionando, capturas y un README que explica que el problema era que los turnos se perdían en conversaciones de chat. El segundo es un pequeño panel que lee una planilla de ventas y muestra totales por semana. El tercero es una contribución a un proyecto de código abierto donde corrigió un error de la documentación y agregó una validación.

Técnicamente, quizás A sabe tanto como B. Pero B hizo el trabajo de mostrarlo, y además eligió proyectos que se parecen a lo que hace la empresa. Es muy probable que quien revisa le dedique más tiempo a B.

Error frecuente: confundir cantidad con evidencia

El error más común en portfolios junior es pensar que más proyectos es mejor. La lógica parece razonable: si muestro muchas cosas, demuestro que trabajé mucho. Pero quien revisa no tiene tiempo para abrir doce repositorios. Va a mirar uno o dos, y si justo elige el peor, esa es la impresión que se lleva.

La solución no es borrar todo tu historial, sino elegir qué se ve primero. En GitHub podés fijar hasta seis repositorios en tu perfil; en un sitio personal, decidís el orden. Lo que no está terminado o no representa tu nivel actual puede quedar privado o archivado. En las próximas lecciones vamos a ver cómo hacerlo.

Ejercicio

Abrí tu perfil de GitHub, tu sitio personal o la carpeta donde tenés tus proyectos. Mirá todo como si fueras alguien que te evalúa con pocos minutos disponibles. Para cada proyecto, respondé por escrito las tres preguntas de esta lección: qué problema resuelve, si funciona y está terminado, y si se entiende qué hiciste vos y por qué. Marcá con un tilde los que pasan las tres preguntas y con una cruz los que no. No borres nada todavía: esa lista es el punto de partida para la próxima lección.

En resumen

• El portfolio junior sirve para mostrar con evidencia que podés tomar un problema, resolverlo y explicarlo.
• La primera revisión suele ser rápida y busca tres cosas: qué problema resuelve, si funciona y cómo pensaste.
• Pocos proyectos claros, terminados y documentados pesan más que muchos clones de tutoriales sin explicación.