Portafolio de programador junior: 5 proyectos que sí se revisan

Un portafolio de programador junior no es una colección de ejercicios: es la prueba de que podés llevar una idea hasta el final y explicarla. Quien revisa tu perfil le dedica entre uno y tres minutos, así que el objetivo no es impresionar con cantidad, sino responder tres preguntas en ese tiempo: qué sabés hacer, cómo trabajás y qué hiciste vos exactamente.

Esta guía propone cinco proyectos que sí se revisan, con el nivel de profundidad esperado, la anatomía de un README que se lee rápido, un ejemplo trabajado de un portafolio real y los errores que hacen que un buen trabajo pase desapercibido.

Qué mira quien revisa un portafolio

Cuando un reclutador técnico abre tu repositorio, sigue un recorrido casi siempre igual:

1. Título y descripción. ¿Se entiende qué hace el proyecto en una frase?
2. ¿Está en línea? Si tiene URL, se abre. Si no funciona, el proyecto pierde la mitad de su valor.
3. README. ¿Cómo se ejecuta? ¿Qué decisiones tomaste? ¿Qué falta?
4. Estructura de carpetas. ¿Hay orden o todo está en un solo archivo?
5. Commits. ¿El historial cuenta un proceso o es un único "primer commit"?
6. Pruebas. Aunque sean tres, muestran que pensás en la calidad.
7. Tu contribución real. En proyectos en equipo, qué parte hiciste.

Cada punto se resuelve con poco esfuerzo si lo tenés en cuenta desde el principio. Ninguno requiere un proyecto enorme.

Proyecto 1: una API pequeña con datos reales

Qué demuestra: que entendés el ciclo completo de un servicio web.

Construí una API con tres o cuatro endpoints sobre un tema que conozcas: turnos, gastos, libros, recetas, lo que sea. Requisitos mínimos:

• Base de datos con al menos dos tablas relacionadas.
• Validación de entrada con mensajes de error claros.
• Un endpoint de salud que devuelva el estado del servicio.
• Variables de entorno para credenciales, nunca claves en el repositorio.
• Documentación de los endpoints en el README con ejemplos de petición y respuesta.

Nivel de profundidad: alcanza con que funcione en tu máquina y con instrucciones claras para levantarla. Si además está desplegada, mucho mejor.

Proyecto 2: el frontend que consume tu propia API

Qué demuestra: que podés conectar interfaces con datos y manejar estados de carga y error.

No necesita ser visualmente espectacular. Debe mostrar:

• Lista de datos con estado de carga visible.
• Formulario que envía datos y refresca la lista.
• Manejo de errores: qué ve el usuario si la petición falla.
• Diseño usable en pantalla de celular.

El error típico es hacer una pantalla linda que solo funciona con datos ideales. Un formulario que muestra "no se pudo guardar, reintentá" cuando falla la red comunica más madurez que cien animaciones.

Proyecto 3: automatización de un problema de tu trabajo actual

Qué demuestra: que identificás problemas reales y los resolvés.

Si vienes de otro rubro, este es tu mejor proyecto. Automatizá algo que hacías a mano: consolidar planillas, renombrar archivos, generar un reporte, ordenar una carpeta, revisar vencimientos.

Requisitos:

• Datos de ejemplo (nunca información real de clientes de tu empleador).
• Instrucciones para ejecutarlo en menos de cinco pasos.
• Antes y después con una medida: "el proceso manual tardaba 90 minutos y ahora tarda 2".

Ese tipo de proyecto cuenta dos cosas a la vez: que sabés programar y que entendés el objetivo del negocio.

Proyecto 4: contribuir a un proyecto existente

Qué demuestra: que podés trabajar en código que no escribiste.

Elegí un proyecto de código abierto de tamaño medio y buscá una mejora chica: corregir un error de documentación, agregar una validación, escribir una prueba que falta. El valor para tu portafolio no está en la magnitud del cambio, sino en que podés mostrar:

• Un pull request con descripción del problema y de la solución.
• Comentarios de revisión y cómo respondiste.
• Una discusión donde te corrigieron y lo aceptaste.

Muchas empresas valoran esta experiencia más que tres proyectos propios, porque demuestra el trabajo en equipo.

Proyecto 5: análisis de datos con SQL y un reporte

Qué demuestra: que sabés hacer preguntas a los datos y comunicar resultados.

Tomá un dataset público o inventá uno con volumen razonable (al menos unos miles de filas) y producí:

• Consultas SQL que respondan cinco preguntas de negocio.
• Un cuadro o gráfico por hallazgo, con títulos que expliquen la conclusión.
• Un documento de una página con los hallazgos y las limitaciones del análisis.

Este proyecto cubre dos demandas muy concretas del mercado: SQL y comunicación de resultados.

Anatomía del README que se lee en 90 segundos

El README es la portada. No es documentación completa y no debería ser un diario personal. Estructura sugerida:

# Nombre del proyecto

Una frase: qué hace y para quién.

## Problema
Qué situación resuelve, en dos o tres líneas.

## Captura
Una imagen o enlace a la versión en vivo.

