Preguntas en entrevistas para Site Reliability Engineer — Más de 30 preguntas y respuestas de expertos

Glassdoor reporta un salario promedio de SRE de 169.680 dólares, con el percentil 75 superando los 213.000 dólares anuales [1]. El rol — nacido en Google en 2003 y ahora adoptado por todas las grandes empresas tecnológicas — se encuentra en la intersección de la ingeniería de software y las operaciones de sistemas, y el proceso de entrevista refleja esa dualidad [2]. Las entrevistas de SRE evalúan el diseño de sistemas con restricciones de confiabilidad, la programación para automatización, la gestión de incidentes bajo presión y la mentalidad específica de cuantificar la confiabilidad a través de SLOs y error budgets. Esta guía cubre las preguntas conductuales, técnicas y situacionales que enfrentarás, con respuestas calibradas a la profundidad que esperan las empresas de primer nivel.

Puntos clave

• Las entrevistas de SRE típicamente incluyen de cuatro a seis rondas: programación, diseño de sistemas, resolución de problemas, gestión de incidentes y preguntas conductuales — distribuidas en un día completo o múltiples sesiones [3].
• El diferenciador central de las entrevistas SRE es el diseño de sistemas orientado a la confiabilidad — debes diseñar sistemas que degraden con gracia, no solo sistemas que escalen [2].
• SLOs, SLIs, error budgets y reducción de toil son vocabulario específico de SRE que los entrevistadores esperan que uses con fluidez.
• Las preguntas de programación para roles SRE enfatizan la automatización, herramientas de infraestructura y scripting operacional en lugar de problemas algorítmicos puros [3].

Preguntas conductuales

1. Cuéntame sobre el incidente más impactante que gestionaste. ¿Cuál fue tu rol y qué reveló la retrospectiva?

Respuesta experta: "Fui el comandante de incidentes durante una falla en cascada que derribó nuestro servicio primario de autenticación, afectando a 2,3 millones de usuarios activos durante 47 minutos. Un cambio rutinario de configuración en nuestro rate limiter estableció accidentalmente el umbral en 10 solicitudes por segundo en lugar de 10.000. El servicio de autenticación alcanzó el límite, devolvió errores 429, y la tormenta de reintentos de los clientes amplificó la carga 50 veces. Declaré un P1, establecí el canal de incidentes, asigné roles (líder de comunicaciones, líderes técnicos para autenticación e infraestructura) y coordiné la respuesta. La solución fue revertir el cambio de configuración, pero también tuvimos que drenar el backlog de reintentos aumentando temporalmente la capacidad. La retrospectiva identificó tres causas raíz: sin validación en los valores de configuración del rate limiter, sin despliegue canary para cambios de configuración y sin circuit breaker en los reintentos del cliente. Implementamos las tres correcciones y añadimos un canary sintético que prueba el flujo de autenticación cada 30 segundos. El incidente consumió el 40 % de nuestro error budget trimestral, lo que desencadenó una congelación de desarrollo de nuevas funcionalidades hasta que se entregaron las mejoras de confiabilidad."

2. Describe una ocasión en la que eliminaste una fuente significativa de toil.

Respuesta experta: "Nuestros ingenieros de guardia dedicaban un promedio de 6 horas por semana escalando manualmente réplicas de lectura de la base de datos durante picos de tráfico — monitoreaban dashboards, se conectaban por SSH a las instancias y ejecutaban scripts de escalado. Esto era toil de manual: repetitivo, automatizable y que escalaba linealmente con el crecimiento del servicio. Construí un controlador de auto-scaling usando un operador personalizado de Kubernetes que monitoreaba métricas de CPU y latencia de consultas, calculaba la cantidad de réplicas necesarias usando un modelo predictivo basado en patrones de tráfico históricos, y escalaba réplicas hacia arriba/abajo automáticamente. Añadí medidas de seguridad: cantidades mínimas y máximas de réplicas, períodos de enfriamiento para prevenir oscilaciones, y alertas de PagerDuty cuando el auto-scaling alcanzaba el 80 % de la capacidad máxima (señalando crecimiento orgánico que requería inversión en infraestructura). Tras el despliegue, las intervenciones de escalado manual bajaron de 6 horas/semana a 0, y nuestra carga de guardia disminuyó un 30 %. El proyecto también mejoró nuestra latencia de consultas P99 en un 15 % porque el escalado automatizado respondía más rápido que los humanos."

3. Da un ejemplo de cómo argumentaste contra un requisito de confiabilidad que considerabas demasiado agresivo.

