DevOps Engineer

Método estructurado: detección (alerta o reporte), triaje, formulación de hipótesis, validación con logs, métricas, trazas o experimentación dirigida en caliente. Honestidad sobre la duración total, las falsas pistas y el coste real para el negocio. Bonus: la persona candidata cita la causa raíz (no solo el hotfix) y la medida sistémica preventiva aplicada después (alerta añadida con SLO, runbook actualizado, automatización de la mitigación, cambio de diseño). Las respuestas tipo reinicié los nodos y todo volvió a la normalidad sin diagnóstico revelan debilidad en investigación operativa.

Capacidad de estructurar una decisión bajo incertidumbre: clarificación de restricciones (escala actual y prevista, equipo, presupuesto, calendario), alternativas evaluadas, arbitrajes explícitos entre simplicidad operativa y flexibilidad futura, consulta a las partes implicadas (backend, seguridad, finanzas), validación posterior. Bonus: la persona candidata menciona una decisión sobre la que cambiaría hoy o un ADR escrito para el equipo. Quienes describen una decisión obvia con perspectiva nunca llegaron a arbitrar de verdad.

Diagnóstico primero, optimización después: análisis del gasto por servicio o por equipo (tagging, cost explorer), identificación del top 3 o 5 de cost drivers, hipótesis priorizadas (rightsizing, spot, reserved, eliminación de recursos huérfanos, optimización de transferencia de datos), validación del impacto antes de generalizar. Bonus: la persona candidata menciona una métrica concreta de ahorro (porcentaje o valor absoluto) y el efecto colateral en fiabilidad (mantenido o mejorado). Quienes responden migramos a spot y ya está sin matizar el riesgo muestran juicio operativo débil.

Capacidad de señalar un riesgo de seguridad sin bloquear: comentario factual en la PR (aquí está el principio de menor privilegio violado, esta es una propuesta concreta de scope reducido), corrección sugerida, escalado al·a la tech lead o al equipo de seguridad si la PR se mergea pese al comentario. Reflejo de auditoría posterior (¿qué otros roles tienen este patrón?). Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico, crítico en un puesto DevOps.

Equilibrio entre desbloqueo y disciplina operativa: clarificación de la necesidad real (¿lectura solo o también escritura?, ¿una vez o recurrente?), oferta de alternativa segura (acceso de solo lectura temporal con auditoría, réplica de lectura, dump anonimizado de los datos relevantes, sesión de pair debugging con la persona DBA). Negativa fundamentada al acceso administrativo directo salvo procedimiento de break-glass documentado. Bonus: la persona candidata identifica el problema subyacente (falta de observabilidad aplicativa o de herramientas de debugging) y propone una mejora estructural.

Diagnóstico primero, no la revolución total: priorización por riesgo operativo. Típicamente: (1) inventario y mapeo del existente (qué está donde, quién lo toca, cuándo se rompe), (2) reducción del ruido de alertas hasta poder confiar en ellas, (3) IaC sobre las zonas más volátiles primero, (4) automatización del pipeline de despliegue con rollback rápido, (5) plan más largo para Kubernetes y el resto. Validación explícita con el equipo y la persona tech lead antes de avanzar. Las respuestas tipo refactor total en 90 días son una bandera roja.

Comprensión clara: liveness reinicia el pod si el proceso queda colgado (loop infinito, deadlock); readiness retira el pod del servicio si no puede atender tráfico de forma temporal (dependencia caída, recarga de caché); startup protege los procesos lentos al arrancar para evitar reinicio prematuro por liveness. Errores típicos: usar el mismo endpoint para liveness y readiness (un fallo de dependencia provoca reinicio inútil), liveness demasiado agresiva (kill durante GC pause), readiness sin endpoint de health real (fallos invisibles). Quienes confunden los tres conceptos crean cascadas de reinicio en producción.

