GitHub para buscar trabajo: fija tres proyectos y documéntalos

Si buscas trabajo como desarrollador, fija tres proyectos pertinentes en GitHub y documenta cómo ejecutarlos, probarlos y reconocer tu aportación. La guía de GitHub para preparar el perfil profesional recomienda destacar entre tres y cinco proyectos relevantes y facilitar que puedan entenderse en pocos minutos. Empezar por tres te obliga a elegir qué habilidades quieres mostrar para el puesto al que aspiras.

Quien abra tu perfil debería poder identificar ese puesto, encontrar un proyecto relacionado y comprobar qué hiciste tú. Una biografía precisa orienta la visita; los repositorios fijados aportan las pruebas. El número de proyectos públicos o la actividad diaria dicen poco por sí solos sobre la calidad del trabajo que encontrará el lector.

Haz que la presentación indique qué trabajo buscas

La biografía debe explicar qué haces y hacia qué puesto orientas tu candidatura. «Desarrollador de software» deja demasiadas posibilidades abiertas. «Desarrollo interfaces web accesibles con React y busco un puesto de frontend» permite interpretar mejor los proyectos fijados. Es un ejemplo hipotético: sustituye la tecnología y la especialidad por las que puedas demostrar.

Usa el README del perfil para ampliar esa presentación: especialidad, proyectos elegidos y una forma de contacto que quieras hacer pública. El procedimiento oficial para el README del perfil explica que este aparece cuando tienes un repositorio público con el mismo nombre que tu usuario y un archivo README.md con contenido en su raíz. Ese archivo presenta a la persona; el README de cada proyecto explica el trabajo concreto.

Comprueba que ambas partes cuenten la misma historia. Si aspiras a análisis de datos, pero tu presentación habla de desarrollo móvil y los proyectos fijados son ejercicios sin relación con datos, quien evalúe la candidatura tendrá que reconstruir tu objetivo. Ajusta el perfil al puesto sin atribuirte experiencia que el código no permita examinar.

Elige los proyectos por la evidencia que aportan

Parte de la descripción del puesto que te interesa y busca trabajo público que muestre sus capacidades principales. Un repositorio puede enseñar la habilidad central; otro, una capacidad complementaria; el tercero, una contribución en código ajeno. La selección funciona cuando cada proyecto responde a una pregunta distinta, no cuando repite el mismo ejercicio con otra tecnología.

Antes de fijar un repositorio, comprueba si puedes explicar una decisión técnica, mostrar un resultado y señalar tu aportación. Un proyecto complejo que nadie puede instalar puede ser menos útil para esta muestra que uno pequeño cuyo problema, solución y límites estén claros. Si todavía no tienes tres proyectos presentables, fija los que sí lo estén y mejora los demás antes de destacarlos.

Desfija tutoriales reproducidos sin adaptación, experimentos cuyo estado no se explica y proyectos que ya no representan el puesto buscado. No hace falta borrar el historial público: los elementos fijados deciden qué encontrará primero quien visite el perfil. Para otra candidatura, revisa esa selección y cambia los proyectos si las capacidades relevantes son distintas.

Escribe un README que permita comprobar el resultado

El README de cada proyecto fijado debe llevar al lector desde «¿qué hace?» hasta «ya pude verlo o ejecutarlo» sin obligarlo a adivinar dependencias. Empieza por el problema que resuelve y el resultado que produce. Después ordena requisitos, instalación, configuración, ejecución y pruebas tal como los necesitaría una persona que llega por primera vez.

Si hay una demostración accesible, enlázala desde el repositorio y explica qué parte del sistema muestra. Si requiere una cuenta, datos de ejemplo o variables de entorno, indícalo antes de los comandos de arranque y ofrece valores de muestra que no revelen secretos. Para un servicio sin interfaz visual, una petición de ejemplo y su respuesta esperada pueden ser más útiles que una captura. Comprueba que la demostración corresponda al código disponible.

Como ejemplo hipotético, «Aplicación de tareas hecha con React» apenas ayuda a evaluar el trabajo. «Aplicación de tareas que guarda cambios localmente; incluye instrucciones de instalación, un ejemplo de uso y pruebas del filtrado» permite comprobar afirmaciones concretas. Añade qué decisiones tomaste tú y qué quedó pendiente: así el lector distingue una función terminada de una intención todavía sin implementar.

Evita que el README sea solo un inventario de dependencias. Si una tecnología importa para el puesto, relaciónala con una decisión visible en el código: cómo guardas los datos, cómo organizas los componentes o qué caso cubre una prueba. Esa explicación da una ruta para profundizar sin convertir la presentación en documentación interminable.

Deja visible cómo trabajaste con el código

El historial y las contribuciones añaden contexto después de que el README haya explicado el proyecto. En su análisis sobre GitHub y la búsqueda de empleo, Pablo Alcalde recomienda mensajes de commit descriptivos y da más peso a la calidad de los repositorios que a la cantidad de actividad diaria. Es un criterio para presentar mejor el trabajo, no una garantía de conseguir entrevistas.

Un mensaje como «update» obliga a abrir el cambio para descubrir su propósito. «Corrige la validación del formulario de registro» permite seguir la evolución del proyecto con menos esfuerzo. En los cambios futuros, agrupa modificaciones relacionadas y describe qué resolviste; reescribir el historial anterior solo para aparentar una trayectoria más pulida no aporta evidencia nueva.

Si contribuiste a un proyecto de otra persona, muestra una intervención que pueda inspeccionarse y explica tu papel: el problema abordado, la propuesta y el resultado de la revisión. Una solicitud de cambios con conversación técnica permite apreciar cómo respondes a comentarios sobre tu código. Si aún no tienes esa experiencia pública, documentar con precisión un proyecto propio ofrece una muestra más honesta que presentar como colaboración algo que no lo fue.

Una auditoría de 30 minutos para ordenar prioridades

Esta distribución de media hora es un ejercicio de priorización, no un plazo para rehacer todos tus proyectos. Dedica el tiempo al obstáculo que hoy dificulta más evaluar tu trabajo:

En cinco minutos, lee la biografía y el README del perfil pensando en el puesto deseado. Corrige la especialidad, el objetivo y el contacto.
En cinco minutos, elige hasta tres repositorios y escribe para ti qué capacidad demuestra cada uno. Desfija los que distraigan de esa selección.
En doce minutos, abre tu mejor proyecto como si no lo conocieras y corrige el primer obstáculo del README: propósito, requisito, comando de arranque, datos de ejemplo o instrucción de prueba.
En cinco minutos, comprueba la demostración y las pruebas que mencionas. Si algo falla, describe el estado real antes de presentar el proyecto como listo para usarse.
En tres minutos, observa si los cambios y contribuciones visibles permiten identificar tu trabajo. Deja anotada la mejora que requiere una sesión más larga.

Al terminar, sigue la ruta que tendría otra persona: presentación, proyecto fijado, README, demostración o ejecución y, finalmente, código. Si la ruta se interrumpe, ese punto merece la próxima corrección. Si funciona, el perfil ya ofrece una muestra concreta que puede examinarse sin depender de cuántos repositorios acumules.