Portfolio Projects for Backend Developer

Tienes tres certificados de cursos y un reclutador que sigue preguntándote qué has construido de verdad. Es la situación más habitual entre quienes buscan su primer puesto backend o llevan poco tiempo, y la solución no es un cuarto certificado. Son proyectos que demuestren decisiones de diseño.

Un certificado dice que completaste un temario. Un proyecto muestra que sabes priorizar, modelar datos, manejar errores y explicar por qué elegiste una arquitectura. En backend eso pesa más, porque el trabajo real se parece mucho más a depurar un fallo de concurrencia que a seguir un tutorial.

Lo que busca quien revisa tu portfolio#

Nadie revisa tu repositorio línea por línea. Un técnico con poca disponibilidad abre tu README, mira la estructura y decide en cinco minutos si merece una entrevista. Ese tiempo es tu presupuesto.

Lo primero que busca es que el proyecto resuelva un problema concreto y no "practicar Node" o "aprender Spring". Después mira tres cosas: cómo modelaste los datos, cómo manejas errores y límites, y si el código tiene una estructura que alguien podría mantener. Por último, si el proyecto está desplegado o es fácil de levantar.

Lo que casi nadie mira: la lista completa de tecnologías, los badges de README, la cantidad de estrellas. Un proyecto pequeño y coherente gana a uno enorme e inacabado. Si tienes dudas sobre qué términos usa la oferta que estás mirando, decodifica la descripción del puesto antes de decidir qué proyecto destacar.

Tres proyectos que aguantan una revisión técnica#

1. Una API de reservas con reglas de negocio reales

Reservas de salas, de citas médicas o de mesas de restaurante. El dominio es fácil de entender y las reglas son difíciles de implementar bien: solapamientos, cancelaciones con ventana de tiempo, lista de espera, zonas horarias.

Este proyecto enseña modelado de datos y transacciones. Tendrás que decidir cómo evitas dos reservas para el mismo hueco, qué pasa si el proceso cae a mitad de una operación y cómo devuelves errores claros. Son exactamente las preguntas que harán en una entrevista técnica.

Ejemplo de cómo ponerlo en el CV, antes y después:

• Antes: "Proyecto personal de API REST con Node.js y PostgreSQL".
• Después: "API de reservas con control de solapamientos y bloqueo pesimista en PostgreSQL; soporta cancelaciones con penalización y lista de espera; desplegada en Railway con pruebas de integración en CI".

La segunda versión da material para preguntas. Un entrevistador puede preguntar por qué elegiste bloqueo pesimista y no optimista, y tú tienes una respuesta preparada.

2. Un procesador de trabajos en segundo plano

Cualquier sistema serio acaba necesitando enviar correos, generar facturas o procesar imágenes fuera de la petición HTTP. Un proyecto que haga esto con una cola, reintentos y control de errores muestra que entiendes cómo se comporta un sistema bajo carga.

Usa algo como Redis con una cola, o la infraestructura de colas de tu lenguaje. Añade reintentos con espera exponencial, un límite de intentos y un registro de trabajos fallidos que se pueda reintentar a mano. Documenta qué pasa cuando el consumidor se cae a mitad del trabajo.

Este proyecto se explica muy bien en entrevista porque es fácil de dibujar. Puedes describir el flujo completo: la petición encola el trabajo, el consumidor lo procesa, si falla se reintenta tres veces y acaba en una tabla de fallos. Esa narrativa demuestra que entiendes el sistema que construiste.

3. Un backend que integra un servicio externo de verdad

Conecta algo real: pagos con Stripe en modo test, la API de GitHub, un servicio de mapas o un proveedor de correo. La parte interesante no es la integración, sino todo lo que sale mal alrededor de ella.

El servicio externo se cae, devuelve errores que no esperabas o cambia de formato. Tendrás que manejar webhooks, verificar firmas, guardar el estado de forma idempotente y no perder datos si tu proceso se reinicia. Es un proyecto que enseña contratos entre sistemas.

Si la oferta a la que aplicas menciona pagos o integraciones, este es el proyecto que debes poner el primero en tu CV. Ajusta el orden de tus proyectos a lo que pide cada vacante, y busca posiciones abiertas donde ese trabajo tenga sentido.

Qué miran los revisores y cómo prepararlo#

Antes de enseñar nada, haz una pasada de limpieza. Este checklist cubre lo que casi siempre se revisa:

• README con qué hace el proyecto, cómo levantarlo y qué decisiones tomaste
• Variables de entorno documentadas en un archivo de ejemplo, nunca con secretos reales
• Migraciones de base de datos incluidas y un comando claro para aplicarlas
• Algunas pruebas que cubran la lógica principal, no solo el arranque
• Un endpoint de salud que indique si el servicio está vivo
• Errores con mensajes útiles, no capturas de pantalla de la consola
• Historial de commits legible, sin subir todo en un único commit gigante
• Licencia y tecnologías reales usadas, sin listar cosas que no aparecen en el código

