Cómo construir tu portafolio de programador en GitHub
Arnold Wender · · 12 min de lectura
Ver todo: ProgramaciónTu currículum dice que sabes programar. Tu portafolio en GitHub lo demuestra o lo desmiente.
En 2026, los recruiters técnicos revisan perfiles de GitHub antes de la primera llamada —los estimados de la industria oscilan entre el 78% y el 87% para posiciones de ingeniería. No es un extra decorativo: es la primera impresión real que tienes antes de que cualquier entrevistador abra tu CV. Y la diferencia entre un perfil que genera respuestas y uno que se ignora no está en cuántos repos tienes, sino en cómo los presentas y qué dicen sobre cómo piensas cuando construyes software.
Esta guía no te va a enseñar Git desde cero —para eso existe Git y GitHub desde cero. Esto es sobre estrategia: qué proyectos construir, cómo documentarlos, qué señales manda tu actividad y cómo evitar los errores que hacen que los perfiles de juniors se parezcan todos entre sí.
Lo que necesitas saber antes de empezar
- Calidad sobre cantidad — 3 a 5 proyectos bien ejecutados y documentados superan a 20 repos a medias; los recruiters no tienen tiempo de revisar montones de código sin contexto
- El README es la puerta de entrada — cada proyecto debe explicar qué resuelve, para quién, qué stack usa y cómo ejecutarlo; código sin README es código inaccesible
- Un demo en vivo vale más que capturas — desplegar tu proyecto en Vercel, Netlify o Railway elimina la fricción de que alguien tenga que ejecutarlo localmente
- El perfil README es tu cara — el repo
usuario/usuarioaparece en tu página de perfil y es lo primero que ve cualquiera; merece un párrafo honesto, tu stack actual y un solo link de contacto - La actividad constante manda señales — commits regulares, PRs y contribuciones muestran que sigues activo; un jardín de contribuciones plano desde hace seis meses dice que dejaste de crecer
- Evita el catálogo de tutoriales — clonar el proyecto de un curso y subirlo sin modificaciones no cuenta como proyecto; en todo caso es deuda de originalidad
Visita Programación en Geekshop para más guías de herramientas y carrera técnica.
Por qué tu portafolio en GitHub importa más que tu título
El mercado técnico en México y Latinoamérica tiene un problema de señal. Los títulos universitarios son heterogéneos —un egresado del Tec tiene una formación distinta a uno de la UNAM, que tiene otra distinta a alguien autodidacta que aprendió con MOOCs. Para los equipos de ingeniería, esa varianza hace difícil calibrar sin ver código.
GitHub resuelve eso. Es evidencia observable. No te creen que “tienes experiencia con React” porque lo pusiste en el CV; lo verifican en diez segundos revisando si tus proyectos de React tienen manejo de estado, separación de componentes, gestión de efectos secundarios y algo que funcione en producción.
LA PRIMERA IMPRESIÓN
Tu perfil README: el resumen que nadie quiere leer pero todos leen
GitHub tiene una función que poca gente usa bien: si creas un repositorio con el mismo nombre que tu usuario —por ejemplo, si tu usuario es maria-lopez, el repo se llama maria-lopez— el README de ese repo aparece destacado en tu página de perfil.
Ese espacio es tu oportunidad de contexto. No para escribir una novela: los recruiters tienen entre 30 y 90 segundos por perfil. Lo que funciona es:
- Una línea de bio directa: qué haces y en qué especialidad te enfocas
- Tu stack principal —tres o cuatro tecnologías en las que tienes profundidad real, no la lista de todo lo que instalaste alguna vez
- En qué estás trabajando o aprendiendo ahora mismo
- Un solo link externo que valga la pena visitar (tu portafolio web, tu LinkedIn, o directamente tu mejor proyecto)
Lo que no funciona: listas interminables de badges de tecnologías que no has usado en proyectos reales, GIFs animados que hacen lenta la carga, frases genéricas como “apasionado del código” o “siempre aprendiendo” sin sustancia detrás.
Las herramientas como GPRM o el GitHub Profile README Generator sirven como punto de partida, pero el resultado de cualquier generador es reconocible a distancia. Úsalos para el esqueleto y reescribe cada sección con tu propia voz.
Qué proyectos subir y cuáles dejar en tu disco duro
El error más común de los portafolios junior es ser un archivo de cursos: to-do lists, calculadoras, clones de Netflix sin terminar, APIs de clima que son el “Hola mundo” de los tutoriales de backend. Esos proyectos no dicen nada sobre cómo resuelves problemas. Solo dicen que seguiste instrucciones.
Los proyectos que generan conversación en entrevistas tienen algo en común: resuelven un problema que alguien tuvo, no un ejercicio académico.
SELECCIÓN DE PROYECTOS
3 a 5 proyectos con historia propia valen más que 20 repos vacíos
La estructura que funciona para un portafolio de 3 a 5 proyectos:
Un proyecto complejo que muestre tu stack principal en serio. Si eres frontend, una aplicación con autenticación, estado compartido, llamadas a API y al menos un flujo no trivial —no un carrusel de imágenes. Si eres backend, algo con lógica de negocio real, manejo de errores, tests y documentación de endpoints.
Un proyecto que resolvió un problema tuyo o de alguien que conoces. Esta es la categoría más subestimada. Una herramienta de CLI que automatiza algo que hacías a mano, un bot que procesa un tipo de dato específico, un script de análisis que corriste para un proyecto escolar o de trabajo. La originalidad del problema habla más que la complejidad técnica.
Un proyecto que muestre que entiendes el ciclo completo: diseño, implementación, despliegue y documentación. No tiene que ser grande. Tiene que estar terminado y ser accesible.
Lo que debe tener cada repo en tu portafolio:
- README que abre con qué hace el proyecto y para quién (no con el stack técnico —eso va después)
- Instrucciones de instalación que funcionen en una máquina limpia
- Link al demo desplegado si existe
- Descripción de una o dos decisiones técnicas que tomaste y por qué — esto es lo que diferencia un proyecto documentado de un proyecto explicado
- Capturas de pantalla o un GIF corto mostrando el flujo principal
Las plataformas de despliegue gratuitas que funcionan en 2026 para demos: Vercel para proyectos Next.js y frontend, Netlify para sitios estáticos, Railway para backends con base de datos, Render para APIs con capa gratuita (tiene cold starts), y GitHub Pages para proyectos estáticos sin backend.
Tabla de elementos por tipo de proyecto
| Tipo de proyecto | README mínimo | Demo requerido | Tests | CI/CD básico |
|---|---|---|---|---|
| App full stack (React + API) | Sí, con capturas | Muy recomendado | Al menos unitarios del backend | Deseable |
| API REST o GraphQL | Sí, con docs de endpoints | Opcional (Postman collection sirve) | Unitarios + integración | Deseable |
| Herramienta CLI | Sí, con ejemplos de uso | No aplica | Recomendados | No necesario |
| Sitio estático / portafolio web | Sí, breve | Obligatorio | No necesario | No necesario |
| Librería o paquete npm | Sí, con API docs | No aplica | Obligatorios | Sí (publica en npm) |
| Script de automatización | Sí, con ejemplos de input/output | No aplica | Opcionales | No necesario |
La columna de tests merece una nota: no es que recruiters vayan a ejecutar tu suite de tests. Es que la presencia de tests —aunque sean básicos— señala que piensas en el comportamiento esperado de tu código, no solo en que “funciona en mi máquina”. Es una señal de madurez que pocos juniors mandan.
Actividad constante vs. sprints de commits
Hay un patrón frecuente en perfiles junior: tres semanas de actividad intensa cuando terminan un bootcamp, y después un jardín de contribuciones plano durante meses. Ese patrón no dice “programador activo”; dice “programador que terminó un curso”.
Un portafolio en GitHub no es un archivo estático — es un historial en movimiento que muestra cómo creces.
La actividad consistente no requiere commits diarios ni trabajar doce horas. Requiere un hábito sostenible: refactorizar algo que dejaste a medias, agregar tests a un proyecto que no los tiene, actualizar dependencias con vulnerabilidades, mejorar la documentación cuando encuentras algo que no explica bien. Esos commits pequeños pero reales son más honestos que un day de commits de conveniencia.
Los proyectos open source son otra forma de generar actividad con contexto. No tienes que hacer contribuciones épicas para empezar: corregir un typo en un README, traducir documentación, reportar un bug con un caso reproducible mínimo o responder preguntas en Issues son formas legítimas de aparecer en el historial de proyectos que otros usan.
Para encontrar proyectos donde contribuir en es-MX, hay repositorios como UXCorpRangel/portfolios-dev o cualquier proyecto con la etiqueta good-first-issue en GitHub Explore filtrado por el lenguaje que usas.
Errores comunes que hundien tu portafolio antes de que alguien lo revise
Para ver qué más puedes agregar a tu entorno de trabajo como programador, revisa la guía de mejores herramientas para desarrollador en Geekshop.
El README de proyecto que sí funciona
La documentación es el skill más subestimado en programación junior y el que más separa a los candidatos cuando los proyectos tienen calidad similar. Un README bien escrito demuestra que puedes explicar sistemas técnicos a otras personas —que es exactamente lo que haces en reuniones de equipo, code reviews y handoffs.
La estructura que funciona es directa:
1. Qué es esto — una o dos oraciones que explican qué hace el proyecto y para quién es útil. No empieces con el stack técnico.
2. Demo — un link si existe. Si no existe, una captura o GIF del flujo principal.
3. Stack y decisiones técnicas — por qué elegiste estas herramientas para este problema, no solo una lista de lo que usaste.
4. Cómo ejecutarlo localmente — instrucciones que funcionen en una máquina limpia, con los prerequisitos explícitos.
5. Una decisión técnica interesante — un párrafo sobre un problema que resolviste durante el desarrollo. Este apartado es opcional pero es el que más conversación genera en entrevistas.
Las herramientas de automatización que vale la pena conocer en 2026 para mantener el README actualizado: Shields.io para badges de estado que se actualizan solos (CI, versión, cobertura de tests), y workflows de GitHub Actions que regeneran secciones con datos en tiempo real como tu última actividad de commits o tus posts de blog.
FAQ
¿Cuántos proyectos necesito en mi portafolio para conseguir mi primer empleo?
La respuesta estándar de la industria es 3 a 5 proyectos bien ejecutados. No es un mínimo absoluto —hay personas que consiguen trabajo con un solo proyecto de gran calidad— pero 3 proyectos con distintos niveles de complejidad y distintos tipos de problemas te dan variedad suficiente para mostrar versatilidad sin diluir la calidad de cada uno. Lo que sí es un umbral real: si todos tus proyectos son ejercicios de tutorial, el número no importa.
¿Tengo que tener mis propios proyectos o puedo colaborar en proyectos de otros?
Ambas cosas cuentan y se complementan. Proyectos propios demuestran iniciativa y capacidad de llevar algo de principio a fin. Contribuciones a proyectos de terceros —open source— demuestran que puedes trabajar en una base de código que no construiste, leer código de otros y colaborar con estándares que no elegiste. Los equipos de ingeniería valoran las dos capacidades, y la segunda es más difícil de demostrar con solo proyectos personales.
¿Importa el lenguaje o framework que uso?
Para conseguir un trabajo específico, sí importa alinearte con el stack del equipo. Para construir un portafolio como programador en general, lo que importa más es demostrar que entiendes los conceptos —manejo de estado, diseño de APIs, modelado de datos, tests— porque esos transferieren entre tecnologías. Un proyecto sólido en Vue muestra capacidades similares a uno en React para alguien que evalúa la profundidad técnica, no el conocimiento de sintaxis.
¿Los proyectos de cursos y bootcamps cuentan?
Cuentan si los modificaste de forma sustantiva. Si tomaste el proyecto de un curso y le agregaste funcionalidad que el instructor no pedía, lo desplegaste, lo documentaste y puedes explicar las decisiones que tomaste, es un proyecto tuyo que partió de un punto de partida prestado. Si es el mismo código que todos los alumnos del curso entregaron sin cambio, no cuenta —los recruiters que contratan para empresas medianas y grandes han visto esos proyectos muchas veces.
¿Importa tener muchos seguidores o estrellas en GitHub?
No para conseguir trabajo. Las estrellas son una métrica de popularidad de proyecto, no de calidad técnica. Un proyecto útil para un nicho pequeño puede tener cero estrellas y ser exactamente el tipo de trabajo que un equipo quiere ver. Donde sí importan las estrellas es si estás construyendo proyectos open source como estrategia de visibilidad a largo plazo —pero eso es una táctica de carrera avanzada, no el punto de partida.
Fuentes
La plataforma mencionada se apoya en su documentación oficial:
- GitHub Docs — GitHub (documentación oficial)