Google DevOps Engineer: CV, palabras clave y entrevista

No te llaman a entrevista y sospechas que tu CV se queda en el filtro automático. O te llaman, pero la entrevista técnica te descuadra. Pasar el proceso de selección de Google para un rol de DevOps o SRE (Site Reliability Engineering) es un reto distinto al de otras empresas, y requiere una preparación específica.

Tu CV no es un diario de lo que has hecho. Es una herramienta de marketing. Debe demostrar, con datos, que puedes resolver los problemas que Google quiere resolver. Tu preparación para la entrevista debe ir más allá de saber usar una herramienta. Tienes que entender el "porqué" detrás de la arquitectura.

Cómo adaptar tu CV para el rol de Google DevOps Engineer#

El primer filtro es casi siempre un sistema de seguimiento de candidatos (ATS). Tu CV debe hablar el mismo idioma que la descripción del puesto. Google busca personas que piensen en sistemas a gran escala, automatización y fiabilidad. Tu CV debe reflejar eso.

No listes tecnologías. Demuestra cómo las usaste para conseguir un resultado medible. Un buen punto de partida es analizar las ofertas de empleo actuales en [/es/jobs/](las ofertas de trabajo de DevOps) para ver qué piden. Luego, usa una herramienta como nuestro decodificador de ofertas de empleo para extraer las palabras clave más importantes.

Palabras clave que no pueden faltar en tu CV

Google tiene un vocabulario propio. Si no lo usas, parecerás un extraño. Céntrate en conceptos, no solo en nombres de productos.

• Fiabilidad (SRE es el corazón de DevOps en Google).
• Observabilidad (trasciende el simple "monitoring").
• Automatización de la infraestructura.
• Infraestructura como código (IaC).
• Orquestación de contenedores.
• Sistemas distribuidos a gran escala.
• CI/CD y despliegues continuos.
• Cultura de "sin culpas" (blameless postmortems).

Ejemplo práctico: reescribiendo un punto del CV

Muchos candidatos escriben algo así:

Responsable de la infraestructura en AWS y los pipelines de CI/CD con Jenkins.

Es genérico y aburrido. No dice nada de tu impacto. Ahora, piensa como un SRE de Google. ¿Qué problema resolviste? ¿Qué métrica mejoraste? ¿A qué escala?

Versión mejorada:

Lideré la migración de 15 servicios monolíticos a una arquitectura de microservicios en GKE, diseñando pipelines de CI/CD con Cloud Build. Esto redujo el tiempo de despliegue de 45 a 5 minutos y aumentó la fiabilidad del sistema (SLO) al 99.95%.

La diferencia es abismal. La segunda versión muestra escala, impacto medible y usa el lenguaje correcto (GKE, SLO). Antes de enviar tu CV, asegúrate de que pasa el filtro. Puedes usar nuestro comprobador de compatibilidad con ATS para verificarlo.

Prepararse para la entrevista técnica de Google#

La entrevista de un DevOps Engineer en Google no se parece a la de otras empresas. No esperes preguntas trampa sobre los flags de un comando de Linux. El enfoque está en la resolución de problemas a gran escala y en tu forma de pensar.

Las cuatro partes de la entrevista técnica

El proceso suele dividirse en estas áreas, aunque puede variar:

• Coding: No serás un desarrollador de software, pero debes saber programar. Te pedirán resolver problemas de algoritmos y estructuras de datos en un lenguaje como Python o Go. Practica en LeetCode, pero céntrate en los problemas de dificultad media. Quieren ver si puedes escribir código limpio y eficiente.
• Linux/Networking: Preguntas sobre el sistema operativo, redes y troubleshooting. Ejemplo: "Un servidor web devuelve un error 503. Describe tu proceso de diagnóstico paso a paso". No buscan la respuesta perfecta, sino tu método lógico.
• System Design: Esta es la más importante. Te darán un problema abstracto como "Diseña un sistema para subir y procesar millones de vídeos al día". Aquí demuestras tu capacidad para pensar en escalabilidad, fiabilidad, costes y complejidad operativa.
• Googleyness: Una entrevista de comportamiento. Buscan si encajas en la cultura: colaboración, comunicación, humildad y capacidad para trabajar con ambigüedad.

