¿Cómo escribo un CV para un puesto de ingeniero backend?

Has desplegado servicios que manejan tráfico real, te han despertado a las 3am con un aviso, y no recibes respuestas de las solicitudes. La razón más probable no es que tu CV esté mal redactado. Es que la primera persona en leerlo es un reclutador que no puede evaluar ingeniería, trabajando desde una lista de requisitos, y tu CV no responde esa lista en los primeros treinta segundos. La segunda razón más probable es que cuando llega a un gerente de ingeniería, se lee como una lista de tickets en lugar de un registro de sistemas que gestionaste.

Ambos problemas son solucionables, y las soluciones son específicas para este trabajo.

No hay cualificaciones, registros ni licencias — di lo que es verdad

La ingeniería backend en el Reino Unido no tiene título protegido, ningún organismo de registro del que dependa la contratación, ni licencia. La acreditación BCS y CEng existen y casi nunca son un factor para conseguir una entrevista backend fuera de algunos contratistas de defensa, ferrocarril y nuclear. Un título en ciencias de la computación es común y no es obligatorio; el aprendizaje Level 6 Digital and Technology Solutions Professional y las rutas de bootcamp a industria están bien representados en equipos que contratan bien. Si tienes cinco o más años de experiencia en producción, la línea del título es una línea cerca del final, sin los módulos.

Las cosas que sí funcionan como credenciales en este campo son diferentes:

Autorización de seguridad. La autorización SC o DV es una puerta real para trabajo backend en Home Office, MoD, proveedores de GCHQ, y muchas consultorías del Crown Commercial framework. Si la posees, ponla en el encabezado con el nivel y si está vigente o caducada. Si la has tenido y ha caducado, di eso también — una autorización caducada es mucho más barata de reinstaurar que empezar desde cero, y los gerentes de contratación en ese sector lo saben.

Derecho a trabajar. Si tienes indefinite leave to remain, settled status, o un pasaporte que no necesita patrocinio, ponlo en una línea. Los empleadores capaces de patrocinar son una minoría y los que no lo son te filtrarán silenciosamente en lugar de preguntar.

Exposición a cumplimiento de dominio. Ámbito PCI DSS, sistemas de producción regulados por FCA, NHS DSP Toolkit, HIPAA, controles ISO 27001 que realmente implementaste. Estas no son certificaciones que obtuviste, son restricciones bajo las que has trabajado, y en contratación fintech y salud tienen más peso que cualquier certificado. "Construí y operé servicios dentro del ámbito de entorno de datos de tarjetahabientes PCI DSS" es una línea que se lee dos veces.

Qué escanea primero un gerente de contratación backend

En orden, aproximadamente, y rápido:

1. Lenguaje y runtime principal, con versión. Java 8 y Java 21 son trabajos diferentes. Mantenimiento de Python 2 y Python async moderno son trabajos diferentes. Go, Kotlin, C#/.NET, Node/TypeScript, Ruby, Rust, Elixir, Scala — sea cual sea, necesita ser legible en el primer tercio de la página uno, no enterrado en un bloque de habilidades al final.
2. Almacenes de datos. Postgres, MySQL, MongoDB, DynamoDB, Cassandra, y qué hiciste con ellos. "PostgreSQL" por sí solo no le dice nada a un gerente. "Postgres: diseño de esquema, ajuste de índices, particionado de una tabla que había superado el rendimiento de consultas de un solo nodo, migraciones sin tiempo de inactividad con escritura dual y relleno" les dice todo.
3. Si has ejecutado cosas en producción. Rotación de guardia, respuesta a incidentes, SLOs, presupuestos de error, revisiones post-incidente que escribiste. Un ingeniero que solo ha entregado código a un equipo de operaciones es una contratación diferente de uno que ha sido avisado por su propio servicio, y esto se verifica temprano.
4. Escala y forma del tráfico. No para impresionar a nadie — para determinar si tus instintos se transfieren. Tasas de solicitudes, volúmenes de datos, objetivos de latencia, tamaños de lotes, número de inquilinos. Usa tus números reales. Si no los tienes, describe la forma en su lugar: "transacciones financieras de bajo volumen y alto valor donde la corrección importaba más que el rendimiento" es una frase genuinamente informativa y no es un número que tuviste que inventar.
5. Mensajería e integración. Kafka, RabbitMQ, SQS/SNS, Pub/Sub, gRPC, REST, GraphQL, webhooks. Si diseñaste los contratos o consumiste los de alguien más.