Respuesta experta: "Un equipo de producto solicitó 99,999 % de disponibilidad (cinco nueves) para un nuevo servicio de notificaciones. Calculé lo que significan realmente cinco nueves: 5,26 minutos de tiempo de inactividad al año, lo que requeriría un despliegue multi-región active-active, conmutación por error automatizada en menos de 30 segundos, y esencialmente tolerancia cero para cambios de configuración sin despliegues canary. El costo de ingeniería se estimó en 6 meses y 400.000 dólares en infraestructura adicional. Entonces pregunté al equipo de producto: '¿Qué les pasa a los usuarios cuando las notificaciones se retrasan 5 minutos?' La respuesta fue 'nada — las notificaciones no son críticas en tiempo.' Propuse 99,9 % de disponibilidad (8,76 horas de inactividad al año), que nuestra infraestructura existente podía lograr con mejoras menores. El equipo de producto aceptó después de ver la curva de compensación costo-confiabilidad. Esta es la disciplina SRE: la confiabilidad es una funcionalidad, y como todas las funcionalidades, tiene un costo que debe justificarse por el impacto en el usuario [2]."

4. Cuéntame sobre una ocasión en la que mejoraste el monitoreo o la observabilidad de un servicio crítico.

Respuesta experta: "Nuestro servicio de pagos tenía un monitoreo que solo rastreaba verificaciones básicas de salud — respuestas HTTP 200 y utilización de CPU. Después de una falla silenciosa donde el servicio devolvió 200 pero con datos en caché obsoletos durante 3 horas, rediseñé nuestro stack de observabilidad. Definí SLIs vinculados a la experiencia del usuario: tasa de finalización exitosa de pagos (objetivo 99,95 %), latencia de procesamiento de pagos en P99 (objetivo 2 segundos) y frescura de datos (obsolescencia de caché menor a 60 segundos). Los implementé como métricas de Prometheus, creé dashboards de Grafana con alertas de tasa de consumo de SLO (multi-ventana: 5 minutos para consumo rápido, 1 hora para consumo lento) y añadí trazado distribuido con Jaeger para rastrear flujos de pago a través de 7 microservicios. El enfoque de alertas multi-ventana redujo las falsas alarmas de guardia en un 60 % mientras detectaba el tipo de falla silenciosa que originalmente motivó el proyecto. Pasamos de '¿está el servicio activo?' a '¿está el servicio entregando valor a los usuarios?'"

5. Describe cómo has equilibrado la velocidad de desarrollo de funcionalidades con el trabajo de confiabilidad.

Respuesta experta: "Implementé una política de error budget donde el trabajo de confiabilidad y el desarrollo de funcionalidades estaban gobernados por la misma métrica. Cuando nuestro error budget mensual estaba por encima del 50 %, el equipo de desarrollo tenía velocidad completa en funcionalidades. Cuando caía por debajo del 50 %, dividíamos 50/50 entre funcionalidades y mejoras de confiabilidad. Por debajo del 25 %, todo el esfuerzo de ingeniería se trasladaba a confiabilidad hasta que el presupuesto se recuperara. Esta no era una regla rígida — era un acuerdo negociado entre SRE y el equipo de producto, documentado en nuestro charter del equipo. La idea clave es que los error budgets hacen la confiabilidad concreta: en lugar de discutir si la confiabilidad 'importa', podíamos señalar datos que mostraban que habíamos consumido el 80 % de nuestro error budget y necesitábamos invertir en estabilidad. Durante un año, este enfoque redujo nuestra tasa de incidentes P1 en un 45 % mientras el equipo de producto entregó un 12 % más de funcionalidades que el año anterior — porque dedicaron menos tiempo a respuesta a incidentes y correcciones urgentes."

6. ¿Cómo abordas las rotaciones de guardia y cómo has mejorado la experiencia de guardia para tu equipo?

Respuesta experta: "Considero la guardia como un problema de ingeniería, no un problema de personal. Cuando me uní al equipo, los ingenieros de guardia recibían un promedio de 14 alertas por semana, con el 40 % de las alertas siendo no accionables o duplicadas. Implementé tres cambios. Primero, ajuste de alertas: revisé cada alerta durante 30 días, eliminé alertas que no se habían disparado o eran consistentemente no accionables, y consolidé alertas duplicadas usando agrupación de alertas en PagerDuty. Segundo, automatización de runbooks: para las 5 alertas accionables más frecuentes, escribí scripts de remediación automatizada (activados por webhooks de PagerDuty) que manejaban las acciones de primera respuesta y solo alertaban a un humano si la remediación automática fallaba. Tercero, mejoras en la entrega de guardia: introduje un documento estructurado de entrega (incidentes abiertos, cambios recientes, riesgos conocidos) y una reunión sincrónica de entrega de 15 minutos entre el ingeniero de guardia saliente y el entrante. Las alertas bajaron de 14/semana a 4/semana, y la puntuación de satisfacción de la encuesta de guardia mejoró de 2,1/5 a 4,3/5."

