Mock interview de SRE — práctica con IA

Las entrevistas de SRE son el loop donde la profundidad de DevOps se encuentra con el rigor de la ingeniería de software — y los candidatos que consiguen ofertas son los que pueden pasar de un triaje de caída de cinco minutos a una conversación de diseño de SLO de treinta minutos sin perder a la audiencia. La mayoría de los candidatos pierden ofertas no por trivias de Linux, sino en el momento en que les preguntan «cuál es tu error budget para este trimestre y cómo llegaste a él». Esta guía muestra cómo usar mock interviews con IA para ensayar específicamente el loop de SRE.

Rondas típicas de una entrevista de SRE

El loop de SRE es el más largo de infra — típicamente 5–6 rondas. Screening del recruiter; un screening telefónico de fundamentos (internals de Linux, networking, fundamentos de sistemas distribuidos); una entrevista de coding (Python o Go, normalmente parsear logs o construir una pequeña CLI, a veces ligera en estructuras de datos); una ronda de respuesta a incidentes o troubleshooting («producción está caída — conduce la llamada»); una ronda de system design («diseña un load balancer global con 99,99 % de disponibilidad»); y una ronda behavioral con el hiring manager. Los loops senior y staff añaden una ronda de SLO/estrategia de fiabilidad donde argumentas tradeoffs a nivel de organización.

La ronda de respuesta a incidentes y la de estrategia de fiabilidad son donde los mocks con IA rinden de forma masiva. Ambas son conversaciones abiertas bajo presión de tiempo, ambas premian el pensamiento estructurado, ambas castigan las respuestas genéricas. El mock con IA reproduce el formato de caída en desarrollo casi con exactitud: un prompt vago, follow-ups que escalan, puntuación según cómo acotas el espacio de búsqueda. La ronda de system design también encaja bien — el diseño de SRE tiene su propio sabor (disponibilidad, blast radius, grafos de dependencias) que el mock puede conducir específicamente.

Principales temas técnicos

SLOs y error budgets

El vocabulario del libro de SRE de Google es requisito mínimo. Esté listo: SLI vs SLO vs SLA, elegir SLIs que de verdad le importan al cliente (tasa de éxito de requests, latencia p99, frescura — no utilización de CPU), la matemática del error budget (un SLO mensual del 99,9 % le da 43 minutos de presupuesto), la error budget policy (qué hace cuando lo agota — congelar releases, despriorizar features, postmortem obligatorio). Una pregunta favorita: «el equipo tiene 99,95 % de disponibilidad pero los clientes se quejan — ¿qué falla?». Las respuestas fuertes interrogan la definición del SLI, la ventana de agregación y la experiencia por cliente.

Respuesta a incidentes

El mock simulará esto directamente. Esté listo para el ritmo de triaje estructurado: evaluar primero el blast radius (a quién afecta, a cuántos), luego estabilizar (rollback, traffic shed, escalado de capacidad), luego diagnosticar (logs, traces, cambios recientes) y solo entonces comprometerse con un arreglo a largo plazo. El rol de IC (incident commander) es una habilidad aparte — esté listo para hablar de cómo coordinas cuando tres personas teclean a la vez. Cultura de postmortem: blameless, action items con responsables, y la diferencia entre root cause y contributing factors.

Internals de Linux y del SO

Esté listo: el modelo de procesos, signals, file descriptors, el OOM killer y cómo predecir qué elige, cgroups y namespaces, /proc y /sys para introspección en vivo, syscalls y strace, eBPF para tracing en producción sin reiniciar servicios, y networking de Linux (iptables, conntrack, netfilter). Una pregunta favorita: «el load average es 200 pero la CPU está al 30 %. ¿Qué falla?». Las respuestas fuertes separan procesos runnable de los sleeping y señalan IO wait, lock contention o threads.

Networking

Los loops senior de SRE sondean a fondo. Esté listo: el handshake de TCP, slow start y congestion control, la diferencia entre latencia y throughput en una sola conversación, DNS (y por qué DNS es la mitad de las caídas del mundo), handshakes de TLS y OCSP stapling, fundamentos de BGP para infra global, routing anycast vs unicast, tipos de load balancer (L4 vs L7, hardware vs software, sticky vs round-robin). Un escenario favorito: «la latencia de EU a US-East se duplicó a las 3am, sin deploy. Explícame el proceso».

