¿Realmente se lee una carta de presentación para DevOps?

Quién la lee realmente

En la mayoría de las empresas tecnológicas, una vacante de DevOps pasa primero por un ATS. Un reclutador o el responsable de contratación escanea tu CV buscando coincidencias de stack: Kubernetes, Terraform, AWS o GCP o Azure, la herramienta de CI que usas, si has ejecutado algo en producción y no solo en un tutorial. Si ese escaneo no coincide, la carta no se abre. No es un comentario sobre tu escritura; es cómo funciona el embudo cuando una oferta para un rol DevOps de nivel medio recibe aplicaciones de personas cuya única experiencia en infraestructura es un proyecto universitario.

Donde sí se lee la carta es más adelante en el proceso, o en empresas pequeñas donde el responsable de contratación hace su propia primera revisión. Un equipo de plataforma de seis personas en una startup Serie B a menudo tiene al ingeniero líder leyendo cada aplicación directamente, porque aún no tienen una capa de reclutamiento. En ese entorno, la carta se lee con atención, porque la persona que la lee va a recibir alertas junto a ti a las 3am y quiere tener una idea de cómo escribes un resumen de incidente, no solo si conoces Helm.

Así que la respuesta honesta es: depende mucho del tamaño del equipo y del proceso de contratación, y generalmente no puedes saber en qué situación estás por el anuncio. Escríbela como si un ingeniero en activo fuera a leerla, porque a veces uno lo hará.

Qué tiene que hacer que tu CV no puede

Tu CV lista herramientas. Puede decir "Terraform, Ansible, ArgoCD, Prometheus, Grafana, GitLab CI" y un punto que menciona una migración o una reducción en el tiempo de despliegue. Lo que no puede hacer bien es mostrar por qué tomaste las decisiones que tomaste, que es lo que realmente les importa a los responsables de contratación DevOps, porque el trabajo consiste principalmente en juicios bajo restricción: ¿mueves el servicio con estado a Kubernetes o lo dejas en una instancia gestionada, arreglas el test inestable o lo pones en cuarentena, llamas a alguien a las 2am o dejas que espere hasta la mañana?

Una carta de presentación que funciona para este campo responde una o dos cosas, no más:

Si tu experiencia en infraestructura coincide con la forma de su entorno. No solo los nombres de las herramientas, sino la escala y la madurez. "Ejecuté Kubernetes" significa algo diferente en una startup de cinco personas ejecutando un cluster EKS que en una empresa con cuarenta microservicios y un equipo de plataforma. Si el anuncio menciona multi-cluster, multi-región, o un régimen de cumplimiento específico (SOC 2, HIPAA, PCI-DSS), di directamente si has operado en ese contexto y qué implicaba realmente: logging de auditoría, política de rotación de secretos, aprobación de gestión de cambios, lo que fuera. Afirmaciones vagas de "experiencia con infraestructura cloud a escala" son exactamente lo que escribe cada otro candidato y se pasan por alto.

Si puedes gestionar un incidente y comunicar sobre él después. Esto es específico de los roles DevOps y cercanos a SRE de una manera que no lo es para la mayoría de trabajos de ingeniería: en algún momento serás la persona explicando a una sala, o a un documento postmortem, por qué algo cayó y qué cambió como resultado. Una frase concreta sobre una caída que diagnosticaste, un rollback que ejecutaste, o una causa raíz que encontraste supera tres frases sobre ser "apasionado de la confiabilidad". Nombra el modo de falla si puedes: un despliegue malo que omitió un health check, un state lock de Terraform que se corrompió, un certificado que expiró porque la renovación no estaba automatizada. La especificidad aquí se lee como competencia porque es muy difícil de falsificar.

Si solo puedes meter una cosa en una carta corta, que sea la historia del incidente o de responsabilidad, no la lista de herramientas: la lista de herramientas ya está en tu CV.

Dónde la carta tiene poco peso, y dónde sí