Preguntas técnicas

1. Explica los SLOs, SLIs y error budgets. ¿Cómo se relacionan entre sí?

Respuesta experta: "Un SLI (Service Level Indicator) es una métrica cuantitativa que mide un aspecto específico de la calidad del servicio — por ejemplo, la proporción de solicitudes HTTP que se completan exitosamente en menos de 200 ms. Un SLO (Service Level Objective) es un valor objetivo para un SLI — por ejemplo, el 99,9 % de las solicitudes deben tener éxito en menos de 200 ms durante una ventana móvil de 30 días. El error budget es el inverso del SLO: si tu SLO es 99,9 %, tu error budget es 0,1 % — puedes tolerar 0,1 % de fallos durante la ventana de medición. Para un servicio que maneja 1 millón de solicitudes por día, un SLO de 99,9 % significa que puedes permitirte 1.000 fallos diarios. El error budget crea un lenguaje compartido entre SRE y los equipos de producto: mientras estés dentro del presupuesto, despliega funcionalidades agresivamente. Cuando el presupuesto se consume, invierte en confiabilidad. Esto reemplaza argumentos subjetivos sobre confiabilidad con decisiones objetivas basadas en datos [2]."

2. Diseña un sistema de monitoreo y alertas para una arquitectura de microservicios con 50 servicios.

Respuesta experta: "Construiría el sistema en tres capas. Recopilación de datos: instrumentar cada servicio con bibliotecas cliente de Prometheus exportando métricas RED (Rate, Errors, Duration) más métricas de negocio personalizadas. Usar una jerarquía de federación de Prometheus — instancias de Prometheus por clúster alimentando un Thanos o Mimir central para almacenamiento a largo plazo y consultas entre clústeres. Agregación de logs vía Loki o Elasticsearch para logging estructurado. Trazado distribuido vía Jaeger o Tempo con propagación de contexto a través de los 50 servicios. Alertas: definir SLOs para los recorridos críticos del usuario de cada servicio, no solo para endpoints individuales. Implementar alertas de tasa de consumo multi-ventana: una ventana de 5 minutos sobre un umbral de 1 hora detecta consumos rápidos; una ventana de 30 minutos sobre un umbral de 6 horas detecta consumos lentos. Enrutar alertas a través de PagerDuty con enrutamiento basado en equipos y políticas de escalamiento. Dashboards: crear dashboards de señales doradas por servicio (latencia, tráfico, errores, saturación), un dashboard SLO de nivel superior mostrando el consumo de presupuesto de los 50 servicios, y mapas de dependencia de servicios generados a partir de datos de trazado. Principios de diseño críticos: alertar sobre síntomas (impacto al usuario), no sobre causas (CPU alta), y asegurar que cada alerta tenga un runbook enlazado en los metadatos de la alerta."

3. Un servicio responde lentamente. Guíame a través de tu enfoque de resolución de problemas.

Respuesta experta: "Empiezo con el impacto al usuario: ¿cuál es la latencia P50/P99 versus lo normal, y qué porcentaje de usuarios está afectado? Luego sigo el método USE (Utilization, Saturation, Errors) y el método RED (Rate, Errors, Duration) sistemáticamente. Primero, verificar el servicio en sí: CPU, memoria, pausas de GC (para servicios JVM), saturación del pool de hilos, agotamiento del pool de conexiones. Segundo, verificar dependencias aguas abajo: latencia de consultas a la base de datos (¿consultas lentas? ¿contención de bloqueos? ¿índice faltante?), tasa de aciertos de caché (¿el caché arrancó en frío o desalojó claves calientes?), latencia de APIs externas (¿un servicio de terceros está degradado?). Tercero, verificar la red: ¿hay pérdida de paquetes, retrasos en la resolución DNS o sobrecarga de handshake TLS? Uso trazado distribuido para identificar qué tramo en la ruta de la solicitud está contribuyendo más latencia — esto localiza el cuello de botella en el sistema distribuido. Si es una degradación gradual, verifico fugas de recursos (memoria, conexiones, descriptores de archivo) o crecimiento de tráfico que supera la capacidad. Si es repentino, verifico despliegues recientes, cambios de configuración o cambios en patrones de tráfico aguas arriba."

4. ¿Cómo diseñarías un sistema para lograr 99,99 % de disponibilidad en múltiples regiones?