Sistemas distribuidos

A las rondas de diseño de SRE les encantan. Esté listo: CAP y PACELC, modelos de consistencia (strong, eventual, causal, read-your-writes), consenso (Raft, esbozo de Paxos), leader election, estrategias de sharding y rebalanceo, topologías de replicación (sync vs async, peligros de multi-leader), transacciones distribuidas (saga, two-phase commit y por qué nadie lo corre), tokens de idempotencia y semánticas de cola (at-most-once vs at-least-once vs exactly-once y qué significa realmente exactly-once en la práctica).

Stack de observabilidad

Prometheus, Grafana, Loki, Tempo o Jaeger, OpenTelemetry. Esté listo: cardinalidad de métricas y cuánto cuesta, alertar sobre síntomas vs causas, qué hace bueno a un runbook, sampling de logs a escala (y por qué tu factura de logs es el segundo mayor coste de infra), estrategias de sampling de traces (head-based vs tail-based), y cómo diseñar dashboards para un on-call que tiene 30 segundos antes de tener que tomar una decisión.

Preguntas de escenario habituales

• «Producción está caída. El último deploy fue hace 4 horas. Conduce la llamada del incidente.» (Ritmo de triaje, pregunta de rollback, comunicaciones, postura de IC.)
• «Define un SLO para una API de pagos. Defiende tu número ante un CFO que quiere 100 %.» (Coste de los nueves, concepto de error budget, disponibilidad percibida por el cliente.)
• «Diseña un load balancer global con 99,99 % de disponibilidad.» (Routing por DNS, anycast, health checks, failover regional, blast radius.)
• «La mitad de las requests a un microservicio van lentas pero solo a las 4am UTC. Investiga.» (Cron jobs, GC, rotación de logs, ventanas de backup, barridos de retención.)
• «Has agotado el error budget trimestral. El PM quiere lanzar una feature grande la semana que viene. ¿Qué dices?» (Budget policy, freeze, negociación, ruta de escalado.)

Áreas de enfoque behavioral — qué buscan los hiring managers

Los hiring managers de SRE filtran por tres rasgos concretos. Primero, calma bajo presión — ¿puedes mantener una voz serena cuando la situación se pone fea? El mock no simula cortisol, pero pone a prueba si tu pensamiento estructurado aguanta cuando el prompt se vuelve ambiguo. Segundo, cultura blameless — toda anécdota de postmortem debería centrarse en causas sistémicas (no teníamos la alerta, el runbook estaba desactualizado, la herramienta de deploy dejó pasar esto) y no en la persona que pulsó el botón. Tercero, juicio de negocio sobre fiabilidad — los SREs staff y principal discuten con PMs y ejecutivos sobre cuánto vale la fiabilidad. Las anécdotas fuertes muestran cómo hiciste ese argumento con números, no con vibras. Cuente con prompts sobre una caída memorable, una vez que agotaste un SLO, una vez que dijiste no a una feature por razones de fiabilidad.

Cómo usar la práctica de mock con IA para este rol

Ponga el tipo de entrevista en «Tech Screening» o «Scenario» según lo que esté entrenando. Para practicar SLO y estrategia de fiabilidad, pegue la situación actual de su equipo como contexto y haga que la IA interprete al CFO o al PM escéptico. Para respuesta a incidentes, cambie a modo «Scenario» y haga que la IA conduzca una caída en desarrollo durante 15–20 minutos. El mock puntúa cómo acotas el espacio de búsqueda, no si llegas al root cause «correcto».

Para system design, haga «System Design» con prompts específicos de SRE: diseña un rate limiter global, diseña un failover de base de datos multi-región, diseña un control plane que no se tumbe a sí mismo. La IA presionará sobre disponibilidad y blast radius como lo hace un entrevistador de SRE — no sobre la UX de cara al usuario.

Un drill que rinde rápido: corre cinco escenarios de incidente seguidos en dominios distintos (pagos, streaming de vídeo, API interna, inferencia de ML, almacenamiento de archivos). El reconocimiento de patrones para «¿es esto un deploy, una dependencia, un problema de datos o de capacidad?» es la habilidad de entrevista de SRE más transferible.

Preguntas frecuentes