Posteos
Cómo armar un portfolio dev que realmente consiga entrevistas
11 de septiembre de 2026
El Developer Skills Report de HackerRank, una encuesta a más de 39.000 desarrolladores de todo el mundo, encontró que el 81% de los responsables de contratación técnica usa el currículum como primer filtro, pero que casi todos coinciden en que medir la habilidad real es la parte más difícil de todo el proceso de selección. Del otro lado, cerca de la mitad de los desarrolladores encuestados sienten que su currículum no refleja bien lo que realmente saben hacer. La consecuencia directa: la abrumadora mayoría de los responsables de contratación termina mirando proyectos y perfiles de GitHub para completar ese cuadro que el currículum solo no puede dar.
Que el proyecto esté terminado y funcione de verdad es lo primero: un demo roto o un repositorio sin instrucciones claras para correrlo genera una impresión mucho peor que directamente no tener ese proyecto. Uno más chico pero completo vale más que otro ambicioso a medio terminar. También pesan las decisiones técnicas explicadas, no solo el resultado final: un README que cuenta por qué se eligió determinada arquitectura, qué problemas aparecieron en el camino y cómo se resolvieron dice mucho más sobre el criterio de quien lo hizo que el código en sí mismo. El código legible —nombres de variables claros, carpetas ordenadas, sin restos de pruebas olvidadas— también entra en la evaluación. Y hay algo que se nota enseguida: si el proyecto resuelve un problema real, aunque sea chico, resulta mucho más interesante de conversar en una entrevista que la enésima réplica de una app tutorial.
Una contribución real a un proyecto open source, aunque sea pequeña, demuestra capacidad de leer código ajeno, seguir las convenciones de otro equipo y comunicarse a través de un pull request: habilidades que se trasladan directo al trabajo en equipo. Un proyecto con usuarios reales, aunque sean pocos —una herramienta que resuelve algo para amigos, familia o un pequeño negocio— marca una diferencia enorme frente a "código que funciona en mi máquina". Y un caso de optimización o refactorización bien documentado, mostrando el antes y el después con métricas concretas si es posible, también suma bastante.
Muchos reclutadores deciden si van a profundizar en un proyecto a partir del README, antes incluso de abrir el código. Uno bueno cuenta qué problema resuelve, qué tecnologías se usaron y por qué, cómo correrlo localmente y, si existe, un link a una demo funcionando.
Un portfolio con tres o cuatro proyectos bien documentados y terminados comunica mucho más que uno con quince a medias o sin contexto. La calidad de la presentación termina siendo, en la práctica, tan importante como la calidad técnica del código a la hora de causar una buena primera impresión.
El objetivo no es demostrar que se sabe "de todo", sino dar pie a una charla interesante en la entrevista técnica. Los mejores proyectos son los que generan preguntas genuinas sobre decisiones tomadas, problemas encontrados y aprendizajes concretos, más que una simple revisión de tecnologías usadas.
Con un 81% de responsables de contratación admitiendo que medir la habilidad real es lo más difícil de contratar, y cerca de la mitad de los propios desarrolladores desconfiando de que su currículum los represente bien, un portfolio bien armado deja de ser un detalle opcional para convertirse en la evidencia concreta que ambos lados del proceso están buscando. Un portfolio abandonado, con el último commit de hace dos años, transmite una señal poco favorable aunque el trabajo actual sea sólido. No hace falta sumar proyectos todo el tiempo, pero sí revisar de vez en cuando que los links funcionen y que el conjunto siga representando el nivel actual, no el de varios años atrás.
En esta pagina