Un portfolio que muestre criterio, no cantidad
Veinte repositorios de tutoriales terminados no dicen nada. Un proyecto con un problema real, decisiones explicadas y sus límites reconocidos vale más que todos ellos juntos, y es lo único que se puede discutir en una entrevista.
El consejo más repetido para quien empieza es «armá un portfolio». El resultado habitual es una lista de proyectos de curso: una aplicación de tareas, un clon de una red social, una tienda de ejemplo. Todos hacen lo mismo y ninguno dice nada de quien los escribió.
Lo que se está evaluando en un portfolio no es si sabés hacer que algo funcione. Es cómo pensás cuando tenés que elegir, y eso sólo se ve cuando hubo un problema real con más de una solución posible.
Qué mira alguien que evalúa
| Lo que se cree que se mira | Lo que se mira en realidad |
|---|---|
| Cuántos proyectos hay | Si hay uno con profundidad |
| Si usa tecnologías modernas | Si eligió esas tecnologías por alguna razón |
| Que el código esté prolijo | Si el problema estaba bien entendido |
| Que tenga muchas funcionalidades | Si sabe qué dejó afuera y por qué |
| Que esté terminado | Si reconoce sus límites y qué haría distinto |
El README es el proyecto
Plantilla
README de un proyecto de portfolio
Qué problema resuelve y para quién
Una o dos frases sobre el problema real, no sobre la tecnología. Ideal: un problema que vos u otra persona tenían de verdad.
Si el problema es «practicar React», decilo y no infles: se nota, y ser honesto vale más.
Cómo verlo funcionando
Un enlace a algo corriendo, o un video corto, o capturas. Y cómo levantarlo en local, en comandos que funcionen.
Muchísima gente no va a clonar el repositorio. Si no hay forma de verlo en treinta segundos, no se ve.
Las decisiones que tomaste
Tres o cuatro. Qué elegiste, qué alternativas había y por qué elegiste eso en este contexto.
Es la sección más importante y la que casi nadie escribe. Acá se ve el criterio.
Qué dejaste afuera a propósito
Lo que un sistema real necesitaría y este no tiene, y por qué no estaba en el alcance.
Reconocer límites es señal de madurez técnica, no de debilidad: muestra que sabés qué falta.
Qué aprendiste y qué harías distinto
Honesto y concreto. Un error específico y qué te enseñó.
Es la sección que mejor se convierte en conversación de entrevista.
Antes de seguir, predecí
Qué construir cuando no tenés experiencia laboral
El problema clásico de quien empieza: no hay proyectos reales porque no hubo trabajo. Hay caminos mejores que el clon de turno:
| Opción | Por qué funciona | Ejemplo |
|---|---|---|
| Un problema propio | Hay usuario real —vos— y decisiones con consecuencias | Una herramienta para algo que hacés a mano todas las semanas |
| Un problema de alguien que conocés | Aparecen requisitos que no elegiste y hay que negociar alcance | Un sistema de turnos para el negocio de un familiar |
| Contribuir a un proyecto abierto | Trabajo en código ajeno, con revisiones de gente con experiencia | Arreglar un error reportado en una biblioteca que usás |
| Reconstruir algo conocido, con foco | Permite profundizar en una parte específica | Un intérprete chico, un servidor HTTP mínimo, una base clave-valor |
Lo que preguntan sobre esto
| Muestra | Qué prueba | Qué falta casi siempre |
|---|---|---|
| Un repositorio con un proyecto | que escribís código | por qué tomaste cada decisión |
| Un post técnico | que podés explicar | nada: es la mejor pieza |
| Contribuciones a proyectos abiertos | que trabajás con otros | contexto de qué resolvía |
| Un sitio con capturas | poco | el código y el razonamiento |
Cierre
Autoevaluación
¿Lo entendiste?
Práctica