Test de DevOps engineer: preguntas de ejemplo y plantilla de evaluación
Por qué las preguntas genéricas de infraestructura fallan
La mayoría de las evaluaciones DevOps preguntan cosas de libro: "¿Qué es un contenedor?" o "Define CICD." Estas preguntas miden recall de trivia, no si alguien puede diseñar un sistema resiliente bajo presión o debuggear un incidente de producción a las 2 AM.
Un test DevOps real debería medir juicio, no hechos. Debería testear si alguien entiende trade-offs entre automatización y operabilidad, sabe cuándo escalar horizontal vs vertical, y puede razonar sobre modos de fallo.
Aquí hay cómo luce una evaluación DevOps con señal.
Categoría 1: diseño de infraestructura bajo restricciones
Pregunta basada en escenario:
"Tienes una aplicación corriendo en una sola instancia EC2. Maneja 1000 RPS, usa 70% CPU, y tiene 4GB de RAM con 60% utilización. Tu SLA es 99.9% uptime. La aplicación es stateless. ¿Qué cambios harías, y en qué orden? ¿Qué trade-offs estás haciendo?"
Esto testea:
- Comprensión de escalabilidad vs redundancia (ambas necesarias para 99.9%)
- Conciencia de coste (¿saltan a soluciones caras?)
- Conocimiento de secuenciación (failover antes de optimización)
- Articulación de trade-offs (EBS gp3 vs NVMe local, por ejemplo)
Una candidata que dice "añade un load balancer y levanta dos instancias más en otra AZ" piensa claramente. Una que dice "cambia a Kubernetes" puede estar pattern-matching sin entender la restricción (alta disponibilidad, no multi-tenancy).
Categoría 2: respuesta a incidentes y troubleshooting
Pregunta basada en escenario:
"Tu pipeline CI/CD falla en builds aleatorios. El error es 'connection timeout to Docker registry.' Pasa aproximadamente una vez cada 20 builds. ¿Qué chequeas primero, y qué instrumentación añadirías?"
Esto testea:
- Metodología sistemática de debugging
- Comprensión de aislamiento de red y autenticación
- Pensamiento de observabilidad (¿qué instrumentarían si tuvieran que prevenirlo la próxima?)
- Priorización (no necesitan análisis de causa raíz perfecto, necesitan el sistema de build estable ahora)
Una candidata que empieza con "verifica la página de status del registry Docker" es menos thoughtful que una que dice "primero: ¿es retry-able y añadimos rate limiting? segundo: verifica si el token del registry está expirando a media build o si nuestra config de red cambió."
Categoría 3: revisión de código y configuración
Ejercicio en vivo:
Provee un snippet Terraform de 30 líneas o una config Docker Compose con problemas intencionales. Pide a la candidata identificar problemas y explicar el fix.
Ejemplos de problemas Terraform:
- Security group permitiendo 0.0.0.0/0 a un puerto de BD
- Política de retención de backup faltante en RDS
- Password de BD hardcoded en variables
- Sin tags para asignación de costes
Ejemplos de problemas Compose:
- Contenedores privilegiados sin justificación
- Health checks faltantes
- Logging a stdout sin límites (riesgo de llenar disco)
- Sin restricciones de recurso (CPU/memoria)
Esto testea si han enviado sistemas a producción y aprendido qué se rompe. Las ingenieras de libro no atrapan estos; los operadores experimentados sí.
Categoría 4: arquitectura y selección de herramientas
Conversación:
"Necesitamos coordinar jobs entre 50 microservicios. Cada job tarda 2-30 minutos. Queremos garantías de orden fuertes. ¿Qué usarías? Recórreme los trade-offs."
Respuestas válidas:
- Temporal (orquestación de workflow, orden fuerte, complejo de operar)
- Step Functions (gestionado, limitado a AWS, menos flexible)
- Pub/Sub + app consumidora (acoplamiento bajo, orden débil, operacionalmente más simple)
- Kubernetes Jobs + custom controller (flexible, más overhead operacional)
La entrevistadora debería empujar atrás: "Step Functions suena más simple." La candidata debería defender: "Hasta que necesites reintentar un job que ya parcialmente succeed, o hasta que tengas un job de 2 minutos corriendo en SLA de 10 minutos, entonces necesitas la state machine de workflow. Pero ese es coste real — el trade-off de complejidad."
Esto testea juicio y experiencia, no conocimiento.
Categoría 5: observabilidad y monitoreo
Escenario corto:
"Has desplegado un cambio y tu tasa de error fue de 0.1% a 0.5%. La latencia p99 es la misma. El cambio tocó logging y tracing, no manejo de requests. ¿Dónde miras?"
Una respuesta débil: "Verifica los logs." Una respuesta fuerte: "Primero, verificaría si la instrumentación de tracing o el nivel de logging cambió — eso podría aumentar la visibilidad de errores sin aumentar errores reales. Luego miraría la cardinalidad de logs. Luego verificaría si estamos logeando casos de error nuevos que antes no se atrapaban."
Esto separa operadores de ingenieras que solo leyeron los docs de Kubernetes.
Cómo estructurar la evaluación
- Take-home de 30 minutos: Escenario de diseño de infra + revisión de configuración. Pídeles explicar sus decisiones.
- Entrevista síncrona de 30 minutos: Conversación de troubleshooting en vivo + discusión de arquitectura. Graba su razonamiento.
- Empareja la evaluación con señales de integridad de tecleo. Las candidatas DevOps copiando soluciones enteras de ChatGPT o StackOverflow mostrarán patrones de edición inusuales. ClarityHire captura esto por defecto.
El contrapunto honesto
No todo rol necesita esta profundidad. Roles DevOps o SRE junior se benefician de filtrado más simple: ¿pueden leer Terraform, desplegar una app, entender un diagrama de red? Para hiring senior+, esta rúbrica aplica. Para mid-level, baja la complejidad pero mantén la estructura basada en escenario.
Próximos pasos
¿Listo para evaluar tus candidatas DevOps con tests reales? Echa un vistazo a nuestro hub de evaluación DevOps y Cloud Engineering para plantillas y orientación sobre cómo evaluar habilidades de DevOps engineers.