Respuesta experta: "99,99 % de disponibilidad permite 52,6 minutos de inactividad por año, lo que significa que cada componente debe ser redundante o fallar independientemente. Arquitectura: despliegue active-active en al menos 3 regiones (no active-passive, que desperdicia capacidad e introduce riesgo de conmutación por error). Balanceo de carga global (Cloudflare, AWS Global Accelerator) con redirección de tráfico basada en verificaciones de salud — si una región falla las verificaciones de salud, el tráfico se redirige automáticamente a regiones saludables en 30 segundos. Capa de datos: replicación síncrona dentro de regiones para consistencia, replicación asíncrona entre regiones con resolución de conflictos (CRDTs o last-writer-wins según el modelo de datos). Aceptar que las escrituras entre regiones tienen sobrecarga de latencia. Despliegue: despliegues canary por región — desplegar en una región, observar durante 30 minutos, luego desplegar en las regiones restantes. Esto previene que un despliegue defectuoso derribe todas las regiones simultáneamente. Modos de falla a considerar: falla de región única, conmutación por error del primario de base de datos, retrasos de propagación DNS, expiración de certificados y fallas de dependencias. Pruebas: ingeniería del caos regular — inyectar fallas mensualmente usando herramientas como Gremlin o Litmus para verificar que la conmutación por error funciona como fue diseñada, no solo como fue documentada."

5. ¿Cuál es la diferencia entre escalado horizontal y vertical, y cuándo prefieres cada uno?

Respuesta experta: "El escalado vertical aumenta los recursos de una sola instancia (más CPU, RAM, disco más rápido). El escalado horizontal añade más instancias detrás de un balanceador de carga. Prefiero el escalado horizontal para servicios sin estado (servidores web, servidores API, workers) porque proporciona crecimiento de capacidad lineal, tolerancia a fallas (perder una instancia es menor) y alineación con patrones de infraestructura en la nube. Uso el escalado vertical para componentes con estado donde el escalado horizontal introduce complejidad — un primario de base de datos que necesita más memoria para su working set, o una pipeline de procesamiento de hilo único que está limitada por CPU. La decisión práctica depende de tres factores: gestión de estado (los servicios con estado son más difíciles de escalar horizontalmente), eficiencia de costos (el escalado vertical alcanza rendimientos decrecientes y límites de hardware) y radio de explosión de falla (una instancia grande fallando es catastrófico; una de veinte instancias pequeñas fallando es manejable). En producción, típicamente combino ambos: escalar verticalmente la base de datos a la instancia más grande práctica, luego escalar horizontalmente con réplicas de lectura para cargas de trabajo intensivas en lectura."

6. Explica Infrastructure as Code (IaC) y cómo lo has usado para mejorar la confiabilidad.

Respuesta experta: "Infrastructure as Code trata la configuración de infraestructura como software: con control de versiones, revisada, probada y reproducible. Uso Terraform para el aprovisionamiento de recursos en la nube (VPCs, bases de datos, balanceadores de carga, políticas IAM) y Ansible o Puppet para la gestión de configuración dentro de las instancias. Beneficios de confiabilidad: reproducibilidad (puedo reconstruir cualquier entorno desde código en minutos, eliminando servidores snowflake), auditabilidad (git log muestra quién cambió qué, cuándo y por qué) y testabilidad (ejecuto terraform plan en CI para detectar cambios disruptivos antes de aplicar, y uso Terratest para pruebas de integración de módulos de infraestructura). Un ejemplo concreto: cuando nuestro entorno de staging divergió de producción y un cambio probado en staging causó una caída en producción, reconstruí ambos entornos desde los mismos módulos de Terraform con variables específicas por entorno. La divergencia se volvió imposible porque el código es la fuente única de verdad. También implementé políticas Sentinel en Terraform Cloud para hacer cumplir las barreras de seguridad — sin buckets S3 públicos, sin security groups con ingress 0.0.0.0/0."

7. ¿Cómo abordas la planificación de capacidad para un servicio que experimenta crecimiento rápido?

Respuesta experta: "Uso un framework de cuatro pasos. Primero, establecer un modelo de carga: identificar los principales impulsores de recursos (solicitudes por segundo, conexiones concurrentes, volumen de datos) y correlacionarlos con métricas de infraestructura (CPU, memoria, I/O de disco, ancho de banda de red). Esto me da un costo por 'unidad de trabajo' — por ejemplo, 'cada solicitud API consume 2 ms de CPU y 0,5 MB de memoria.' Segundo, modelar el crecimiento: usar datos históricos para proyectar el crecimiento del tráfico (lineal, exponencial, estacional). Para un servicio de rápido crecimiento, proyecto al menos 6 meses adelante y aplico un factor de seguridad de 2x. Tercero, identificar recursos cuello de botella: el recurso que alcanza la capacidad primero determina tu disparador de escalado — podría ser CPU en nodos de cómputo, IOPS en la base de datos o ancho de banda en la red. Cuarto, automatizar la respuesta: implementar auto-scaling para recursos elásticos (cómputo, cachés) y establecer aprovisionamiento consciente del tiempo de entrega para recursos no elásticos (actualizaciones de instancia de base de datos, capacidad reservada). Reviso los planes de capacidad mensualmente, comparando proyecciones con valores reales, y ajusto el modelo cuando el crecimiento real se desvía más del 20 % de la proyección."