## Cómo ejecutarlo
Tres comandos máximo.

## Decisiones técnicas
Por qué elegiste ese lenguaje, esa base de datos, ese enfoque.
Qué alternativa descartaste.

## Qué falta
Tres mejoras pendientes con prioridad.

## Uso de IA
Si usaste asistentes, para qué y qué revisaste vos.

La sección "Decisiones técnicas" es la que más se subestima y la que más suma: muestra criterio. La sección "Qué falta" muestra honestidad y visión. Nunca presentes una lista de funciones sin explicar por qué.

Ejemplo trabajado: portafolio de tres proyectos

Supongamos un perfil que viene de administración y quiere trabajar en desarrollo backend. Este es un portafolio posible y su justificación:

Proyecto	Qué muestra	Qué omitir
API de turnos con PostgreSQL	Modelado de datos, validaciones, endpoints	Las capturas de todos los archivos
Script de conciliación de gastos	Problema real, medida de impacto, manejo de datos sucios	La explicación de cada función
Aporte a un proyecto abierto	Trabajo en equipo, revisión, trato con mantenimiento	La captura del hilo entero de comentarios

Tres proyectos bien contados alcanzan. Si el perfil fuera frontend, se reemplazan por una interfaz con consumo de API, un componente reutilizable publicado y un aporte a una biblioteca.

Lo que unifica a los tres: cada uno resuelve un problema identificable, tiene datos o enlace para verificarlo y explícita qué hiciste vos. Esa combinación es la que hace que quien revisa te llame aunque no tengas experiencia formal.

Errores que arruinan un buen portafolio

• Demasiados proyectos y ninguno terminado. Mejor tres completos.
• Enlaces rotos o demo caída. Verificala antes de cada postulación.
• README sin instrucciones. "Clonar y ejecutar" no es una instrucción.
• Claves y archivos de entorno en el repositorio. Es un problema de seguridad real, no un detalle estético.
• Copiar un tutorial sin cambiar nada. Se nota, y no demuestra nada sobre vos.
• Nombres de repositorios genéricos. proyecto-final no dice nada; api-turnos-clinica sí.
• Explicar solo el "qué" y no el "por qué". Las decisiones son lo que se evalúa.
• Usar IA para generar código que no podés explicar. En la entrevista se nota en la primera pregunta técnica.

Limitaciones: cuándo el portafolio no alcanza

El portafolio es necesario, pero no suficiente:

• No compensa una búsqueda mal dirigida. Un portafolio excelente aplicado a roles equivocados sigue sin respuestas.
• No reemplaza la red de contactos. Las recomendaciones internas siguen siendo el canal más efectivo.
• No salva un perfil sin foco. Si tus proyectos son de tres áreas distintas, quien revisa no entiende qué querés hacer.
• No sustituye la comunicación. Saber explicar en una entrevista es lo que convierte el portafolio en oferta.
• Requiere tiempo sostenido. Un buen portafolio se construye en semanas, y eso hay que planificarlo.
• En algunos mercados pesa menos. Para roles muy competitivos o remotos internacionales, el portafolio compite con experiencia formal y títulos.

Cómo usar IA sin que el portafolio deje de ser tuyo

La IA es útil para revisar tu README, proponerte casos borde, explicarte un error o generar datos de prueba. Lo que no debería hacer es escribir el proyecto entero. Regla práctica: si no podés explicar cualquier línea de tu repositorio durante quince minutos, todavía no es tu proyecto. Declarar el uso de asistentes en el README, con una frase honesta, no te perjudica; te posiciona como alguien que trabaja con criterio.

Preguntas frecuentes

¿Cuántos proyectos necesito para buscar trabajo? Tres bien terminados alcanzan para un perfil junior. Dos pueden ser suficientes si uno es realmente sólido y está publicado.

¿Los proyectos tienen que resolver un problema real? Ayuda muchísimo, porque te da contexto para explicar decisiones. Un clon de una aplicación conocida también sirve, pero necesita una vuelta de tuerca propia.

¿Necesito desplegar los proyectos? Es muy recomendable: una URL que funciona elimina la fricción de ejecutar código ajeno. Si no podés desplegar, incluí capturas y un video corto.

¿Vale la pena un portafolio con un diseño elaborado? Con que sea legible, rápido y claro es suficiente. El diseño no compensa la falta de contenido.

¿Qué hago si no tengo idea de qué proyecto hacer? Elegí un problema que te afecte semanalmente. La motivación de resolver algo propio se mantiene mucho más que la de copiar un tutorial.

¿Debo incluir proyectos de la facultad o de cursos? Sí, si están terminados y podés explicarlos. Todo cuenta mientras sea verificable.

Siguiente paso

Si estás armando tu portafolio para buscar el primer empleo, combiná esta guía con el CV para trabajo tech y el plan de primer empleo en tecnología sin experiencia. Para la parte de código, te sirven las guías de Express desde cero y desarrollo web. Y si querés una ruta guiada con proyectos revisados, revisá los cursos de Cursalo y la categoría IA para el trabajo.