Sé honesto contigo mismo sobre esto. Si el rol es en una organización grande con un pipeline estructurado (aplicación, entrevista con reclutador, prueba técnica, entrevista de diseño de sistemas, panel), es muy improbable que la carta sea el factor decisivo. Podría ayudarte a pasar un filtro inicial si está claramente escrita por alguien que leyó la oferta, pero el ejercicio para llevar a casa o la ronda de diseño de sistemas en pizarra (diseña un pipeline CI/CD para X, depura este manifiesto roto de Kubernetes, explica cómo reducirías el MTTR de un servicio inestable) es donde se toma la decisión real. Ninguna carta compensa no poder explicar en qué se diferencia un Terraform apply de un plan, o qué sucede cuando falla el readiness probe de un pod durante un rolling update.

Dónde sí tiene peso: equipos pequeños contratando a su primer o segundo ingeniero DevOps, roles que mencionan explícitamente comunicación cross-funcional (porque estarás explicando decisiones de infraestructura a desarrolladores que no piensan en ello diariamente), y cualquier rol donde el anuncio mismo pide una carta de presentación y especifica qué debe contener. Si una oferta dice "cuéntanos sobre un incidente de producción que manejaste", esa instrucción no es decorativa. Ignorarla, o responder con entusiasmo genérico en su lugar, es un problema mayor que omitir la carta por completo.

También hay una categoría de roles DevOps y de plataforma donde un GitHub público, un repositorio personal de infraestructura como código, o un artículo de blog sobre una migración hace más trabajo que cualquier carta. Si tienes uno, enlázalo en la carta misma en lugar de enterrarlo en tu CV: un responsable de contratación que puede ver tus módulos reales de Terraform o tus playbooks de Ansible obtiene más señal de diez minutos leyendo código que de diez minutos leyendo prosa sobre tus habilidades.

Manejando las partes incómodas

Si estás pasando de un background de sysadmin o NOC a un título DevOps, o de ingeniería de software a infraestructura, dilo claramente y explica qué has estado haciendo ya que se solapa: escribir scripts de despliegue, gestionar rotaciones de guardia, construir herramientas internas, en lugar de dejar que el CV implique que un cambio de título ocurrió sin razón. Los responsables de contratación en este campo ven muchos sysadmins rebrandeándose sin la experiencia en automatización e IaC para respaldarlo, y una carta que es específica sobre qué has automatizado realmente, versus qué has operado manualmente, se lee como más creíble que una que simplemente reclama el nuevo título.

Si hay un gap, o estás aplicando algo fuera del nivel de seniority de la oferta, abórdalo en una frase y sigue adelante. No gastes espacio de párrafo defendiéndolo: gasta el espacio en la coincidencia de infraestructura y la historia del incidente, porque eso es lo que el lector está realmente verificando.

Qué hacer con esto

Abre el anuncio de nuevo y encuentra el stack específico y el punto de dolor específico que nombra: una migración, una carga de guardia, un problema de confiabilidad, un requisito de cumplimiento. Escribe un párrafo conectando tu experiencia real a esa cosa nombrada, con suficiente detalle para que no pudiera haberse copiado en una aplicación para una empresa diferente. Escribe un párrafo, o incluso dos frases, describiendo un incidente o proyecto donde tomaste una decisión de juicio y funcionó, nombrando el modo de falla o la métrica que cambió. Corta todo lo demás. Corta "apasionado de la cultura DevOps", corta "prospero en entornos de ritmo rápido", corta cualquier cosa que sería igualmente cierta si cambiaras el título del trabajo. Apunta a menos de 250 palabras: un responsable de contratación leyendo esto entre tickets no va a leer más que eso, y una carta más larga no compensa una coincidencia técnica más débil. Si existe un enlace a tu código de infraestructura o a un postmortem relevante, ponlo.

jobmarket.pro lee el anuncio completo y redacta una carta de presentación desde tu historial real de proyectos e incidentes en lugar de afirmaciones genéricas, que es el problema específico que este artículo ha estado describiendo.