Preguntas situacionales

1. El error budget de tu servicio se agotó y quedan dos semanas en el trimestre. El equipo de producto quiere desplegar una funcionalidad importante. ¿Qué haces?

Respuesta experta: "De acuerdo con nuestra política de error budget, agotar el presupuesto activa una congelación de confiabilidad — sin despliegues de funcionalidades hasta que el presupuesto se recupere o el trimestre se reinicie. Presentaría los datos al equipo de producto: 'Nuestro SLO es 99,9 %, y hemos consumido el 100 % de nuestro error budget con 14 días restantes. Desplegar una funcionalidad importante introduce riesgo de despliegue que podría empujarnos más hacia una violación de SLO.' Ofrecería alternativas: ¿podemos desplegar la funcionalidad detrás de un feature flag con un lanzamiento gradual (1 % -> 10 % -> 100 %) para minimizar el radio de explosión? ¿Podemos priorizar una mejora específica de confiabilidad que recuperaría el presupuesto más rápido? ¿Hay una forma de desplegar primero en un subconjunto de regiones? La política de error budget existe precisamente para esta situación — sin ella, negociaríamos caso por caso, lo que socava todo el framework de SLO. Pero también sería flexible: si la funcionalidad es crítica para los ingresos y la violación de SLO es menor, la dirección podría aceptar el riesgo con visibilidad completa de la compensación [2]."

2. El cambio de un ingeniero junior causó una caída en producción. ¿Cómo manejas la retrospectiva?

Respuesta experta: "El principio fundamental es la ausencia de culpa — la retrospectiva examina qué pasó y por qué el sistema lo permitió, nunca quién tiene la culpa [2]. Lideraría la retrospectiva estableciendo los hechos de la línea temporal: qué cambio se hizo, cuándo, cuál fue el impacto inmediato, cuándo fue detectado, cómo se resolvió. Luego me concentraría en las causas sistémicas: ¿por qué el proceso de gestión de cambios permitió un cambio inseguro? ¿Hubo revisión de código insuficiente, pruebas automatizadas faltantes, despliegue canary inadecuado o falta de capacidad de rollback? Las acciones correctivas deben mejorar el sistema, no castigar al ingeniero: agregar validación automatizada que hubiera detectado el error, mejorar la paridad del entorno de staging para que el problema hubiera surgido antes de producción, agregar monitoreo que detecte el modo de falla más rápido. Declararía explícitamente en el documento de retrospectiva: 'El ingeniero siguió el proceso documentado. El proceso fue insuficiente, y estas mejoras prevendrán la recurrencia.' Una cultura de culpa lleva a los ingenieros a ocultar errores; una cultura sin culpa los lleva a reportarlos y corregirlos."

3. Heredas un sistema legado sin monitoreo, sin documentación y sin pruebas. ¿Dónde empiezas?

Respuesta experta: "Priorizaría por radio de explosión. Semana 1: agregar monitoreo básico de salud — ¿está respondiendo el servicio? ¿Cuál es la tasa de error? ¿Cuál es la utilización de recursos? Desplegaría un exportador de Prometheus para métricas del sistema e instrumentaría los puntos de entrada para métricas a nivel de solicitud. Esto me da visibilidad antes de tocar algo. Semanas 2–4: documentar la arquitectura del sistema leyendo el código, rastreando flujos de solicitudes y mapeando dependencias. Crearía un grafo de dependencias mostrando con qué se comunica el sistema y qué se comunica con él. Mes 2: agregar pruebas de integración para la ruta crítica — el único recorrido de usuario que, si se rompe, generaría una alerta. Esto me da una red de seguridad para cambios futuros. Mes 3: implementar CI/CD para que los cambios pasen por pruebas automatizadas y despliegue por etapas en lugar del manual SSH-y-desplegar. A lo largo del proceso, haría seguimiento del toil: ¿qué operaciones manuales requiere este sistema? Eso informa la priorización del trabajo de automatización. El principio clave es: no reescribir, estabilizar. Un sistema legado que ha estado funcionando durante años ha sobrevivido innumerables casos límite — reemplazarlo introduce nuevos riesgos."

4. Tu monitoreo muestra una fuga lenta de memoria en producción. El servicio se estrella y reinicia cada 72 horas. ¿Cómo abordas esto?

