Software e Infraestructura · 2026
CV Harvard para Ingenieros/as DevOps
Tu CV es un deploy: entrega confiabilidad medible, no una lista de herramientas.
¿Cómo se hace un CV de Ingenieros/as DevOps en formato Harvard?
A los Ingenieros DevOps los contratan equipos de plataforma, SRE y organizaciones con mucha infraestructura que escanean tu CV buscando primero el radio de impacto y la confiabilidad: frecuencia de deploy, MTTR, uptime y cuánto gasto cloud lograste recuperar. El formato Harvard de una página te obliga a pasar de un muro de logos de herramientas a resultados concretos — menos incidentes, pipelines más rápidos, infra más barata — medidos en nueves, minutos y dólares. Empieza con trabajo de confiabilidad cuantificado, mantén educación y certificaciones compactas, y que cada bullet se lea como un postmortem con final feliz.
Qué buscan los recruiters
- Confiabilidad cuantificada: nueves de uptime (99,95%), MTTR reducido (45min → 8min), menos incidentes, frecuencia de deploy (semanal → 30x/día)
- Profundidad real en IaC y orquestación: Terraform, Kubernetes, Helm, ArgoCD, Ansible — con escala del clúster (nodos, pods, regiones), no solo logos
- Ingeniería de costos cloud: ahorro en $ vía rightsizing, instancias Spot/Savings Plans, autoscaling (ej. bajé la cuenta de AWS 38%, USD 420K/año)
- Resultados de pipelines CI/CD: tiempo de build reducido, lead time de deploy, rollback automatizado, % de cobertura de tests que bloquea releases
- Dominio del stack de observabilidad: Prometheus/Grafana, Datadog, OpenTelemetry, definición de SLO/SLI, ruido de alertas reducido
- Certificaciones que habilitan el rol: CKA/CKAD, AWS Solutions Architect / DevOps Engineer Professional, Terraform Associate, equivalentes GCP/Azure
Secciones requeridas, en este orden
Empieza por confiabilidad y escala, no por un muro de herramientas
- Pon una sección de Experiencia compacta justo después de Educación; abre cada bullet con el resultado de confiabilidad o costo (MTTR, uptime, $ ahorrado), no con la tecnología
- Limita el bloque de 'Habilidades Técnicas' al pie — agrupa por Cloud / IaC / Orquestación / CI-CD / Observabilidad para que el ATS haga match sin una sopa de 30 ítems
- Indica la escala de la infra dentro del bullet, no en una línea de skills: 'clúster EKS de 40 nodos, 1.200 pods, 3 regiones' le muestra al revisor tu radio de impacto al instante
- Elimina proyectos de hobby y herramientas en plan 'familiarizado con' — lista solo lo que te despertarían a las 3am a arreglar y te podrían preguntar en una entrevista
Que Educación y certificaciones jueguen al estilo Harvard
- Educación primero, una línea cada una: título, institución, año de egreso — sin promedio salvo que sea alto y hayas egresado hace poco
- Pon las certificaciones vigentes y demandadas (CKA, AWS DevOps Pro, Terraform Associate) justo bajo Educación, con el organismo emisor y el año
- Saca certificaciones vencidas o deprecadas; un CKA caducado o una cert de Cisco de 2014 señalan ops desactualizada, no profundidad
- Si eres autodidacta o de bootcamp, lidera con sistemas que pusiste en producción y certificaciones — el formato Harvard premia resultados sobre pedigrí
Una página, limpio para ATS, disciplina de texto plano
- Sin foto, sin fecha de nacimiento, sin gráficos ni barras de habilidad — los operadores de Kubernetes no tienen barras de progreso y tu CV tampoco
- Una sola columna, fuentes estándar, sin tablas ni cuadros de texto — muchos parsers ATS destrozan los CV de infra a dos columnas y devuelven basura
- Escribe la herramienta y su sigla una vez: 'Infraestructura como Código (IaC) con Terraform' para que hagan match ambas variantes
- Orden cronológico inverso, bullets con verbo de acción (Rediseñé, Automaticé, Migré) — cada línea se gana su lugar o se elimina
Ejemplo en formato Harvard
Bullets fuertes vs débiles
Responsable de pipelines CI/CD y deployments usando Jenkins.
Reconstruí el pipeline CI/CD de Jenkins a GitHub Actions con etapas de test paralelizadas, bajando el tiempo medio de build de 22min a 6min y subiendo la frecuencia de deploy de semanal a 30+ deploys/día en 14 servicios.
Nombra la migración, la métrica (tiempo de build y frecuencia de deploy) y la escala (14 servicios). El revisor entiende en segundos que esta persona es dueña del pipeline de entrega de punta a punta.
Ayudé a reducir los costos de AWS del equipo.
Bajé la cuenta de AWS un 38% (USD 420K/año) con rightsizing de 60 instancias EC2 sobredimensionadas, moviendo cargas stateless a Spot y comprometiendo Savings Plans — con una política de tagging forzada por Terraform para mantener el gasto atribuible.
Dólares y porcentaje, las palancas concretas (Spot, Savings Plans, rightsizing) y el control (política de tagging). Esto es madurez FinOps, no un 'ayudé' difuso.
Mejoré la confiabilidad y el monitoreo del sistema.
Llevé el uptime de producción de 99,5% a 99,97% definiendo SLOs en Prometheus, automatizando rollbacks con Argo Rollouts y reduciendo el ruido de alertas un 70% — bajando el MTTR de incidentes Sev-1 de 45min a 8min.
Nueves de uptime, MTTR antes/después y el tooling exacto (Prometheus, Argo Rollouts). Se lee como un postmortem de confiabilidad y prueba competencia en on-call.
Migré la infraestructura a Kubernetes.
Migré 28 servicios cercanos al monolito a un clúster EKS de 40 nodos con Helm y GitOps en ArgoCD, logrando un cutover sin downtime tras un Ingress de traffic-shifting y bajando el tiempo de aprovisionamiento por servicio de 3 días a 20 minutos.
Escala del clúster (40 nodos), el stack GitOps (Helm, ArgoCD), el mecanismo de seguridad (sin downtime, traffic-shifting) y una métrica de velocidad de aprovisionamiento. Disciplina de migración de nivel producción en una línea.
Errores comunes específicos
- Listar 30+ herramientas como un muro plano de keywords. Los reclutadores confían en la profundidad sobre la amplitud — agrupa 4-6 categorías y lista solo herramientas que te puedan poner a prueba.
- Describir tareas en vez de resultados ('responsable del monitoreo'). Cada bullet necesita un número: nueves de uptime, minutos de MTTR, dólares ahorrados o deploys por día.
- Ocultar la escala de la infra. 'Gestioné Kubernetes' no dice nada; 'EKS de 40 nodos, 1.200 pods, 3 regiones' le muestra al revisor tu radio de impacto real.
- Mantener certificaciones vencidas o deprecadas (CKA caducado, Cisco de 2014). Señalan que dejaste de aprender — sácalas y destaca las vigentes que habilitan el rol.
- Irte a dos páginas con detalle junior o proyectos de hobby. La disciplina Harvard es una página — si un bullet no tiene métrica ni escala, es relleno, elimínalo.
Tu CV empieza aquí. Decides después si pagas.
Empezar mi CVPreguntas frecuentes
- ¿Debo listar todos los clouds y herramientas que toqué, o solo los más fuertes?
- Solo los más fuertes. Un muro plano de 30 herramientas se lee como superficial y ensucia el match del ATS. Agrupa 4-6 categorías (Cloud, IaC, Orquestación, CI/CD, Observabilidad) y lista solo lo que puedas defender en una entrevista de diseño de sistemas o troubleshooting. La profundidad gana: un stack Terraform/Kubernetes/AWS que de verdad dominas supera a una sopa de logos.
- ¿Cómo cuantifico el trabajo DevOps si no 'lanzo features'?
- Tus métricas son confiabilidad y velocidad, no features. Cuantifica uptime (nueves), MTTR (minutos), frecuencia de deploy (por día/semana), tasa de fallos en cambios, tiempo de build/pipeline ahorrado y costo cloud reducido ($ y %). Estas métricas tipo DORA son exactamente lo que los hiring managers de plataforma y SRE escanean primero.
- ¿Necesito certificaciones como CKA o AWS DevOps Professional?
- No son obligatorias pero habilitan muchos roles y filtros de ATS, sobre todo CKA/CKAD para shops de Kubernetes y AWS DevOps Engineer Professional para equipos con mucha infra en AWS. Pon las certificaciones vigentes bajo Educación con emisor y año. Saca las caducadas o deprecadas — una cert vencida señala skills desactualizadas, no credibilidad.
- ¿Un CV DevOps realmente cabe en una página con todo el detalle de infra?
- Sí, y así debe ser. La regla Harvard de una página te obliga a recortar tareas y sopa de herramientas hasta dejar resultados cuantificados. Mete la escala dentro del bullet ('clúster EKS de 40 nodos') en vez de un párrafo aparte, limita las skills a un pie agrupado y deja que las métricas hablen. Los revisores dedican ~7 segundos — una página densa y orientada a resultados gana a dos de relleno.