Ejemplo de respuesta a una pregunta de system design

Pregunta: "Nuestro equipo de producto quiere crear un nuevo servicio para notificaciones push. Debe soportar miles de millones de eventos al día. ¿Cómo lo diseñarías?"

Una mala respuesta sería empezar a nombrar tecnologías: "Usaría Kafka, luego Redis, y luego Kubernetes".

Una buena respuesta estructurada sigue un proceso.

Posible respuesta:

"Primero, definiría los requisitos y las restricciones. ¿Qué latencia es aceptable? ¿Qué nivel de fiabilidad necesitamos (SLO)? ¿Cuál es el presupuesto?

Asumiendo que necesitamos alta fiabilidad y baja latencia, mi diseño se basaría en una arquitectura de colas de mensajes para desacoplar la recepción del envío. El endpoint de la API recibiría la notificación y la pondría en una cola de alta disponibilidad, como Google Cloud Pub/Sub. Esto nos protege de picos de tráfico.

Luego, un pool de workers (en GKE o Cloud Run, por ejemplo) leería de la cola y se encargaría de enviar la notificación al proveedor final (APNs, FCM). Para la fiabilidad, los workers implementarían reintentos con backoff exponencial y moverían los mensajes fallidos a una cola de 'dead-letter' para su análisis.

Para la observabilidad, instrumentaría todo el flujo con Cloud Monitoring y Cloud Logging para crear paneles que muestren la latencia, la tasa de error y la profundidad de la cola. Así podemos detectar problemas rápidamente. El coste es un factor clave, por lo que usaría un servicio serverless como Cloud Run para los workers nos permitiría escalar a cero cuando no haya tráfico."

Esta respuesta demuestra que piensas en todo el ciclo de vida de un sistema, no solo en la parte técnica.

Preguntas frecuentes#

¿Existe una diferencia entre DevOps y SRE en Google?

Sí. Aunque se solapan, Google es cuna del SRE. Un SRE se centra en la fiabilidad del software en producción, tratando los problemas operativos como problemas de software. Un rol de DevOps puede ser más amplio, enfocado en la cultura y las herramientas de CI/CD para toda la organización. En las ofertas de Google, a menudo se buscan perfiles SRE.

¿Qué nivel de programación esperan en la entrevista?

No esperan que seas un ingeniero de software de primer nivel, pero sí que seas competente. Debes saber resolver problemas de complejidad media en LeetCode, entender estructuras de datos como hash maps, árboles y grafos, y escribir código limpio y legible. Python y Go son las opciones más comunes.

¿Cómo se maneja la entrevista de "Googleyness"?

Prepara 3 o 4 historias de tu carrera profesional que demuestren: un conflicto que resolviste colaborativamente, una vez que tuviste que tomar una decisión con información incompleta, un error que cometiste y lo que aprendiste, y cómo has ayudado a un compañero. Usa el método STAR (Situación, Tarea, Acción, Resultado) para estructurar tus respuestas.

¿Es necesario tener experiencia previa en Google Cloud?

No es estrictamente necesario, pero es una gran ventaja. Demuestra iniciativa y familiaridad con su ecosistema. Si solo tienes experiencia en AWS o Azure, asegúrate de entender los conceptos fundamentales de la nube (IaaS, PaaS, serverless) y sé capaz de explicar cómo trasladarías tus conocimientos a GCP. Puedes explorar más sobre el sector tecnológico en nuestro [/es/blog/](blog de consejos de carrera).

¿Cuánto tiempo debo dedicar a la preparación?

Para un rol de este nivel, la gente suele dedicar entre 2 y 6 meses de preparación seria. Esto incluye resolver problemas de código a diario, leer libros clave como "Site Reliability Engineering" y "Designing Data-Intensive Applications", y practicar system design con un amigo o colega al menos una vez por semana. No es un proceso que se pueda improvisar.