Respuesta experta: "Primero, cuantificaría el impacto: ¿los reinicios están causando errores visibles para el usuario? Si el reinicio es graceful (drenando conexiones, el balanceador de carga marca la instancia como unhealthy antes del crash), el impacto inmediato al usuario podría ser mínimo. Si es ungraceful (OOM kill, conexiones caídas), es un P2 que necesita atención inmediata. Para la investigación: habilitaría profiling de heap (pprof para Go, JVisualVM para Java, memory_profiler para Python) en una instancia de producción con tráfico reducido. Tomaría snapshots del heap a intervalos regulares (cada hora) y compararía conteos y tamaños de objetos para identificar qué tipos de objetos están creciendo. Causas comunes: caché sin evicción, fugas de goroutines/hilos, agotamiento del pool de conexiones sin limpieza adecuada, o acumulación de listeners de eventos. Para la mitigación a corto plazo, configuraría un CronJob o liveness probe que reinicie gracefully el servicio cada 48 horas durante ventanas de bajo tráfico — ganando tiempo mientras se investiga la causa raíz. Para la solución a largo plazo, una vez identificado el tipo de objeto que fuga, corregiría la causa raíz, añadiría un SLI de uso de memoria a nuestro monitoreo, y crearía una alerta cuando la tasa de crecimiento de memoria exceda las normas históricas."

5. La dirección te pide reducir los costos de infraestructura en un 30 % manteniendo los niveles actuales de confiabilidad. ¿Cómo lo abordas?

Respuesta experta: "Identificaría oportunidades de reducción de costos en cuatro categorías. Dimensionamiento correcto: auditar los tipos de instancia contra la utilización real — en mi experiencia, del 40 al 60 % de las instancias en la nube están sobredimensionadas. Usar las recomendaciones del proveedor de nube (AWS Compute Optimizer, GCP Recommender) y validar con datos reales de utilización de CPU/memoria. Capacidad reservada: convertir cargas de trabajo de línea base predecibles de on-demand a instancias reservadas o savings plans (típicamente 30–50 % de ahorro). Instancias spot/preemptibles: identificar cargas de trabajo tolerantes a fallas (procesamiento por lotes, runners de CI/CD, workers sin estado) que pueden tolerar interrupciones y moverlas a precios spot (60–90 % de ahorro). Optimización de arquitectura: identificar y eliminar desperdicios — recursos no utilizados, datos sobreplicados, logging costoso que nadie lee, y entornos de desarrollo funcionando 24/7 que podrían apagarse por las noches y fines de semana. Presentaría cada iniciativa con ahorros proyectados, esfuerzo de implementación y riesgo de confiabilidad. La restricción es clara: la confiabilidad no es negociable. La reducción de costos proviene de la eficiencia, no de eliminar redundancia o degradar la calidad del servicio."

Preguntas para el entrevistador

1. ¿Cuáles son los SLOs de los servicios que este equipo gestiona, y cómo se manejan los error budgets? Revela si el equipo practica los principios SRE o solo usa el título.

2. ¿Cómo es la rotación de guardia — cuántos ingenieros, cuál es el volumen de alertas y cuál es la política de escalamiento? Impacta directamente tu calidad de vida e indica la salud operacional del equipo.

3. ¿Cómo equilibra el equipo el trabajo de proyecto (mejoras de confiabilidad) con el trabajo operacional (respuesta a incidentes, toil)? Muestra si el equipo tiene capacidad para trabajo de ingeniería o está atrapado en modo de apagar incendios.

4. ¿Cómo es la relación del equipo con los equipos de desarrollo — SRE está integrado o centralizado? Determina tu modelo de colaboración diaria e influencia.

5. ¿Cuál es el enfoque del equipo respecto a las retrospectivas — ¿son libres de culpa y qué porcentaje de acciones correctivas se completa? Revela la cultura de aprendizaje de incidentes del equipo — un equipo que escribe retrospectivas pero nunca completa las acciones correctivas tiene un problema de cultura.

6. ¿Qué infraestructura y herramientas gestiona el equipo — proveedores de nube, orquestación de contenedores, stack de observabilidad? Pregunta práctica sobre el entorno técnico.

7. ¿Cuáles son los mayores desafíos de confiabilidad que el equipo enfrenta actualmente? Da perspectiva sobre los problemas que estarías resolviendo y si son interesantes.

Formato de la entrevista y qué esperar