Todo lo demás — Kubernetes, Terraform, pipelines CI, proveedor de nube — importa, pero es la segunda pasada. Los ingenieros que lideran con un muro de nombres de servicios de AWS y entierran el lenguaje se están clasificando en el montón equivocado.

Evidencia en este campo significa sistemas, no responsabilidades

La diferencia más grande entre un CV backend que consigue una llamada de selección y uno que no es la diferencia entre describir un rol y describir un sistema.

Un rol suena como: "Responsable de desarrollar y mantener microservicios en un entorno Java/Spring Boot usando metodologías ágiles."

Un sistema suena como: "Gestioné el servicio de cumplimiento de pedidos: Kotlin/Spring Boot, Postgres, grupo de consumidores Kafka procesando eventos del servicio de checkout. Rediseñé el consumidor para ser idempotente después de que entregas duplicadas estaban produciendo pedidos con doble cobro; introduje una tabla outbox para que la escritura y la publicación compartieran una transacción."

El segundo apenas es más largo. Le dice a un gerente lo que sabes sobre que la entrega exactamente una vez es una mentira, outboxes transaccionales, y el modo de fallo que encontraste. Le da al entrevistador una pregunta para hacerte, que es el propósito real del documento.

Escribe dos o tres de estos por rol reciente. No ocho. Elige aquellos donde algo fue difícil y puedes explicar el compromiso.

Qué omiten rutinariamente los ingenieros backend

Esta es la parte que le cuesta entrevistas a la gente, y es consistente.

Migraciones. Descomposición de monolito, Python 2 a 3, Postgres autogestionado a RDS o Aurora, on-prem a nube, REST a gRPC, un broker de mensajes a otro, un salto de versión mayor de framework en docenas de servicios. Los ingenieros las omiten porque no eran funcionalidades y se sentían como mantenimiento. Los gerentes de contratación las valoran mucho, porque el trabajo de migración es donde aparecen juicio, compatibilidad hacia atrás, feature flags, escrituras duales, rellenos y planes de rollback todos a la vez. Si has liderado una, pertenece cerca del principio de ese rol.

Modelado de datos. "Diseñé el esquema" es una frase que la mayoría de ingenieros backend pueden escribir honestamente y la mayoría no lo hace. Di cuáles eran las entidades, cuál era la restricción complicada, y qué te equivocaste y tuviste que cambiar.

Trabajo operacional con un costo asociado. Reducir gasto en nube, eliminar un cluster de Redis que nadie necesitaba, dimensionar instancias correctamente, eliminar un N+1 que estaba martillando una réplica de lectura. Los ingenieros piensan que esto es poco glamuroso. Cualquiera con un presupuesto no.

Incidentes. No para admitir culpa — para demostrar que has estado cerca de producción cuando se rompió. "Diagnostiqué agotamiento de pool de conexiones bajo un pico de tráfico; introduje PgBouncer y un circuit breaker en la llamada descendente" es una línea fuerte.

Testing más allá de la palabra 'tests'. Testing de contratos entre servicios, Testcontainers, tests basados en propiedades, testing de carga con k6 o Gatling, cómo probaste una migración. "Escribí tests unitarios" es ruido. "Construí tests de contratos entre nuestro servicio y tres consumidores para que pudiéramos desplegar independientemente" es una señal de contratación.

La forma del equipo y el código. Cuántos ingenieros, cuántos servicios gestionaste, qué tan antiguo era el código, si eras el único ingeniero backend. Trabajar solo en un monolito Rails legacy y trabajar en un equipo de plataforma de doce son ambos respetables y ninguno es inferible de un título de trabajo.

