Un perfil de GitHub bien ordenado es hoy el filtro más rápido que aplican los reclutadores técnicos: dedican menos de un minuto a mirarlo y deciden si vale una entrevista. Lo que define ese minuto no es la cantidad de repositorios ni el gráfico de contribuciones, sino tres cosas: un README de perfil que explique quién sos, entre dos y cuatro proyectos fijados con documentación clara y demo funcionando, y evidencia de que el código es tuyo y lo entendés.

La mayoría de los perfiles junior fallan por lo mismo: veinte repositorios de tutoriales sin descripción, ningún proyecto fijado, README vacíos y links que no abren. No es un problema de habilidad técnica, es un problema de presentación, y se arregla en un fin de semana.

Los relevamientos del sector son bastante consistentes en la magnitud: alrededor del 87% de los reclutadores técnicos revisa el GitHub del candidato antes de decidir si avanza con una entrevista, y quienes tienen un perfil activo reciben notablemente más respuestas, según los checklists de perfil que publican las plataformas de contratación técnica. También aparece un dato que conviene tener presente: buena parte de los responsables de contratación considera que un GitHub sólido puede compensar la falta de formación formal.

Los seis elementos de un perfil que consigue respuestas

1. README de perfil: tu presentación de treinta segundos

Es el archivo especial que se muestra arriba de tu perfil. Tiene que responder cuatro preguntas en pocas líneas: qué hacés, qué stack usás, qué estás construyendo ahora y cómo contactarte.

Lo que no conviene poner: listas interminables de íconos de tecnologías, estadísticas automáticas de contribuciones, frases motivacionales. Ocupan la parte más valiosa de la pantalla y no aportan información evaluable.

2. Dos a cuatro proyectos fijados, no más

La función de repositorios fijados existe para que vos elijas qué se mira. Si no la usás, el reclutador ve tus repos por fecha, que casi nunca son los mejores.

Criterio de selección: elegí los proyectos que puedas defender en una conversación de veinte minutos. Uno bueno vale más que cinco a medio hacer. Si tenés un proyecto que resuelve un problema real —aunque sea chico y personal— fijalo antes que cualquier clon de aplicación conocida.

3. README de proyecto con estructura fija

Esta es la parte que más diferencia genera y la que menos gente hace bien. Cada proyecto fijado necesita:

• Una línea de qué hace y para quién, arriba de todo.

• Captura o GIF del proyecto funcionando. Es lo primero que se mira.

• Link a la demo desplegada y funcionando.

• Stack usado en una lista corta.

• Cómo correrlo localmente en tres o cuatro pasos.

• Decisiones técnicas: dos o tres párrafos explicando por qué elegiste determinada estructura o librería y qué alternativas descartaste.

Ese último punto es el que convierte un repositorio en evidencia de criterio. Sin él, el proyecto solo prueba que sabés seguir un tutorial.

4. Demos desplegadas y funcionando

Un link roto es peor que no tener link: comunica descuido. Antes de cada tanda de postulaciones, abrí todas tus demos en una ventana privada y verificá que carguen. Los servicios de despliegue gratuitos suelen suspender proyectos inactivos, así que este chequeo hay que repetirlo.

5. Historial de commits que se pueda leer

Un repositorio con un único commit llamado "proyecto final" genera dudas sobre la autoría. Un historial con commits descriptivos y progresivos muestra proceso. No hace falta que sea perfecto, pero sí que cuente una historia coherente.

6. Una contribución externa, aunque sea chica

Corregir documentación, arreglar un error menor o mejorar un ejemplo en un proyecto de código abierto demuestra que sabés trabajar en un repositorio ajeno: leer el código de otros, seguir convenciones y abrir un pull request. Es una señal desproporcionadamente valiosa para el esfuerzo que requiere.

Qué mira un reclutador y en qué orden

El orden importa porque define dónde poner el esfuerzo. Optimizar el código de un proyecto que nadie va a abrir porque el README es confuso es esfuerzo mal invertido.

Errores que descartan un perfil

• Veinte repositorios de tutoriales sin descripción. Archivá o borrá lo que no aporte. Un perfil con cuatro repos buenos supera a uno con treinta mediocres.

• Credenciales o claves de API en el historial. Es motivo de descarte inmediato en muchos equipos, porque habla de criterio de seguridad. Revisá el historial, no solo el estado actual del código.

• Nombres de repositorio sin significado. "proyecto1", "test", "prueba-final" no dicen nada. Usá nombres descriptivos.

• Cero actividad en los últimos seis meses. Si estás buscando trabajo, tiene que haber movimiento reciente.

• Código generado por IA sin entender. Se detecta en la entrevista con dos preguntas. Usá asistentes, pero revisá y comprendé cada parte de lo que subís.