Las entrevistas de SRE en las grandes empresas tecnológicas típicamente abarcan de 4 a 6 horas a lo largo de todo el proceso [3]. La ronda de programación evalúa la competencia en Python/Go/Java con problemas enfocados en automatización, procesamiento de datos o herramientas de sistema — espera problemas como "escribe un parser de logs que identifique patrones de error" en lugar de LeetCode puro. La ronda de diseño de sistemas te pide diseñar sistemas distribuidos con restricciones explícitas de confiabilidad — "diseña un acortador de URLs que sirva el 99,99 % de las solicitudes en menos de 100 ms." La ronda de resolución de problemas presenta un escenario de producción (degradación del servicio, falla en cascada, alertas misteriosas) y evalúa tu metodología de diagnóstico. La ronda conductual evalúa experiencia de guardia, gestión de incidentes, colaboración entre equipos y reducción de toil. Algunas empresas añaden una ronda de fundamentos de Linux/redes que cubre temas como gestión de procesos, operaciones de sistema de archivos, TCP/IP y resolución DNS. El proceso completo desde la llamada del reclutador hasta la oferta típicamente toma de 3 a 6 semanas.

Cómo prepararse

• Estudia el libro de SRE de Google. Los capítulos sobre SLOs, error budgets, toil y gestión de incidentes son fundamentales y se referencian frecuentemente en entrevistas [2].
• Practica diseño de sistemas con restricciones de confiabilidad. Diseña sistemas con objetivos de disponibilidad explícitos, modos de falla y estrategias de degradación elegante.
• Prepara historias de incidentes. Ten 3–5 narrativas detalladas de incidentes con tu rol, línea temporal, causa raíz, resolución y mejoras sistémicas.
• Repasa los fundamentos de Linux. Gestión de procesos, operaciones del sistema de archivos, comandos de red (ss, tcpdump, dig, traceroute) y herramientas de rendimiento del sistema (top, vmstat, iostat, sar).
• Practica programación para automatización. Escribe scripts que analicen logs, interactúen con APIs, gestionen estado de infraestructura y manejen casos de falla con elegancia.
• Conoce tu stack de observabilidad. Prepárate para discutir Prometheus, Grafana, Jaeger/Tempo, ELK/Loki, PagerDuty, y cómo los has usado en producción.

Errores comunes en la entrevista

1. Diseñar para escalabilidad sin diseñar para fallas. Las entrevistas SRE evalúan específicamente cómo tu sistema maneja las fallas — describir un sistema que "asume que todo funciona" es una señal de alerta [2].
2. No cuantificar la confiabilidad. Decir "el sistema debería ser altamente disponible" en lugar de "el sistema debería cumplir un SLO de 99,95 % de disponibilidad medido por la tasa de solicitudes exitosas" muestra que no has interiorizado los principios SRE.
3. Tratar los incidentes como problemas puramente técnicos. No discutir comunicación, coordinación y procesos de retrospectiva durante las historias de incidentes sugiere que careces de experiencia en gestión de incidentes.
4. Ignorar el toil. Las entrevistas SRE preguntan frecuentemente sobre reducción de toil. No tener ejemplos de trabajo operacional manual que hayas automatizado es una brecha.
5. Sobreingeniería de soluciones. Proponer arquitectura de cinco nueves para un servicio no crítico demuestra juicio deficiente. SRE trata sobre confiabilidad apropiada, no confiabilidad máxima [2].
6. No entender el modelo de error budget. Si no puedes explicar cómo los error budgets crean alineación entre SRE y los equipos de producto, no has estudiado el framework SRE.
7. No demostrar capacidad de programación. Los SREs son ingenieros, no operadores. Tener dificultades con un problema de programación señala que podrías no ser capaz de construir la automatización y herramientas que definen el rol [3].

Puntos clave

• Las entrevistas SRE evalúan una mentalidad de ingeniería específica: cuantificar la confiabilidad, hacer compensaciones basadas en datos y tratar las operaciones como problemas de ingeniería de software.
• SLOs, SLIs, error budgets y toil son el vocabulario de SRE — úsalos con fluidez y demuestra experiencia práctica con cada uno.
• Prepara historias detalladas de incidentes que muestren tu metodología de diagnóstico, habilidades de comunicación y pensamiento en mejoras sistémicas.
• Las respuestas de diseño de sistemas deben incluir modos de falla explícitos, estrategias de degradación elegante y objetivos de disponibilidad.

¿Quieres asegurarte de que tu currículum te lleve a la etapa de entrevista? Prueba el verificador gratuito de puntuación ATS de ResumeGeni para optimizar tu currículum de Site Reliability Engineer antes de postularte.

FAQ

¿Cuál es la diferencia entre SRE y DevOps?

SRE es una implementación específica de los principios DevOps con prácticas prescriptivas: SLOs, error budgets, presupuestos de toil y un modelo de compromiso definido con los equipos de desarrollo. DevOps es un movimiento cultural más amplio que enfatiza la colaboración entre desarrollo y operaciones. SRE proporciona el framework concreto — SLOs, error budgets y la regla del 50 % de tiempo de ingeniería — que hace los principios DevOps accionables. Muchas empresas usan los términos indistintamente, pero en entrevistas en empresas que practican SRE formalmente (Google, LinkedIn, Dropbox), la distinción importa [2].

