Cómo montar un portfolio de programador que consiga entrevistas

La mayoría de portfolios que recibo para revisar tienen el mismo problema: diez proyectos, todos a medio terminar, todos con el mismo README.md genérico generado por una plantilla, y ni un solo enlace que funcione a la primera. Un reclutador o un lead técnico no va a bucear en eso. Va a mirar los primeros dos proyectos, y si no le dicen nada en treinta segundos, cierra la pestaña y pasa al siguiente candidato.

Un portfolio no es una lista de todo lo que sabes hacer. Es una demostración curada de que puedes llevar algo desde una idea hasta un producto que funciona, documentado de forma que otra persona lo entienda sin preguntarte nada. Eso es lo que se evalúa realmente, y es distinto a lo que evalúa una entrevista técnica: ahí valoran cómo razonas en directo, aquí valoran qué eres capaz de terminar por tu cuenta.

Cuántos proyectos incluir (menos de los que crees)

Tres o cuatro proyectos bien rematados superan a diez a medias, siempre. Cada proyecto adicional que enseñas es una oportunidad más de que algo falle: un enlace roto, una demo que no carga, un README a medio escribir. Si tienes quince repositorios en GitHub, elige los tres o cuatro que mejor representen lo que sabes hacer hoy y deja el resto visible en tu perfil, pero no los destaques en el portfolio.

Prioriza variedad sobre cantidad: un proyecto de backend con una API, uno de frontend con estado real (no solo un layout bonito), y si puedes, uno que combine ambos. Eso cuenta más que tres clones distintos del mismo tipo de app.

Qué debe tener cada proyecto para ser útil

No basta con "funciona". Cada proyecto necesita tres cosas visibles sin que nadie tenga que clonar el repositorio:

• Una demo en vivo. Un enlace que abra la aplicación funcionando, no capturas de pantalla. Vercel, Netlify o Render tienen planes gratuitos de sobra para esto.
• Un README que explique el porqué. No solo qué hace el proyecto, sino qué decisión técnica tomaste y por qué, y qué harías distinto si lo repitieras hoy.
• Código que se pueda leer. Nombres de variables con sentido, funciones que no mezclan diez responsabilidades, sin comentarios que expliquen código que debería explicarse solo. Si en tu día a día programas de forma más desordenada por velocidad, para el portfolio limpia lo que muestras: es tu carta de presentación, no tu backlog interno.

Un README que vende sin exagerar

El README es lo primero que se lee y, muchas veces, lo único que se lee. Uno bueno no repite el nombre del proyecto seguido de una lista de tecnologías sin contexto; explica el problema que resuelve, cómo se usa y qué parte fue la más interesante de construir.

# Gestor de gastos compartidos

App para dividir gastos entre grupos de amigos sin depender de
una hoja de cálculo. Calcula automáticamente quién debe a quién
minimizando el número de transferencias necesarias.

## Por qué lo hice así
El reto no era el CRUD, era el algoritmo de liquidación: con 6
personas y 40 gastos, una hoja de cálculo se vuelve inmanejable.
Implementé un algoritmo greedy que reduce el número de pagos
finales a un máximo de (n-1) transferencias.

## Demo
https://gastos-compartidos.vercel.app

## Stack
React + Node.js + PostgreSQL. Tests con Jest en la lógica de
liquidación (la parte que realmente podía romperse).

## Si lo repitiera hoy
Cambiaría el estado global por Zustand; usé Redux por aprender
la herramienta y fue más ceremonia de la que el proyecto necesitaba.

Fíjate en la última sección: admitir una decisión que cambiarías no resta puntos, los suma. Demuestra que tienes criterio con perspectiva, algo que se nota mucho comparado con quien defiende cada línea de su código como si fuera perfecta.

Dónde alojarlo: ¿web propia o solo GitHub?

GitHub por sí solo no es un portfolio, es un almacén de código. Una web propia, aunque sea de una sola página, te permite controlar el orden en que se ve todo, añadir contexto que no cabe en un README y enlazar tu perfil de LinkedIn y tu email de contacto sin que nadie tenga que buscarlos. No hace falta que sea compleja: una landing estática con tres tarjetas de proyecto, enlace a demo, enlace a repositorio y una breve bio es más que suficiente. Constrúyela tú mismo — es, de paso, tu primer proyecto real del portfolio.

Errores que tiran por tierra un portfolio bueno

Después de revisar bastantes, los fallos se repiten casi siempre en la misma lista: proyectos copiados de un tutorial sin ninguna modificación visible, enlaces a demos que llevan meses caídas porque el plan gratuito expiró, commits con mensajes como "cambios" o "asdf" en el historial visible, y ausencia total de forma de contactar. Ninguno de estos errores es difícil de arreglar, pero todos restan más de lo que parece porque son lo primero que se nota.

Un proyecto de tutorial sin ninguna modificación no demuestra que sepas programar, demuestra que sabes seguir instrucciones. Añade algo tuyo: una funcionalidad extra, un cambio de enfoque, algo que no estaba en el vídeo original.

Checklist: construye tu portfolio paso a paso

Cuándo enseñarlo (y cuándo no hace falta)

Adjúntalo desde la primera candidatura, no lo guardes para "cuando esté perfecto" — nunca lo está. Un portfolio con tres proyectos sólidos hoy vale más que uno con siete "algún día". Y si te preguntan en una entrevista por qué elegiste ese stack o ese enfoque, la respuesta ya la tienes escrita en tu propio README: solo tienes que decirla en voz alta.