Cómo redactar un CV para un puesto de ingeniero DevOps

Qué busca primero un responsable de contratación

Un responsable de contratación DevOps lee un CV buscando evidencia de dos cosas antes que nada: qué partes de la cadena de herramientas has operado realmente, y si has tenido responsabilidad en producción o solo lo has tocado en un entorno de pruebas. Están escaneando, no leyendo, en la primera pasada. Eso significa que el primer tercio de la página necesita responder 'qué han ejecutado en producción y a qué escala' sin que el lector tenga que buscarlo.

Esto es diferente de un CV de ingeniería de software, donde el escaneo busca lenguajes y diseño de sistemas. Un responsable de contratación DevOps o SRE quiere ver las herramientas específicas de orquestación y aprovisionamiento (Kubernetes, Terraform, Ansible, Pulumi), qué nube (AWS, Azure, GCP — y qué servicios dentro de ella, porque 'AWS' solo les dice poco), las herramientas CI/CD (Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD), y si has tenido guardias. Si tu CV abre con un resumen genérico sobre ser un 'profesional orientado a resultados', has usado los seis segundos que tenías en algo que no les dice nada.

Pon el stack que usaste, y tu responsabilidad específica dentro de él, en la primera entrada de trabajo, en las dos primeras líneas. 'Responsable de módulos Terraform aprovisionando clústeres EKS en tres cuentas AWS' funciona. 'Responsable de procesos de infraestructura y despliegue' no, porque sobreviviría siendo copiado en el CV de un administrador de sistemas o un ingeniero de build sin cambios. Esa es la prueba: si una frase encajaría igual de bien en el CV de otra ocupación, elimínala.

Certificaciones y cuánto cuentan realmente

No hay licencia para ejercer como ingeniero DevOps — ningún organismo de registro profesional, nada equivalente a la colegiatura de abogados o un número de instalador autorizado. Así que las certificaciones aquí funcionan como señal, no como puerta, y los responsables de contratación varían mucho en el peso que les dan. Vale la pena ser honestos sobre esa variación en lugar de pretender que hay una respuesta establecida.

Las certificaciones que realmente se reconocen en este campo son limitadas: AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect, Azure Administrator de Microsoft (AZ-104) o Azure DevOps Engineer Expert (AZ-400), Professional Cloud DevOps Engineer de Google, Certified Kubernetes Administrator (CKA) y Certified Kubernetes Application Developer (CKAD) de la CNCF, y Terraform Associate de HashiCorp. Si tienes una de estas, inclúyela con el año — las certificaciones en este campo envejecen, porque los servicios y el contenido del examen cambian cada año o dos, y una certificación de nivel asociado de 2019 se lee diferente a una de 2025.

Lo que no ayuda: listar cada curso de Udemy o Coursera que hayas completado. Un responsable de contratación que tenga que averiguar si 'Docker & Kubernetes: The Complete Guide' es una credencial reconocida por el proveedor o un curso de fin de semana asumirá lo segundo y seguirá adelante. Si el aprendizaje autodirigido es genuinamente relevante, ponlo en una línea breve de 'actualmente aprendiendo' en lugar de presentarlo como equivalente a una certificación — la diferencia es visible inmediatamente para cualquiera en el campo, y pretender lo contrario te cuesta credibilidad en todo lo demás en la página.

Algo que vale la pena nombrar directamente: no hay buena evidencia de que las certificaciones se correlacionen con el desempeño en el trabajo en este campo, y muchos ingenieros experimentados en roles senior no tienen ninguna. Trátalas como un atajo útil para un reclutador haciendo una primera pasada, no como prueba de competencia para alguien técnico haciendo la segunda.

Cómo se evidencia normalmente la experiencia en este campo

El trabajo DevOps no produce el tipo de portafolio al que un diseñador o escritor puede apuntar. Nadie puede mirar tu archivo de estado de Terraform. Así que el CV tiene que hacer el trabajo de evidenciar por sí mismo, a través de detalles específicos que son verificables en principio incluso si el lector no los verifica.

Los detalles específicos que tienen peso:

• Escala: número de nodos, clústeres, servicios o entornos de los que eras responsable. 'Gestioné la plataforma Kubernetes' es vago; 'ejecuté un clúster EKS de 40 nodos sirviendo 12 servicios de producción' no lo es.
• Métricas operacionales antes-después que puedes atribuir realmente a tu trabajo: frecuencia de despliegue, tiempo de entrega para cambios, tiempo medio de recuperación (MTTR), tasa de fallos en cambios — las cuatro métricas DORA son lo más cercano a un lenguaje de medición compartido que tiene este campo, y nombrar cuál moviste, y aproximadamente cuánto, es mucho más fuerte que 'mejoré la eficiencia de despliegue'.
• Propiedad de incidentes: si eras la persona avisada, no solo alguien en un equipo que tenía rotación de guardia. 'Guardia principal para infraestructura de pagos, una semana de cada cuatro' es específico. 'Participé en respuesta a incidentes' no lo es.
• Trabajo de migración y plataforma: mover de EC2 a contenedores, de un monolito a microservicios, de Kubernetes autogestionado a un plano de control gestionado, de Jenkins a GitOps con ArgoCD. Las migraciones son material natural para CV porque tienen un antes, después y duración claros.
• Coste: la optimización de costes en la nube es algo que los responsables de contratación con conocimientos FinOps buscan específicamente y rara vez se menciona. Si redimensionaste instancias, moviste cargas de trabajo a spot, o renegociaste capacidad reservada y redujo el gasto, dilo — este es uno de los pocos lugares donde pertenece un número, siempre que sea uno que puedas defender en una entrevista.