¿Qué lenguajes de programación debo conocer para entrevistas SRE?

Python y Go son los lenguajes más comúnmente usados en SRE. Python para scripting, automatización y herramientas operacionales. Go para herramientas de sistemas de alto rendimiento (muchas herramientas del ecosistema Kubernetes, Prometheus y herramientas de infraestructura interna están escritas en Go). Algunas empresas usan Java o Ruby. Debes ser competente en al menos un lenguaje compilado y un lenguaje de scripting [3].

¿Qué rango salarial debo esperar como Site Reliability Engineer?

Los salarios van desde 128.842 dólares (promedio de PayScale) hasta 169.680 dólares (promedio de Glassdoor), con el percentil 75 en 213.272 dólares [1]. Los SREs senior en empresas FAANG pueden ganar entre 300.000 y más de 500.000 dólares incluyendo compensación en acciones. La compensación varía según el nivel de la empresa, la ubicación y la especialización. SRE típicamente tiene una prima del 10–20 % sobre los roles generales de ingeniería de software en la misma empresa.

¿Qué tan importante es el libro de SRE de Google para la preparación de entrevistas?

Muy importante. El libro de SRE de Google ("Site Reliability Engineering: How Google Runs Production Systems") define los conceptos que la mayoría de las entrevistas SRE evalúan: SLOs, error budgets, toil, gestión de incidentes y el modelo de compromiso SRE [2]. Incluso si estás entrevistándote en una empresa que no sigue exactamente las prácticas de Google, el libro proporciona el vocabulario y los frameworks que usan los entrevistadores.

¿Necesito experiencia de guardia para obtener un rol SRE?

La experiencia de guardia es altamente preferida pero no siempre requerida para posiciones SRE de nivel de entrada. Si no tienes experiencia formal de guardia, demuestra habilidades equivalentes: sistemas de monitoreo que hayas construido, incidentes a los que hayas respondido (incluso en entornos de staging o desarrollo), y automatización que hayas creado para reducir operaciones manuales. Demuestra que comprendes la realidad operacional de ejecutar sistemas en producción.

¿Qué certificaciones son útiles para entrevistas SRE?

Google Cloud Professional Cloud DevOps Engineer, AWS DevOps Engineer Professional, y Certified Kubernetes Administrator (CKA) son las certificaciones más relevantes. Sin embargo, las entrevistas SRE en empresas de primer nivel valoran la experiencia práctica y la capacidad de resolución de problemas mucho más que las certificaciones. Las certificaciones pueden ayudarte a pasar el filtrado de currículum, pero no te llevarán a través de una entrevista técnica.

¿Cómo es una entrevista SRE diferente de una entrevista de ingeniería de software?

Las entrevistas SRE incluyen diseño de sistemas con restricciones explícitas de confiabilidad (SLOs, modos de falla, degradación elegante), rondas de resolución de problemas (diagnóstico de escenarios de producción) y preguntas conductuales sobre gestión de incidentes y experiencia de guardia. Las entrevistas de ingeniería de software se enfocan más en programación algorítmica, diseño de sistemas a nivel de aplicación y pensamiento de producto. Las preguntas de programación SRE tienden a ser más prácticas y enfocadas en automatización que problemas algorítmicos puros [3].

Fuentes: [1] Glassdoor, "Site Reliability Engineer: Average Salary & Pay Trends 2026," https://www.glassdoor.com/Salaries/site-reliability-engineer-salary-SRCH_KO0,25.htm [2] Google, "Site Reliability Engineering: How Google Runs Production Systems," https://sre.google/sre-book/table-of-contents/ [3] InterviewBit, "SRE (Site Reliability Engineer) Interview Questions (2025)," https://www.interviewbit.com/sre-interview-questions/ [4] Exponent, "Site Reliability Engineer Interview Questions Explained (Updated 2026)," https://www.tryexponent.com/questions?role=sre [5] Wiz, "Site Reliability Engineer Interview Questions Explained," https://www.wiz.io/academy/cloud-careers/site-reliability-engineer-interview-questions [6] NovelVista, "50 Site Reliability Engineer (SRE) Interview Questions 2026," https://www.novelvista.com/blogs/devops/top-sre-interview-question-answer [7] MindMajix, "Top 50 Site Reliability Engineer (SRE) Interview Questions 2025," https://mindmajix.com/sre-interview-questions [8] Coursera, "Site Reliability Engineer Salary Guide 2026," https://www.coursera.org/articles/site-reliability-engineer-salary