Pipeline estructurado: build reproducible con caché, tests unitarios y de integración acotados a las fronteras, escaneo de vulnerabilidades de la imagen (Trivy, Grype), firma y publicación en registry privado, despliegue automático en staging tras merge en main, promoción a producción con aprobación humana o canary automático. Detalles esperados: GitOps (Argo CD o Flux) frente a push, gestión de secrets (External Secrets Operator, Vault, SOPS), estrategia de rollback (revertir el commit en el repo de estado, no el imperative kubectl rollout undo). Bonus: la persona candidata menciona observabilidad del propio pipeline (DORA metrics, tasa de fallo de despliegue).

Comprensión de los tres pilares: métricas (Prometheus, VictoriaMetrics, Datadog) para alertas y dashboards, logs estructurados (Loki, Elastic, Datadog) para diagnóstico, trazas distribuidas (OpenTelemetry, Tempo, Honeycomb) para análisis de latencia y errores entre servicios. Definición de SLI y SLO por servicio crítico, alertas que dispararán a partir de error budget consumido y no de umbral fijo. Control de coste: sampling de trazas, retención escalonada de logs, cardinality budget de métricas. Bonus: la persona candidata distingue el ruido de las alertas de la falta de cobertura y propone un proceso de revisión periódica.

Apertura: capacidad de separar el código de infraestructura del ego personal. Bonus: la persona candidata cita una vez en que cambió de opinión gracias a una review y explica qué le hizo cambiar. Quienes describen sobre todo haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para un puesto donde el código de infraestructura afecta a todo el equipo.

Postura de partenariado, no de gatekeeping: clarificación de la necesidad real, explicación pedagógica del riesgo, propuesta de alternativas viables, eventual pair-debugging para que la persona aprenda. Bonus: la persona candidata reconoce que el rol DevOps en pyme incluye una dimensión de transmisión activa y que las plataformas autoservicio bien diseñadas reducen la necesidad de mediar. Quienes describen un patrón consistente de bloqueo sin alternativa revelan disfunción operativa.

Postura de mentoría activa: pair sobre tareas de infraestructura, reviews pedagógicas (no solo aprobar el merge), documentación de las decisiones importantes (ADR, runbooks), compartir en reuniones de equipo o en lunch and learn. En pyme con equipo de plataforma pequeño (1 a 4 personas DevOps), la capacidad de transmisión es esencial para la pervivencia de la plataforma. Quienes responden ayudo cuando me piden sin más precisión muestran una postura pasiva.

Conciencia del trade-off: la pyme ofrece ownership amplio (toda la plataforma) y autonomía, a cambio de menos escala técnica, menos especialización profunda y guardias compartidas con un equipo pequeño. Bonus: la persona candidata cita restricciones que le motivan (decidir y operar sobre el conjunto, ver el efecto directo, trabajar cerca del negocio). Quienes solo citan el salario o el remote revelan riesgo de desencaje rápido.

Plan de aprendizaje concreto: 1 o 2 ejes técnicos (profundización en seguridad de infraestructura, SRE a escala, gestión de coste cloud, plataforma autoservicio) coherentes con el contexto del puesto. Bonus: la persona candidata identifica qué oportunidad específica ofrece la oferta (acceso a una stack concreta, escala creciente, primer·a especialista de plataforma del equipo). Quienes responden quiero aprender de todo sin priorizar muestran inmadurez profesional o falta de preparación.

Lucidez sobre las realidades del on-call DevOps en pyme: rotación de al menos 4 personas para evitar burnout, runbooks claros, compensación visible (económica o en descansos), observabilidad madura antes de poner a alguien de guardia. Bonus: la persona candidata pregunta de forma activa por el estado real de la guardia en la empresa (frecuencia, ruido de alertas, compensación) y no se conforma con descripciones genéricas. Quienes responden estoy disponible cuando haga falta sin matizar revelan inexperiencia o riesgo de quemarse rápido.