Lo que no evidencia experiencia: una lista desnuda de nombres de herramientas sin contexto. 'Habilidades: AWS, Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana' en la parte superior de la página le dice a un responsable de contratación que has oído hablar de estas herramientas. No les dice qué hiciste con ellas. Cada herramienta nombrada debe aparecer de nuevo, adjunta a una tarea, en algún lugar de la sección de experiencia — si no lo hace, el responsable de contratación asume razonablemente exposición en lugar de propiedad.

Qué pertenece en la página, específicamente

• El proveedor de nube y la profundidad dentro de él. No solo AWS — qué servicios. EC2 y S3 es básico; EKS, RDS, diseño de políticas IAM, peering de VPC y Lambda para automatización es un nivel diferente de la plataforma.
• Herramientas de infraestructura como código y si escribiste módulos o los consumiste. Hay una diferencia real entre escribir un módulo Terraform reutilizable usado por otros equipos y aplicar el de otra persona.
• Detalles de orquestación de contenedores: las distribuciones de Kubernetes importan (vanilla, EKS, GKE, AKS, OpenShift), al igual que las herramientas circundantes — Helm, Kustomize, mallas de servicio como Istio o Linkerd si las has usado.
• Stack de observabilidad: Prometheus, Grafana, Datadog, el stack ELK/EFK, OpenTelemetry. Di qué instrumentaste, no solo qué panel miraste.
• Plataforma CI/CD y diseño de pipeline, incluyendo si los pipelines eran algo que configuraste dentro de una plantilla existente o algo que diseñaste desde cero, incluyendo gestión de artefactos y estrategia de rollback.
• Puntos de contacto de seguridad y cumplimiento relevantes para este rol: gestión de secretos (Vault, AWS Secrets Manager), soporte de auditoría SOC 2 o ISO 27001, trabajo de IAM con privilegios mínimos. Si has pasado por una auditoría de cumplimiento como el ingeniero que tuvo que producir evidencia para ella, eso vale una línea — tanto los auditores como los responsables de contratación lo reconocen como un tipo específico de presión.
• Lenguaje usado para automatización y herramientas — Python, Go, Bash — nombrado como herramientas para un propósito (escribir operadores personalizados, scripts de automatización, CLIs internos), no como una lista genérica de 'lenguajes de programación'.

Qué dejan fuera rutinariamente los candidatos de este campo

La brecha más común es contexto de equipo y organizacional. DevOps se sitúa entre desarrollo y operaciones por definición, y un CV que no diga con quién trabajaste — 'integrado con dos equipos de producto', 'único ingeniero de plataforma apoyando a 30 desarrolladores', 'parte de un equipo SRE de cuatro personas cubriendo guardias siguiendo el sol' — deja al responsable de contratación incapaz de juzgar el alcance. El mismo trabajo de infraestructura significa algo diferente hecho solo versus hecho como parte de un equipo de plataforma de doce personas.

La segunda brecha es el fallo. Los ingenieros en este campo a menudo se sienten incómodos poniendo una caída en su CV, pero un incidente bien manejado, con una descripción clara de qué se rompió, qué hiciste y qué cambió después, es evidencia más fuerte de seniority que otra línea sobre 'mantener disponibilidad'. Cualquiera puede reclamar alta disponibilidad; no todos pueden describir qué hicieron la única vez que no estuvo disponible.

La tercera es el trabajo de mantenimiento aburrido que mantiene una plataforma funcionando — parcheo, actualizaciones de dependencias, rotación de certificados, pruebas de backup y restauración. Es poco glamuroso, así que la gente lo corta, pero un responsable de contratación construyendo un equipo pesado en ops a menudo se preocupará más por si realmente has ejecutado un simulacro de recuperación ante desastres que por si has usado la herramienta más nueva del stack.

Finalmente, la gente deja fuera qué decidieron no hacer. La ingeniería de plataforma es tanto sobre decir no a la complejidad innecesaria como sobre construir cosas. Una línea como 'recomendé no migrar a una malla de servicio por razones de coste y sobrecarga operacional' señala juicio que una lista de herramientas nunca lo hará.

Qué hacer a continuación

Revisa tu CV actual línea por línea y pregunta, para cada viñeta: ¿podría esta frase, sin cambios, estar en el CV de un administrador de sistemas o un desarrollador backend? Si es sí, añade la herramienta específica, la escala específica o la métrica específica hasta que no pudiera. Luego verifica que cada herramienta que has nombrado en una lista de habilidades también aparezca adjunta a una tarea en tu sección de experiencia — si no lo hace, añade la tarea o elimina la herramienta.

Si estás enviando solicitudes y no recibes respuesta, vale la pena verificar si la brecha es el CV o el ajuste — muchos roles DevOps anunciados bajo un título cubren trabajo real bastante diferente, desde ingeniería de plataforma hasta gestión de releases hasta SRE puro, y un CV ajustado para uno se lee como desajuste para otro. jobmarket.pro lee cada anuncio completo y prepara la solicitud desde tu experiencia real, ajustada a lo que ese rol específico está pidiendo, en lugar de enviar el mismo CV a cada publicación con el título del trabajo cambiado.