Plan de dos días para ordenar tu perfil

Día 1 — Limpieza y selección.

1. Listá todos tus repositorios públicos y clasificalos: mostrar, archivar, borrar.

2. Elegí los tres mejores y verificá que corran localmente.

3. Revisá el historial buscando claves o datos sensibles.

4. Fijá los tres elegidos en el perfil.

Día 2 — Documentación y despliegue.

1. Escribí el README de cada proyecto con la estructura de seis puntos.

2. Desplegá los que sean desplegables y verificá los links en ventana privada.

3. Escribí el README de perfil.

4. Tomá capturas o grabá un GIF corto de cada proyecto funcionando.

Dos días de trabajo cambian de forma medible la tasa de respuesta a las postulaciones. Es una de las intervenciones con mejor relación esfuerzo-resultado en toda la búsqueda de empleo tech. Si querés ampliar sobre qué tipo de proyectos elegir, esta guía sobre qué proyectos de GitHub buscan los recruiters complementa bien el criterio de selección, y el material de portfolio para programadores junior cubre la parte del sitio propio.

Qué proyectos conviene tener fijados según el rol que buscás

• Frontend: una aplicación con estado complejo, consumo de API real y diseño responsive. Idealmente con atención a accesibilidad, que es una habilidad escasa.

• Backend: una API con autenticación, base de datos, manejo de errores y tests. La documentación de los endpoints cuenta como parte del proyecto.

• Full stack: un proyecto completo desplegado, con frontend y backend en repos separados o en un monorepo bien organizado.

• Datos: un análisis con notebook limpio, conclusiones escritas y un tablero o visualización. El razonamiento vale más que el modelo.

• IA y automatización: una aplicación que integre un modelo resolviendo un problema concreto, con manejo de errores y control de costos.

La regla general: el proyecto tiene que parecerse a lo que harías en el puesto que buscás. Un clon de red social no dice nada sobre tu capacidad de resolver el problema de la empresa; una herramienta que resuelve una tarea real, sí.

Cursos recomendados de Coderhouse

Si el problema es que todavía no tenés proyectos propios que valga la pena fijar, la salida es formación con entregas obligatorias:

• Nivel inicial: el Curso de JavaScript te da la base del lenguaje y termina con proyectos propios que podés documentar y desplegar.

• Nivel intermedio: la Carrera de Desarrollo Full Stack genera durante el trayecto los tres o cuatro proyectos completos que después vas a fijar en el perfil.

• Para diferenciarte: el Curso de Python o el Curso de AI Engineering te permiten sumar un proyecto con integración de IA, que hoy es el tipo de repositorio que más atención genera: el World Economic Forum reporta un premio salarial cercano al 23% para candidatos con habilidades de IA declaradas frente a perfiles comparables sin ellas.

Lo importante no es la cantidad de cursos, sino que cada uno deje un proyecto terminado, desplegado y explicable.

Preguntas frecuentes

¿Importa el gráfico de contribuciones diarias?

Mucho menos de lo que se cree. Los reclutadores no cuentan cuadrados verdes: miran los repositorios fijados, la calidad de los README y si hay actividad reciente. Forzar commits diarios sin contenido real no mejora tu perfil y consume tiempo que rinde más documentando un proyecto existente.

¿Cuántos repositorios debería tener visibles?

Entre cuatro y ocho públicos, con dos a cuatro fijados. Más que eso diluye la atención y suma ruido. Todo lo que sea ejercicio de curso sin modificaciones propias conviene archivarlo: archivar no borra el historial, solo lo saca del listado principal.

¿Puedo subir proyectos que hice con ayuda de IA?

Sí, y es lo normal hoy. La condición es que entiendas cada parte de lo que subís, porque en la entrevista te van a preguntar por decisiones específicas. Una buena práctica es aclarar en el README qué herramientas usaste durante el desarrollo: transmite transparencia y criterio, no debilidad.

¿Sirve tener un perfil de GitHub si busco roles no técnicos como datos o producto?

Para roles de datos, sí y bastante: notebooks limpios con análisis documentados son evidencia directa. Para producto o roles de negocio, el peso es menor y conviene priorizar un portfolio propio con casos escritos. Aun así, un repositorio con automatizaciones o análisis funciona como diferencial en perfiles no técnicos que trabajan con datos.

¿Qué hago si mi mejor proyecto es de una empresa y no lo puedo publicar?

No publiques código que no te pertenece. Lo que sí podés hacer es escribir un caso: qué problema había, qué enfoque usaste, qué resultado tuvo, sin exponer código, datos ni información confidencial. Ese caso puede ir en el README de perfil o en tu sitio personal, y en la entrevista podés explicarlo con más detalle respetando el acuerdo de confidencialidad.