La mayoría de los candidatos a entrevistas de DevOps llegan conociendo sus herramientas. Pueden recitar comandos de Kubernetes, describir la gestión del estado de Terraform y explicar la diferencia entre implementaciones azul-verde y canarias. Luego el entrevistador les pide que expliquen por qué Knight Capital perdió 440 millones de dólares en 45 minutos y la sala se queda en silencio. Esa brecha entre el conocimiento de las herramientas y el criterio de ingeniería es exactamente lo que separa una devolución de llamada de un rechazo.

Las entrevistas de DevOps prueban tres cosas simultáneamente: si comprende la filosofía detrás de la entrega de software moderno, si tiene la profundidad técnica para respaldarla y si puede comunicarse bajo presión. Aquí se explica cómo prepararse para cada capa.

Lo que realmente mide la entrevista

Antes de comenzar a memorizar los estados del pod de Kubernetes, comprenda lo que realmente busca el entrevistador. Los roles de DevOps han evolucionado significativamente: ya no se trata simplemente de automatizar implementaciones. Las entrevistas modernas evalúan su capacidad para unir el desarrollo de software y las operaciones de TI, lo que significa que la alineación filosófica es tan importante como la recuperación de la sintaxis.

El Marco de investigación y evaluación de DevOps (DORA) le brinda el vocabulario que esperan los entrevistadores. Las cuatro métricas que necesitas para tener frío:

• Frecuencia de implementación: Con qué frecuencia lanzas a producción. Los equipos de élite se despliegan varias veces al día.

• Plazo de entrega de cambios: Cuánto tiempo transcurre desde el compromiso del código hasta la producción. Cuanto más corto, mejor.

• Tasa de errores de cambio: el porcentaje de implementaciones que causan incidentes de producción.

• Tiempo de recuperación de implementación fallida: Qué tan rápido se recupera cuando algo se estropea (anteriormente llamado Tiempo medio de restauración).

Estas no son trivialidades: son la lente a través de la cual los ingenieros superiores evalúan las decisiones arquitectónicas. Cuando un entrevistador pregunta “¿cómo mejoraría la confiabilidad de la implementación?” esperan una respuesta basada en estas métricas, no simplemente “Agregaría más pruebas”.

Combine DORA con el modelo CALMS (Cultura, Automatización, Lean, Medición, Compartir) para preguntas de comportamiento. Cuando le preguntan sobre un conflicto pasado con un desarrollador o cómo impulsó la adopción de una nueva herramienta, CALMS le brinda un marco para estructurar la respuesta.

Información clave: la mayoría de los candidatos se preparan demasiado en la sintaxis de las herramientas y no se preparan lo suficiente en la filosofía de la ingeniería. Las métricas DORA y el modelo CALMS le indican qué califican realmente los entrevistadores.

Las bases técnicas que le permitirán superar la primera pantalla

Las entrevistas técnicas siguen patrones predecibles. Los temas cambian según el nivel de antigüedad, pero dos tecnologías aparecen en casi todas las entrevistas de DevOps, independientemente del tamaño de la empresa: Kubernetes y Terraform. Si no domina ambos, no está preparado.

Kubernetes: conozca el ciclo de vida, no solo los comandos

Los entrevistadores le pedirán que recorra el Ciclo de vida del pod de Kubernetes. Los cinco estados que debes explicar claramente:

• Pendiente: Pod aceptado por el clúster; contenedores aún no creados (programación o descarga de imágenes en curso).

• Correr: Pod vinculado a un nodo; al menos un contenedor está activo.

• Tuvo éxito: Todos los contenedores terminaron exitosamente; no se reiniciará.

• Fallido: Todos los contenedores terminados; al menos uno salió con un código distinto de cero.

• Desconocido: No se puede recuperar el estado del pod, generalmente debido a una falla de comunicación del nodo.

El seguimiento casi siempre se trata de CrashLoopBackOff. Este no es un estado del ciclo de vida; es una condición en la que un contenedor sigue fallando y Kubernetes lo sigue reiniciando. Tu respuesta: comprobar kubectl logs <pod> para el error de aplicación, entonces kubectl describe pod <pod> para eventos como muertes de OOM o fallas en la extracción de imágenes.

Conozca el Componentes del plano de control de Kubernetes lo suficientemente bien como para explicar lo que hace cada uno:

• kube-apiserver: el punto de entrada único para todas las llamadas a la API del clúster. Único componente que escribe en etcd.

• etcd: Almacén distribuido de valores clave. Fuente única de verdad para el estado del clúster.

• kube-scheduler: Asigna nuevos pods a nodos según la disponibilidad y las restricciones de los recursos.

• kube-controller-manager: Ejecuta los bucles de reconciliación que mantienen el estado real coincidiendo con el estado deseado.

• kubelet: Agente en cada nodo trabajador que garantiza que los contenedores se ejecuten según la especificación del pod.

