Cómo escribir un CV eficaz
Un CV de Backend funciona cuando comunica impacto medible, tecnologías reales y contextos concretos: volúmenes, sistemas, restricciones y resultados.
Primera página: qué debe entender el recruiter en 10 segundos
Se buscan señales inmediatas: stack, seniority y tipo de sistemas.
- Rol y seniority (Junior/Mid/Senior) + años de experiencia reales.
- Stack: lenguajes y frameworks principales (p.ej., Node.js/TS, Python/FastAPI).
- Tipo de sistemas: APIs, microservicios, event-driven, data pipelines, etc.
- Contexto: cloud/DevOps, volúmenes o criticidad (pagos, e-commerce, B2B).
Redacción: bullets cortos, verificables y técnicos
Mejor 6-10 bullets potentes por experiencia que párrafos largos o “hype”.
- Usa verbos de acción: diseñado, implementado, optimizado, automatizado, migrado, reducido.
- Incluye tecnologías y decisiones: caching, índices, reintentos/DLQ, CI/CD, monitoring.
- Números solo si son reales y defendibles (P95, % latencia, uptime, volúmenes, costes).
Palabras clave útiles para ATS (sin forzar)
Incluye keywords alineadas con descripciones típicas, repartidas entre experiencia y skills.
- API REST, OpenAPI/Swagger, microservicios, event-driven, Kafka/RabbitMQ
- PostgreSQL/MySQL, Redis, MongoDB, caching, optimización de consultas
- CI/CD, Docker, Kubernetes, AWS/GCP/Azure, IaC (si se usó)
- Observability: logging, métricas, tracing, SLO/SLA
- Seguridad: OAuth2/JWT, RBAC, OWASP, gestión de secretos
Resumen profesional
El resumen (3-5 líneas) debe decir enseguida: experiencia, stack, tipo de sistemas y un resultado. Es la parte más leída después del nombre.
Estructura recomendada (simple y eficaz)
Una fórmula que casi siempre funciona para Backend.
- Quién eres + años de experiencia (o nivel junior).
- Stack y dominios (APIs, microservicios, BD, cloud).
- Fortaleza: rendimiento, resiliencia, seguridad, data pipelines.
- Opcional: 1 indicador medible (real).
Ejemplos listos (para personalizar)
Copiables y adaptables según tu perfil.
- “Backend Developer con 6+ años en Node.js/TypeScript y PostgreSQL. Diseño microservicios y APIs cloud con foco en rendimiento (P95) y observabilidad, introduciendo caching y monitoring para reducir incidentes en producción.”
- “Software Engineer orientado a backend con experiencia en Python/FastAPI y data pipelines. Acostumbrado a CI/CD y containers, con atención a seguridad (OAuth2/JWT) y calidad de código (tests y reviews).”
Experiencia laboral
Aquí se gana o se pierde. Para Backend, la experiencia debe describir sistemas, decisiones técnicas, resultados y contexto (volúmenes, restricciones, criticidad).
Bullets fuertes: qué incluir
Un buen listado cubre el ciclo: diseño → implementación → deploy → observabilidad.
- APIs: diseño, versionado, documentación y contratos con frontend/partners.
- Datos: esquema, migraciones, optimización de queries, caching y consistencia.
- Fiabilidad: reintentos/DLQ, idempotencia, circuit breaker, timeouts.
- DevOps: CI/CD, Docker/K8s (si aplica), releases y rollbacks.
- Observabilidad: métricas, logs estructurados, alerting e incident response.
Ejemplos de bullets “reales” (sin inventar resultados)
Sustituye por tu contexto.
- “Implementé idempotencia y reintentos con backoff en integraciones de pago, reduciendo duplicados e inconsistencias.”
- “Optimicé consultas e índices en PostgreSQL para endpoints críticos, mejorando tiempos de respuesta bajo carga.”
- “Introduje métricas y alerting sobre tasa de error y latencia P95, mejorando el diagnóstico y reduciendo MTTR.”
Proyectos clave y portfolio
En backend, los proyectos cuentan si demuestran capacidad: arquitectura, calidad, documentación y despliegue. Mejor 2-4 proyectos sólidos que 10 demos vacías.
Qué hace que un proyecto sea “bueno” para un CV
Un reviewer técnico busca señales de madurez, no solo código que “funcione”.
- README claro: objetivo, arquitectura, cómo ejecutar, docs API.
- Tests (aunque mínimos) y CI (badges/acciones) si es posible.
- Docker Compose o scripts de setup para reproducibilidad.
- Ejemplos de llamadas a la API y manejo consistente de errores.
Ejemplos de proyectos eficaces
Ideas típicas que ponen en valor skills backend.
- API e-commerce: auth, carrito, pedidos, pagos (demo).
- Event-driven: order processing con Kafka + reintentos/DLQ + idempotencia.
- Data pipeline: ETL con Airflow + data quality + alertas de fallo.
- Demo de observabilidad: métricas y tracing de un servicio REST con dashboards.
Competencias técnicas y transversales
En 2026 destacan competencias orientadas a producción: rendimiento, seguridad, observabilidad y delivery. Mejor agrupar skills y mantener relevancia.
Hard skills (operativas) de Backend
Competencias técnicas que se espera leer.
- APIs: REST, OpenAPI, versionado, gestión de errores, paginación/filtrado.
- BD: SQL (PostgreSQL/MySQL), índices, optimización de consultas, migraciones.
- Caching y rendimiento: Redis, profiling, P95/P99, rate limiting.
- Mensajería: Kafka/RabbitMQ, consumer groups, reintentos/DLQ.
- DevOps: CI/CD, Docker, bases de K8s, configuración y secretos.
Soft skills (que de verdad cuentan en backend)
No las escribas como adjetivos: conéctalas al contexto.
- Resolución de problemas en producción: triage y fixes rápidos.
- Comunicación técnica: explicar trade-offs y decisiones de arquitectura.
- Colaboración: contratos API con frontend y alineación con product.
- Ownership: mantenimiento de servicios, reducción de deuda técnica, mejoras de calidad.
Competencias 2026 valoradas (si son reales)
Inclúyelas solo si las has usado de verdad.
- Observabilidad (métricas/logging/tracing) y mentalidad SLO.
- Secure coding (OWASP), gestión de secretos, auditoría.
- Entrega progresiva (canary/feature flags) y estrategia de rollback.
- Conciencia de costes cloud: optimización de recursos y escalado.
Formación
En Backend, la formación cuenta, pero gana la demostración práctica: proyectos, experiencia y capacidad de trabajar en sistemas reales.
Título académico
Indica grado/bachillerato y centro. Si tienes experiencia, evita detalles innecesarios.
Cursos útiles y creíbles
Mejor pocos cursos bien elegidos que una lista infinita.
- Fundamentos cloud (AWS/GCP/Azure) si encaja con tu experiencia.
- Kubernetes (solo si realmente trabajaste con containers/orquestación).
- Seguridad / OWASP / secure coding (si aplicado en proyectos o trabajo).
- Bases de datos y performance tuning (si puedes describir intervenciones reales).
Idiomas
En roles tech, el inglés se usa a menudo para documentación, tickets y llamadas. Indica niveles reales y qué puedes hacer de verdad.
Cómo indicarlos de forma creíble
Mejor un nivel realista y una nota práctica que un “excelente” no defendible.
- Indica nivel (A1-C2) o básico/intermedio/avanzado de forma coherente.
- Si lo usas en el trabajo: “lectura de documentación técnica y comunicación por tickets/llamadas” (si es cierto).
Indicadores y métricas (KPI) para Backend
En backend, los KPI se relacionan con calidad y producción: latencia, errores, incidentes, fiabilidad y costes. Usar el lenguaje correcto ayuda, sin inventar cifras.
Métricas típicas monitorizadas
A menudo se siguen con dashboards y alerting.
- Latencia P95/P99 en endpoints críticos (tiempo de respuesta).
- Tasa de error (4xx/5xx) y estabilidad del servicio.
- Throughput (req/s) y capacidad en picos.
- MTTR (tiempo medio de recuperación) y número de incidentes.
- Uptime/disponibilidad y cumplimiento de SLO/SLA (si aplica).
Cómo incluirlas sin “disparar números”
Si no tienes datos, describe acciones y contexto; si los tienes, usa solo los reales y defendibles.
- “Optimicé consultas y caching para mejorar tiempos de respuesta en endpoints de alto tráfico.”
- “Implementé dashboards y alerting para reducir el tiempo de diagnóstico en producción.”
- Si tienes números reales: “reduje P95 en X%”, “reduje MTTR”, “mejoré uptime” (solo si es defendible).
Herramientas y stacks típicos
Mostrar familiaridad con herramientas reales reduce el riesgo percibido (onboarding más rápido).
Stack y herramientas que puedes citar (si las usaste de verdad)
Describe lo que has utilizado en trabajo o proyectos.
- APIs: OpenAPI/Swagger, Postman/Insomnia.
- BD: PostgreSQL/MySQL + herramientas (psql, migraciones, ORM si aplica).
- Cache/cola: Redis; Kafka/RabbitMQ (incluso en demos).
- DevOps: Docker, GitHub Actions/GitLab CI, bases de K8s.
- Observabilidad: logging estructurado, métricas y tracing (herramientas varias).
Cuándo citar herramientas específicas
Solo si son realmente relevantes y puedes sostenerlo en entrevista.
- Si la oferta pide una herramienta (p.ej., Kafka, K8s), citarla ayuda.
- Si no recuerdas nombres de plataformas internas, describe la función y el contexto.
Formato y maquetación ATS
Un CV ATS-friendly es legible tanto por software como por un hiring manager. Sencillez y estructura estándar ganan siempre, especialmente en tech.
Formato recomendado
Guías prácticas que funcionan en la mayoría de casos.
- 1 página para junior; 1-2 páginas para mid/senior.
- Secciones estándar: Resumen, Experiencia, Proyectos, Skills, Formación, Idiomas, Certificaciones.
- Bullets cortos (1-2 líneas) y keywords dentro del texto.
- PDF limpio, fuente estándar, sin gráficos complejos ni columnas extremas.
Qué evitar (problemas ATS típicos)
Pueden “romper” la lectura automática.
- Texto dentro de imágenes, iconos o barras de progreso.
- Diseños en múltiples columnas demasiado agresivos.
- Tablas complejas para experiencia y tecnologías.
Errores a evitar
Son errores que hacen descartar un CV backend incluso con buen perfil.
Demasiado genérico o solo buzzwords
Escribir “microservicios, cloud, DevOps” sin contexto no comunica nada.
- Añade lo que hiciste: APIs, BD, caching, CI/CD, observabilidad, incidentes.
- Añade contexto: tráfico, criticidad, sistemas integrados, restricciones.
Skills infladas o no sostenibles
En tech se valida todo en entrevista.
- Evita listar 20 tecnologías si realmente usas 3.
- No declares “Kubernetes avanzado” si solo viste un tutorial.
Sin evidencia de calidad y producción
En backend moderno cuentan tests, delivery y observabilidad.
- Cita tests y reviews, aunque mínimos pero reales.
- Cita pipelines y monitorización si los has usado.
- Muestra responsabilidad: incident response, mejoras, mantenimiento.
CV Backend Developer junior / entry-level
Si eres junior, debes demostrar potencial y solidez: fundamentos, proyectos, capacidad de aprender y uso de herramientas reales (Git, API, BD).
Qué incluir en lugar de experiencia “real”
Usa lo que demuestre habilidades prácticas aunque no sea laboral.
- Proyectos personales (API + BD) con README, tests básicos y Docker.
- Prácticas/bootcamps: describe tareas técnicas concretas (APIs, queries, bugfix).
- Contribuciones open-source (aunque pequeñas): issues, PRs, documentación.
- Retos técnicos: explícalos con claridad, sin exagerar.
Resumen junior: ejemplo listo
Ejemplo concreto, sin inventar experiencia.
- “Perfil junior orientado a backend: he desarrollado APIs REST con Node.js/Python y PostgreSQL, cuidando validación de inputs, gestión de errores y documentación OpenAPI. Cómodo con Git y Docker para entornos reproducibles, con atención a calidad y buenas prácticas.”
Skills a poner (si eres junior)
Elige skills coherentes y defendibles.
- Fundamentos de API REST, HTTP, códigos de estado, auth básica (JWT).
- SQL y modelado de datos básico (joins, indexación conceptual).
- Git, debugging, tests unitarios básicos.
- Docker nivel inicial para levantar un stack local.
CV para cambio de carrera (desde otros roles)
Si vienes de QA, IT, data, frontend o soporte, conecta competencias transferibles y proyectos que demuestren backend real.
Cómo poner en valor el pasado
No lo borres: tradúcelo al lenguaje backend.
- Desde QA: foco en calidad, automatización, testing, prevención de incidentes.
- Desde IT/ops: foco en entornos, deploy, monitorización, troubleshooting.
- Desde data: foco en pipelines, ETL, BD, rendimiento de queries.
- Desde frontend: foco en contratos API, integraciones y debugging end-to-end.
Qué hace falta para ser creíble
2-3 proyectos bien hechos valen más que una lista larga de cursos.
- Una API completa con auth, BD, validación, manejo de errores y docs.
- Un proyecto “production-like”: logging, métricas o al menos patrones de resiliencia.
- Un README claro y una demo reproducible (Docker Compose).
Carta de presentación
Si se solicita, debe ser breve y concreta: stack, contexto, disponibilidad y 1-2 evidencias (proyecto, resultado, ownership).
Estructura en 6 líneas (funciona de verdad)
Perfecta para candidaturas tech: directa y sin relleno.
- 1 línea: rol y por qué te postulas.
- 1-2 líneas: stack y qué sabes hacer (APIs, BD, microservicios, CI/CD).
- 1 línea: prueba (proyecto/resultado real).
- 1 línea: por qué esa empresa (producto/stack/sector).
- 1 línea: cierre y disponibilidad para entrevista.
Ejemplo breve (copiable)
Adáptalo con empresa y disponibilidad.
- “Me postulo para la posición de Backend Developer en [Empresa]. Tengo experiencia en APIs y microservicios con Node.js/TypeScript y Python, con fuerte enfoque en rendimiento, bases de datos y CI/CD. He trabajado en integraciones y mecanismos de resiliencia (reintentos/idempotencia) y he mejorado la observabilidad para reducir problemas en producción. Me interesa especialmente [motivo específico ligado al producto/stack]. Quedo a disposición para una entrevista.”