El README es tu carta de presentación. Escríbelo pensando en alguien que no sabe nada de ti. En tres líneas debe quedar claro qué problema resuelve, cómo se ejecuta y qué decisión técnica te costó más.

Cómo presentarlo en el CV y en GitHub#

En el CV, dedica a cada proyecto entre dos y cuatro líneas. Empieza por la acción y el resultado técnico, no por "proyecto personal". Incluye el stack solo si aporta contexto, y deja el enlace al repositorio en la cabecera o junto al proyecto.

En GitHub, fija los tres repositorios arriba y ponles descripciones claras. Un nombre como booking-api es mejor que proyecto-final-curso-2024. Si el proyecto está desplegado, añade la URL en la descripción del repo y en el README.

Un buen formato para la entrada del CV es este:

"Plataforma de reservas para clínicas (Node.js, PostgreSQL). API con control de solapamientos, cancelaciones con penalización y lista de espera. Pruebas de integración en CI y despliegue en Railway. Repositorio: enlace."

Eso son tres líneas y ya invita a preguntar. Si quieres ver cómo se comparan tus proyectos con lo que pide el mercado, puedes explorar las ofertas disponibles y ajustar el foco.

Errores que hacen que parezca un tutorial#

Los proyectos que parecen copiados tienen patrones muy reconocibles. El primero: una lista de tareas, un clon de Netflix o una API de blog con autenticación básica, sin ninguna extensión propia. Si es un tutorial, añádele algo que no estaba en el vídeo y cuéntalo en el README.

El segundo error: describir tecnologías en vez de decisiones. "Usé Docker, PostgreSQL y Express" no dice nada. "Elegí transacciones de base de datos en vez de bloqueos en la aplicación porque el conflicto se resolvía en el mismo punto de escritura" dice mucho.

El tercero: repositorios sin contexto. Si no hay README, no hay forma de saber qué hace el proyecto ni cómo ejecutarlo. El cuarto: código que compila pero nunca se ha probado con datos reales, con casos límite sin cubrir.

También cuenta la antigüedad. Un proyecto de 2022 con dependencias sin actualizar y un README de dos líneas resta en vez de sumar. Mejor dos proyectos mantenidos que cinco abandonados.

Cómo hablar de ellos en una entrevista#

Prepara una explicación de dos minutos por proyecto: el problema, tu decisión principal y lo que harías distinto hoy. La última parte es la que más impresiona, porque demuestra que reflexionas sobre tu propio trabajo.

Un ejemplo de respuesta para el proyecto de reservas:

"Construí una API de reservas para clínicas porque el caso de solapamientos me obligó a pensar en concurrencia. Al principio usaba validación en la aplicación, pero aparecían duplicados bajo carga. Lo moví a una restricción de exclusión en PostgreSQL y manejé la excepción para devolver un error claro. Hoy añadiría pruebas de carga para medir el punto de saturación."

Esa respuesta tiene problema, intento, corrección y siguiente paso. Es exactamente lo que un entrevistador quiere oír, y no suena memorizada.

Cuando te pregunten por la parte más difícil, no digas "configurar Docker". Habla de una decisión con alternativas descartadas. Si te preguntan por seguridad, menciona algo concreto que hiciste: validación de entrada, límites de tasa, o verificación de firmas en webhooks.

Antes de una entrevista, repasa tus propios repositorios como si fueras el revisor. Pásale un chequeo rápido de formato y compatibilidad a tu CV, y vuelve a leer el README de cada proyecto. La mayoría de preguntas incómodas nacen de detalles que tú mismo dejaste sin documentar.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántos proyectos necesito para buscar trabajo como backend?

Dos o tres bien hechos bastan para una candidatura junior o de primer cambio. Es mejor tener dos proyectos con decisiones explicadas y pruebas que cinco repositorios vacíos de contexto. Ajusta cuál de ellos pones primero según la oferta concreta.

¿Sirve un proyecto hecho en un curso o bootcamp?

Sirve si lo extiendes más allá de lo que pidió el instructor. Añade una funcionalidad propia, un caso límite o una mejora de rendimiento, y cuéntalo en el README. Un proyecto clonado sin cambios es lo primero que un revisor descarta.

¿Necesito desplegarlo en la nube?

No es obligatorio, pero ayuda. Lo mínimo aceptable es que otra persona pueda levantar el proyecto con dos o tres comandos siguiendo tu README. Si lo despliegas, deja la URL accesible y documenta la arquitectura de forma breve.

¿Qué stack conviene elegir?

El que domines lo suficiente para explicar decisiones, no el más de moda. Si la oferta pide un lenguaje concreto, al menos uno de tus proyectos debería usarlo. Lo que se valora es la calidad de la implementación y la claridad al explicarla.

¿Cuentan los proyectos de mi trabajo actual?

Sí, con cuidado. Puedes describir lo que construiste sin revelar datos confidenciales ni código propietario. Explica el problema y tus decisiones en términos generales, y evita subir material de la empresa a tu cuenta personal.