Terraform: la gestión estatal es donde se ganan o se pierden las entrevistas

La mayoría de los candidatos saben cómo escribir un bloque de recursos. Menos pueden explicar Gestión del estado de Terraform en condiciones adversas, que es donde residen las verdaderas cuestiones.

• Estado remoto: Almacenar siempre terraform.tfstate de forma remota (S3, Azure Blob, GCS). Permite la colaboración, admite el control de versiones y mantiene las credenciales fuera de los entornos locales.

• Bloqueo de estado: Previene la concurrencia terraform apply huye del estado corruptor. En los backends de AWS S3, DynamoDB maneja el bloqueo. Se escribe una ID de bloqueo en la tabla; las ejecuciones simultáneas se bloquean hasta que se lanza.

• Detección de deriva: terraform plan compara la infraestructura real con el archivo estatal. Si alguien hizo un cambio manual en la consola, el plan muestra la diferencia.

• Reemplazo de recursos: El viejo terraform taint el comando es obsoleto. Usar terraform apply -replace="resource_address" en cambio.

• Importar recursos no administrados: terraform import lleva la infraestructura existente al estado Terraform, pero no genera el código de configuración. Escribe el HCL manualmente y luego lo importa.

Consejo profesional: cuando se le pregunte sobre la deriva de Terraform, no diga simplemente “ejecutar el plan de Terraform”. Explique qué causa la deriva (cambios manuales en la consola, otras herramientas de automatización que tocan los mismos recursos), por qué es importante (el estado y la realidad divergen) y cómo lo evitaría (aplicar cambios solo de IaC a través de una política).

Diseño de sistemas: las preguntas que separan a los mayores de los jóvenes

Las preguntas sobre el diseño del sistema revelan su opinión sobre el fracaso, la escala y las compensaciones. Dos escenarios surgen repetidamente.

Migrar un monolito a microservicios

El entrevistador quiere escuchar el “Patrón del higo estrangulador”, un método descrito por Martín Fowler para extraer de forma incremental la funcionalidad de un sistema heredado. Los puntos clave:

• No se reescribe el monolito de una vez. La extracción incremental es el único camino seguro.

• Una puerta de enlace API o un proxy interceptan las solicitudes. Rutas de funcionalidad migradas a nuevos microservicios; todo lo demás sigue golpeando el monolito.

• El monolito eventualmente no maneja nada y puede retirarse.

La respuesta trampa es “Lo reescribiría”. Se trata de un evento generador de currículum disfrazado de solución.

Observabilidad versus monitoreo

Las entrevistas modernas distinguen entre monitoreo (“¿está funcionando el sistema?”) y observabilidad (“¿por qué está roto?”). El tres pilares de la observabilidad son:

• Métrica: Mediciones numéricas a lo largo del tiempo: uso de CPU, latencia de solicitudes, tasa de error. ellos te dicen algo anda mal.

• Registros: Registros con marca de tiempo de eventos discretos. ellos te dicen qué sucedió.

• Rastros: recorridos de solicitudes distribuidas entre microservicios. ellos te dicen donde esta el cuello de botella.

Guíe al entrevistador sobre cómo interactúan: una métrica (pico de latencia) activa una alerta, los seguimientos muestran qué servicio es lento, los registros en ese servicio revelan la causa raíz. Esa es la respuesta que están buscando.

Preguntas de comportamiento: estructura primero, historia después

Las entrevistas conductuales hacen tropezar a los candidatos técnicos porque la habilidad que se prueba (comunicación estructurada) es diferente de la habilidad sobre la que se pregunta. El método ESTRELLA (Situación, Tarea, Acción, Resultado) le brinda una base que funciona para cualquier escenario.

Lo que realmente requiere cada componente:

• Situación: Breve contexto. Una o dos frases como máximo. No narres toda la historia de fondo.

• Tarea: Tu responsabilidad específica, no la de tu equipo. “Necesitábamos arreglarlo” no es una tarea. “Yo era el ingeniero de guardia responsable de restablecer el servicio”.

• Acción: Los pasos específicos tú tomó. Aquí es donde los entrevistadores realmente escuchan. Las respuestas vagas pierden puntos aquí.

• Resultado: Resultado cuantificado. “La latencia cayó un 50 %” en lugar de “las cosas mejoraron”.

Los tres escenarios para los que debes tener respuestas preparadas:

• Fallo de producción que usted causó: Céntrese en la solución y en la autopsia, no en la culpa. Los entrevistadores quieren ver que aprendiste algo y cambiaste algo.

• Conflicto con un desarrollador: Resolución basada en datos. “Les mostré la métrica de frecuencia de implementación y acordamos que la cadencia de lanzamiento era la causa principal” es una buena respuesta. “Teníamos opiniones diferentes” no lo es.

