Ruta: Portfolio Junior

Un portfolio junior no es una galería de proyectos: es una demostración de que sabes construir software de calidad. Necesita al menos un proyecto desplegado y funcional, con código limpio, tests, README profesional y CI/CD.

No importa si el proyecto es simple. Importa que esté acabado, documentado y demostrable. Un proyecto acabado vale más que cinco proyectos a medias.

Elige un problema real y resuélvelo con las herramientas que ya conoces. Un gestor de tareas, un tracker de gastos, un clon sencillo de una app que uses.

El objetivo no es impresionar con complejidad, sino demostrar que entiendes el ciclo completo: requisitos, diseño, implementación, testing, deploy y mantenimiento. Un MVP bien hecho es infinitamente mejor que un proyecto ambicioso inconcluso.

Tu README es la primera impresión. Incluye: qué hace el proyecto, por qué lo hiciste, qué tecnologías usaste, cómo ejecutarlo localmente, cómo desplegarlo, y capturas o GIFs de funcionamiento.

Escribe en inglés si puedes, o al menos un resumen en inglés. Usa badges de build status, cobertura de tests y licencia. Un README vacío o incompleto transmite desinterés o falta de atención al detalle.

Tu proyecto debe estar vivo. Usa Vercel, Netlify, Railway, Render o cualquier plataforma gratuita. Un repo sin demo es un libro sin portada.

Configura un dominio personalizado si puedes. Asegúrate de que el deploy sea automático: cada push a main debe actualizar la producción. Esto demuestra que entiendes DevOps básico, no solo desarrollo.

Tests unitarios como mínimo. Tests de integración si el proyecto lo permite. Un pipeline de CI que ejecute los tests en cada commit.

Incluye cobertura de tests en el README. No busques el 100% de cobertura buscando líneas sin sentido. Busca cubrir los casos críticos y los caminos felices y de error. Un proyecto con tests transmite profesionalidad y cuidado por la calidad.

GitHub Actions que lintee, testee y despliegue automáticamente. No es opcional: es la diferencia entre un junior que escribe código y un junior que entrega software.

Configura al menos dos workflows: uno para PRs (lint + test) y otro para main (lint + test + deploy). Incluye badges en el README. Esto demuestra que entiendes el ciclo de vida del software más allá de escribir código.

Incluye capturas de pantalla del proyecto funcionando. Mejor aún: un GIF o un video corto de demostración. Los reclutadores no van a clonar tu repo para ver qué hace.

Muestra la interfaz principal, flujos clave y estados de error. Si es una API, incluye ejemplos de requests/responses. La presentación visual reduce la fricción de evaluación y aumenta las probabilidades de que tu proyecto sea visto.

Proyectos sin terminar. README vacío. Sin deploy. Sin tests. Código sin formatear. Commits con mensajes como fix o update. Dependencias desactualizadas y vulnerables.

Cada uno de estos errores transmite una señal negativa: que no acabas lo que empiezas, que no te importa la calidad, o que no entiendes cómo se trabaja en equipo. Corrígelos antes de enviar una sola candidatura.