Un currículum para un puesto de DevOps o ingeniería de plataformas se lee mejor cuando destaca la fiabilidad, la responsabilidad de guardia, las migraciones de infraestructura y las herramientas de las que dependen otros equipos, en lugar de las viñetas centradas en funcionalidades que suele usar un currículum general de ingeniería de software. Los dos tipos de currículum comparten la mayoría de los mismos mecanismos: experiencia en orden cronológico inverso, un breve resumen, una sección de habilidades y viñetas que describen resultados en vez de tareas. Lo que cambia es qué resultados realmente impresionan en este tipo de puesto, ya que quienes se benefician del trabajo de infraestructura suelen ser otros ingenieros y no usuarios finales, y el propio trabajo suele ser invisible cuando sale bien.
Por qué cambia el énfasis
Una funcionalidad que construye un ingeniero de software suele tener un antes y después visible: una pantalla que no existía, un flujo que pasaba de cinco pasos a dos. El trabajo de infraestructura y plataformas rara vez logra ese mismo efecto visible, porque el mejor resultado posible suele ser que nada cambie desde el punto de vista del usuario: un despliegue que antes despertaba a alguien a las dos de la madrugada ya no lo hace, un servicio que se caía bajo carga ya no se cae. Un currículum para este tipo de puesto tiene que hacer que esa fiabilidad invisible resulte comprensible para alguien que nunca ha trabajado en infraestructura, nombrando qué dependía del trabajo y qué se habría roto sin él.
Describir la fiabilidad y el tiempo de actividad con honestidad
El trabajo de fiabilidad invita a la misma trampa descrita en cuantificar el impacto de ingeniería en un currículum sin inventar cifras: una cifra tentadora pero imposible de verificar como "mejoré el tiempo de actividad un 40 %" cuando nunca se llegó a rastrear una cifra así. Cuando existe una métrica real y actualmente comprobable, de un panel o un informe de incidente, tiene su lugar en el currículum tal cual. Cuando no existe, el alcance y un estado antes-después descrito pesan igual sin el riesgo.
Guardias y respuesta a incidentes como contenido del currículum
La responsabilidad de guardia merece mencionarse directamente en lugar de esconderse en una línea vaga como "apoyo a sistemas de producción", porque señala un nivel de responsabilidad operativa que un puesto puramente centrado en funcionalidades no tiene. Lo que se lee bien es la forma de esa responsabilidad: de qué sistema o sistemas estabas de guardia, cómo funcionaba más o menos la rotación, y una cosa concreta que cambió gracias a un incidente que gestionaste.
Migraciones y cambios de infraestructura que merece la pena nombrar
Una migración, un cambio de plataforma o un cambio de herramienta merece su propia viñeta cuando es el tipo de proyecto al que otros ingenieros tuvieron que adaptarse, en lugar de un cambio puramente interno que nadie fuera del equipo notó. Nombrar qué se movió y por qué suele aportar más información que mencionar solo el nombre de la tecnología de destino.
Herramientas de las que dependen otros equipos
Una herramienta interna merece el mismo trato que una funcionalidad orientada al cliente: qué hace, quién la usa, qué sustituyó. Presentar proyectos personales en un currículum de ingeniero de software cubre la misma estructura subyacente para trabajo construido fuera de un puesto formal, y se aplica igual de bien a una herramienta interna construida dentro de un puesto.
Ejemplo ilustrativo: una viñeta reescrita en torno a la propiedad de infraestructura
Antes, vago y orientado a funcionalidades: "Trabajé en infraestructura y despliegue para el equipo de backend." Después, reescrito en torno a la propiedad, el alcance y un estado antes-después descrito: "Fui responsable de la pipeline de despliegue de los once servicios del equipo de backend; antes la pipeline requería un paso de aprobación manual por cada servicio antes de desplegar, y tras la reescritura, una batería de pruebas superada bastaba para desplegar automáticamente, reduciendo de tres a uno el número de ingenieros que debían estar disponibles en el momento del lanzamiento."
Agrupar una lista larga de herramientas y plataformas
La sección de habilidades de un ingeniero de plataformas suele ser más larga que la de un desarrollador típico, abarcando a la vez proveedores de nube, herramientas de orquestación, sistemas de monitorización y lenguajes, exactamente el tipo de lista larga y variada que se beneficia de agruparse por categorías en lugar de dejarla en una sola línea sin ordenar.
Crea el tuyo
La plantilla Developer de CVBuilderKit está construida en torno a entradas guiadas por proyectos y responsabilidad, lo que encaja tanto con el trabajo de infraestructura y plataformas como con el código de aplicación. Empieza desde ella, o desde un documento en blanco, en el creador y reescribe tus viñetas de fiabilidad, guardia y migración en torno a lo que realmente dependía del trabajo antes de recurrir a una cifra que actualmente no puedes respaldar.