• Aprender una nueva herramienta bajo presión: ¿Cuál fue la estrategia de aprendizaje? ¿Qué funcionó? ¿Qué harías diferente?

¿Te suena familiar? Estos escenarios son prácticamente idénticos en todas las empresas. Prepare tres historias STAR sólidas y cubrirá el 80% de la ronda de comportamiento.

El estudio de caso que necesita en su bolsillo trasero

Un estudio de caso impresiona constantemente a los entrevistadores experimentados cuando se utiliza correctamente: Knight Capital Group. En 2012, Knight Capital perdió 440 millones de dólares en 45 minutos debido a un error de implementación. Las causas fundamentales:

• Se reutilizó un indicador de implementación en un código nuevo, pero activó un código antiguo inactivo en cualquier servidor que ejecutara la versión anterior.

• La actualización se implementó manualmente en siete de los ocho servidores. El octavo ejecutó el código antiguo con la nueva configuración de bandera y ejecutó operaciones erráticas durante 45 minutos.

Las lecciones de DevOps son exactamente lo que los entrevistadores quieren oírle articular:

• Las implementaciones deben ser automatizadas y atómicas. Los procesos manuales en los procesos de implementación son un factor de riesgo, no un control.

• Los indicadores de configuración no se deben reutilizar. El código muerto debe eliminarse.

• La idempotencia importa: la misma implementación ejecutada en cualquier servidor debería producir el mismo resultado.

Mencione esto cuando le pregunten sobre la confiabilidad de la implementación, no porque esté alardeando, sino porque demuestra que comprende que las fallas de DevOps tienen consecuencias comerciales reales.

Ingeniería de plataformas: el territorio que necesita conocer

Las entrevistas para puestos de alto nivel abordan cada vez más Ingeniería de Plataforma—Construir la infraestructura interna que utilizan otros desarrolladores. Si está solicitando algo por encima del nivel medio, prepárese para recibir preguntas sobre las plataformas de desarrollo interno (IDP).

Los conceptos centrales:

• Plataforma de desarrollo interno (IDP): una capa de autoservicio que permite a los desarrolladores aprovisionar infraestructura sin presentar tickets. Los ingenieros pueden poner en marcha entornos, gestionar implementaciones y acceder a servicios compartidos a través de interfaces estandarizadas.

• Caminos Dorados: Plantillas y flujos de trabajo preaprobados que guían a los desarrolladores hacia valores predeterminados seguros y compatibles sin restringirlos.

• Reducción de la carga cognitiva: El objetivo es permitir que los desarrolladores de aplicaciones se centren en el código de la aplicación. Cada ticket que tienen que presentar o paso manual que tienen que realizar es un impuesto a su atención.

La investigación de DORA muestra que las organizaciones que utilizan IDP generalmente entregan software más rápido y funcionan mejor operativamente, aunque la implementación a menudo conlleva una caída temporal del rendimiento a medida que los equipos se adaptan. Saber que existe la curva J y poder explicarla es el tipo de detalle que indica madurez operativa.

Verificación de la realidad: si solo sabes cómo usar herramientas, eres un candidato junior con años de senior. Las preguntas que hacen avanzar su candidatura son aquellas en las que explica las compensaciones, cuantifica los resultados y hace referencia a cómo han fallado los sistemas reales.

Qué hacer realmente en las próximas dos semanas

La brecha entre “Conozco DevOps” y “Puedo aprobar una entrevista de DevOps” se cierra más rápido con una preparación específica que con una revisión amplia. Aquí es donde centrarse:

• Métricas de DORA y CALMS: Comprenda ambos marcos lo suficientemente bien como para discutirlos en el contexto de su propia experiencia, no sólo como definiciones.

• Plano de control y ciclo de vida del pod de Kubernetes: Practique explicando cada componente en voz alta. Si no puedes explicarlo de forma sencilla, es que aún no lo sabes lo suficientemente bien.

• Gestión del estado de Terraform: Conozca el bloqueo, la deriva, la importación y la obsolescencia de terraform taint. Estos surgen en todos los niveles de antigüedad.

• Tres historias ESTRELLA: Fallos en la producción, conflictos con los desarrolladores y rápida adquisición de habilidades. Tener resultados cuantificados para cada uno.

• Estudio de caso de Knight Capital: Conozca de memoria la causa raíz y las lecciones de DevOps.

• Patrón de higo estrangulador y pilares de observabilidad: Las respuestas de referencia para preguntas sobre diseño de sistemas sobre migración de monolitos y depuración de sistemas distribuidos.

• Conceptos básicos de ingeniería de plataformas: desplazados internos, caminos dorados, carga cognitiva. Requerido para roles senior, diferenciándose para nivel medio.

Las entrevistas en sí mismas son un sistema: entradas repetibles, resultados predecibles. Estudie el sistema, no sólo las herramientas.