Documentos de diseño y RFCs. Si estás aplicando a nivel senior, staff o principal, lo que se evalúa es el alcance de la toma de decisiones técnicas. Escribir documentos de diseño contra los que otros equipos construyeron es la evidencia más clara de ello. Di cuántos, sobre qué, y quién era la audiencia.

La sección de habilidades, y cómo generalmente falla

El fallo común es una lista de sesenta tecnologías en un párrafo, incluyendo cada servicio de AWS para el que alguna vez abriste la consola. Se lee como relleno y hace invisible una fortaleza genuina.

Agrupa por función y mantén cada grupo corto: lenguajes, almacenes de datos, mensajería, infraestructura, observabilidad. Descarta cualquier cosa sobre la que no quisieras que te preguntaran durante diez minutos. No pongas años junto a cada elemento y no pongas barras de competencia ni calificaciones de estrellas en nada — un gerente de ingeniería que lee "Kafka ★★★☆☆" no aprende nada y forma una opinión sobre el autor.

Si eres un ingeniero full-stack aplicando para roles backend, el bloque de habilidades es donde decides de qué trata el CV. React, Tailwind y Figma cerca del principio te harán leer como un ingeniero front-end que quiere un cambio. Mantén la experiencia front-end — es contexto genuinamente útil — pero ponla después del material backend y descríbela como lo que fue.

Cosas que son contestadas, honestamente

Certificaciones de nube. AWS Solutions Architect Associate, GCP Professional Cloud Developer, CKA. En consultorías, integradores de sistemas, tiendas partner de AWS y partes del sector público estas tienen peso visible, a veces porque el estatus de partner del empleador depende del recuento de personal que las tiene. En la mayoría de empresas de producto están cerca de neutral, y un puñado de ingenieros senior activamente las descuentan. No hay una respuesta universal honesta. Mira si el anuncio las nombra. Si lo hace, ponlas en el encabezado. Si no, una línea al final.

Enlaces a GitHub. Un perfil de ocho repos de tutorial y un dotfiles forkeado es peor que ningún enlace. Un solo servicio desplegado con un README que explica los compromisos, o un enlace directo a un PR mergeado en un proyecto que alguien más mantiene, vale mucho. Enlaza a la cosa específica, no al perfil.

Longitud. La regla de una página es una convención americana que no gobierna la contratación de ingeniería en el Reino Unido. Dos páginas es normal para un ingeniero de nivel medio, tres es aceptable a nivel staff con una larga historia, y los roles mayores de aproximadamente diez años deberían colapsar a una sola línea cada uno. Prioriza el inicio sin importar qué.

Proyectos personales a nivel senior. Algunos gerentes los leen como entusiasmo, algunos como una señal de que no estás obteniendo suficiente trabajo interesante. Si el proyecto demuestra algo que tu trabajo pagado no — trabajo de sistemas distribuidos, un lenguaje al que quieres moverte — mantenlo. De lo contrario está compitiendo por espacio con tu experiencia de producción y perdiendo.

Qué hacer a continuación

Toma el último anuncio backend del que fuiste rechazado sin respuesta. Escribe las cuatro o cinco cosas que realmente pide — el lenguaje, el almacén de datos, el broker de mensajes, la escala, si quiere alguien que haya estado de guardia. Luego abre tu CV y cronometra cuánto tarda en encontrar cada una. Si alguna de ellas tarda más de unos segundos en localizar, muévela hacia arriba.

Luego reescribe las dos viñetas más fuertes en tu rol más reciente como sistemas en lugar de responsabilidades: en qué se construyó, con qué hablaba, qué se rompió o fue difícil, qué cambiaste. Mantén los números reales que tienes y describe la forma donde no los tengas.

Hacer esto correctamente para cada anuncio es lento, por lo que la mayoría de la gente deja de hacerlo después de las primeras docenas de solicitudes; jobmarket.pro lee cada anuncio completo y prepara la solicitud desde un perfil al que no puede agregar experiencia.