Un buen candidato SRE no vende herramientas: vende resultados operacionales medibles (MTTR, error budget, reducción de ruido) y decisiones reversibles bajo presión.
Prepárate para tu interview de Ingeniero de Confiabilidad del Sitio en Chile: preguntas técnicas reales (SLO, incidentes, Kubernetes) y cómo responder con impacto.
Llegó el correo: “Queremos entrevistarte”. Y de inmediato te imaginas el peor momento posible: un incidente en producción, el negocio presionando, y tú explicando por qué tu SLO no es “99,9% porque sí”. Si tu entrevista es para Ingeniero de Confiabilidad del Sitio en Chile, esa película mental no es paranoia: es literalmente el tipo de conversación que vas a tener.
Aquí no te van a evaluar por “ser ordenado” o “trabajar bajo presión” en abstracto. Te van a medir por cómo piensas cuando el sistema se cae, cómo negocias error budget con producto, y si puedes automatizar sin romper compliance. En Chile, además, suele haber mezcla de entrevista técnica seria + conversación muy humana (y directa) con liderazgo.
En Chile, el proceso típico para un Site Reliability Engineer (o SRE) suele moverse rápido si la empresa está sufriendo dolores reales de disponibilidad. Lo más común: una primera llamada corta con RR. HH. para validar expectativas (renta, modalidad, disponibilidad para on-call), seguida de una entrevista técnica con alguien del equipo (a veces un Ingeniero de Operaciones o Ingeniero de Infraestructura que hoy está “apagando incendios” y quiere ayuda).
Después viene la parte que decide todo: una conversación de diseño/arquitectura y operación. Ahí te piden que aterrices SLO/SLI, estrategia de observabilidad, y cómo manejarías incidentes. En empresas con Kubernetes, casi siempre aparece un ejercicio práctico: revisar un dashboard, leer logs, proponer hipótesis, o discutir un postmortem. En fintech, retail y telco chilenas es común que te pregunten por continuidad operacional, auditorías y controles (no siempre con nombres perfectos, pero sí con intención).
La modalidad remota/híbrida está instalada, pero ojo: el “on-call” se conversa temprano y con franqueza. Y culturalmente, en Chile se valora que seas claro sin ser soberbio: explicar trade-offs con calma, y reconocer límites (“no lo sé, pero lo investigaría así”) suma más que improvisar.
Estas preguntas suenan “blandas”, pero en un Ingeniero SRE son trampas técnicas disfrazadas. Te están midiendo criterio operacional, comunicación en crisis y capacidad de influir sin autoridad.
Q: Cuéntame de un incidente en producción que te tocó liderar o coordinar. ¿Qué hiciste en los primeros 15 minutos?
Why they ask it: Quieren ver si sabes estabilizar, comunicar y reducir MTTR sin entrar en pánico.
Answer framework: STAR + “primeros 15 minutos” (Situación/Tarea/Acción/Resultado, enfatizando triage, comunicación y mitigación).
Example answer: “En mi último equipo tuvimos un aumento súbito de errores 5xx tras un despliegue. En los primeros 15 minutos prioricé detener el sangrado: activé el canal de incidente, asigné roles (comms, mitigación, investigación) y ejecutamos rollback porque el error budget se estaba consumiendo rápido. Mientras tanto, comuniqué a soporte y producto un ETA conservador y el alcance. Recuperamos el servicio en 12 minutos y luego hicimos postmortem con acciones: canary + alertas por saturación de pool de conexiones.”
Common mistake: Contar la historia como “yo lo arreglé” sin hablar de comunicación, roles y decisiones de mitigación.
Entre incidentes y “día a día”, la siguiente pregunta suele aparecer porque en Chile muchas empresas están madurando: pasan de operar por intuición a operar por métricas.
Q: ¿Cómo defines SLOs cuando el negocio solo pide ‘máxima disponibilidad’?
Why they ask it: Evalúan si puedes traducir deseos del negocio a objetivos medibles (SLI/SLO) y negociar trade-offs.
Answer framework: Marco SLO (Servicio → usuario → SLI → objetivo → ventanas → error budget) + ejemplo concreto.
Example answer: “Parto por el journey del usuario: por ejemplo, ‘pagar’ o ‘iniciar sesión’. Defino SLIs que reflejen experiencia real (latencia p95, tasa de éxito, disponibilidad por endpoint crítico) y propongo un SLO con ventana móvil, por ejemplo 99,9% mensual para pagos. Luego explico el error budget como una herramienta de decisión: si lo gastamos, frenamos features riesgosas y priorizamos confiabilidad. Lo importante es que el SLO sea defendible con datos y alineado al impacto económico.”
Common mistake: Proponer un número sin SLI, sin ventana y sin conversación de error budget.
Ahora viene una pregunta muy chilena por contexto organizacional: equipos con silos (dev vs ops) y fricción histórica.
Q: Describe un conflicto con desarrollo por un despliegue riesgoso. ¿Cómo lo resolviste sin bloquear al equipo?
Why they ask it: Quieren saber si puedes influir y mejorar el sistema, no solo decir “no”.
Answer framework: Problema–Opciones–Decisión–Evidencia (plantea alternativas y usa datos).
Example answer: “Tuvimos presión por lanzar una funcionalidad sin pruebas de carga. En vez de bloquear, propuse dos caminos: canary al 5% con métricas de error/latencia y feature flag para rollback lógico. Mostré datos de incidentes previos y el costo de una caída en hora punta. Acordamos un plan: release gradual + límites de rate + alertas temporales. Se lanzó a tiempo y sin degradación.”
Common mistake: Presentarte como ‘policía’ de producción que solo pone trabas.
En roles SRE en Chile, especialmente en empresas medianas, te van a pedir “hacer de todo” (observabilidad, CI/CD, cloud, seguridad). Esta pregunta mide tu capacidad de priorizar.
Q: Si te dan 90 días para “mejorar la confiabilidad”, ¿qué priorizas primero y cómo lo demuestras?
Why they ask it: Buscan pensamiento estratégico con entregables medibles.
Answer framework: 30-60-90 con métricas (baseline → quick wins → cambios estructurales).
Example answer: “Los primeros 30 días levanto línea base: SLIs actuales, top incidentes, y mapa de servicios. En 60 días apunto a quick wins: alertas accionables, runbooks, y reducción de ruido (menos páginas inútiles). En 90 días cierro con dos apuestas grandes: SLOs acordados con producto y automatización de despliegues/rollback. Lo demuestro con métricas: MTTR, tasa de incidentes repetidos y consumo de error budget.”
Common mistake: Hablar de herramientas (“pondremos Prometheus”) sin métricas ni secuencia.
Y sí: te van a preguntar por on-call. En Chile se conversa directo porque impacta vida personal y continuidad.
Q: ¿Cómo organizas un esquema de on-call sostenible y qué haces para reducir la carga?
Why they ask it: Quieren señales de madurez: menos heroísmo, más ingeniería.
Answer framework: “Carga → causas → palancas” (medir páginas, eliminar ruido, automatizar, mejorar calidad).
Example answer: “Primero mido: páginas por semana, horas fuera de horario y causas principales. Luego ataco el ruido: umbrales correctos, deduplicación, y alertas basadas en SLO. En paralelo, runbooks y automatización de mitigaciones comunes (reinicios seguros, escalado, circuit breakers). Si el on-call sigue alto, es señal de deuda: lo llevo a planificación con datos.”
Common mistake: Normalizar el sufrimiento (“da lo mismo, yo aguanto”).
Aquí se decide el rol. En Chile muchas empresas están en AWS/Azure, con Kubernetes, microservicios y observabilidad a medias. Te van a pedir criterio: no solo “sé usar X”, sino “cuándo X es mala idea”. Para calibrar, mira requisitos reales en avisos de empleo de SRE en LinkedIn Jobs, Get on Board e Indeed Chile (patrones: Kubernetes, Terraform, CI/CD, Prometheus/Grafana, incident management).
Q: Explícame la diferencia entre SLI, SLO y SLA, y cómo los usas para tomar decisiones de despliegue.
Why they ask it: Miden si entiendes el “contrato” de confiabilidad y el rol del error budget.
Answer framework: Definición → ejemplo → decisión (con error budget).
Example answer: “SLI es la métrica de experiencia (p. ej., tasa de éxito de checkout). SLO es el objetivo interno (99,9% mensual) y SLA es el compromiso externo con consecuencias. Para despliegues, uso el error budget: si estamos cerca de agotarlo, reduzco riesgo con canary más lento, congelo cambios no críticos o priorizo fixes. Si hay holgura, puedo acelerar releases con controles.”
Common mistake: Confundir SLA con SLO o hablar solo en términos de ‘uptime’.
Q: ¿Qué métricas y señales usarías para detectar degradación en un servicio de pagos en tiempo real?
Why they ask it: Quieren ver si piensas en “golden signals” y en experiencia de usuario.
Answer framework: Golden Signals (latencia, tráfico, errores, saturación) + métricas de negocio.
Example answer: “Parto por latencia p95/p99 por endpoint crítico, tasa de éxito y errores por tipo (4xx/5xx, timeouts). Agrego saturación: CPU, memoria, conexiones DB, colas y rate limits. Y cruzo con señales de negocio: tasa de aprobación, abandonos y reintentos. Lo clave es alertar por impacto al usuario, no por métricas internas aisladas.”
Common mistake: Alertar por CPU alta sin correlación con errores/latencia.
Q: ¿Cómo diseñarías la observabilidad para microservicios en Kubernetes: logs, métricas y trazas?
Why they ask it: Evalúan si puedes construir un sistema observable, no solo instalar herramientas.
Answer framework: “Tres pilares + correlación” (IDs, contexto, sampling, cardinalidad).
Example answer: “En métricas uso Prometheus con etiquetas controladas para evitar cardinalidad explosiva y dashboards en Grafana. En logs, JSON estructurado con trace_id/request_id y niveles consistentes; centralizo con Loki o ELK según el stack. En trazas, OpenTelemetry para instrumentación y un backend tipo Jaeger/Tempo. Lo importante es correlacionar: desde una alerta por SLO puedo saltar a trazas y luego a logs del pod exacto.”
Common mistake: Montar herramientas sin estándares de logging ni estrategia de correlación.
Q: ¿Qué estrategia de despliegue prefieres (blue/green, canary, rolling) y cuándo NO la usarías?
Why they ask it: Buscan criterio de riesgo y entendimiento del sistema.
Answer framework: “Contexto → riesgo → control” (tipo de cambio, reversibilidad, estado, DB).
Example answer: “Canary me gusta cuando puedo medir impacto rápido con SLIs y revertir sin dolor. Blue/green sirve si el cambio es grande y el costo de duplicar infraestructura es aceptable. Rolling es simple, pero puede ser peligroso si hay incompatibilidades. Si hay migraciones de base de datos no reversibles, priorizo enfoque expand/contract, feature flags y compatibilidad hacia atrás.”
Common mistake: Elegir una estrategia como dogma, sin hablar de DB y reversibilidad.
Q: ¿Cómo gestionas la confiabilidad cuando dependes de terceros (pasarelas, SMS, APIs) con SLAs débiles?
Why they ask it: En Chile es común depender de proveedores regionales; quieren resiliencia real.
Answer framework: Resiliencia por capas (timeouts, retries con backoff, circuit breaker, degradación).
Example answer: “Defino timeouts agresivos y retries con backoff y jitter, cuidando idempotencia. Implemento circuit breakers para cortar cascadas y colas para desacoplar. Si el tercero cae, diseño degradación: por ejemplo, permitir ‘pago pendiente’ o reintento asíncrono. Y monitoreo el proveedor como parte del SLO del journey, no como un ‘problema externo’.”
Common mistake: Reintentos infinitos que amplifican la caída del proveedor.
Q: ¿Qué opinas de ‘toil’? Dame ejemplos y cómo lo reducirías en un equipo SRE.
Why they ask it: Quieren mentalidad SRE: automatizar lo repetitivo y proteger foco.
Answer framework: Definición Google SRE → inventario → automatización → guardrails.
Example answer: “Toil es trabajo manual, repetitivo, sin valor duradero: reinicios, tickets iguales, deploys manuales. Lo reduzco midiendo horas/semana, atacando el top 3 con automatización (scripts, self-service, pipelines) y mejorando calidad upstream (tests, validaciones). También pongo guardrails: runbooks, ownership claro y límites al soporte ad-hoc.”
Common mistake: Llamar ‘toil’ a cualquier tarea que no te gusta, sin criterios.
Q: En Terraform, ¿cómo evitas cambios peligrosos en producción y cómo manejas el estado (state) en equipo?
Why they ask it: Infra como código es central; buscan prácticas seguras.
Answer framework: “Control de cambios” (remote state, locking, PRs, plan/apply, entornos).
Example answer: “Uso remote state con locking (por ejemplo S3 + DynamoDB o equivalente en Azure) y separo workspaces/estados por entorno. Todo cambio va por PR con revisión y terraform plan en CI; el apply se hace con permisos controlados y, si aplica, ventanas de cambio. Para recursos críticos, agrego políticas (OPA/Conftest) y módulos versionados.”
Common mistake: Ejecutar apply local sin revisión ni locking, generando drift y conflictos.
Q: ¿Cómo asegurarías alta disponibilidad en una base de datos crítica sin disparar costos?
Why they ask it: Quieren trade-offs: RPO/RTO, replicación, backups, pruebas.
Answer framework: Requisitos → opciones → decisión (RPO/RTO + costo + complejidad).
Example answer: “Primero aclaro RPO/RTO por caso de uso. Luego comparo opciones: réplica en otra zona, failover administrado, o read replicas según patrón de lectura. Mantengo backups con retención y pruebas de restore (no solo ‘tenemos backup’). Y optimizo costo: dimensionamiento correcto, escalado por demanda y evitar sobre-replicar si el RTO lo permite.”
Common mistake: Prometer ‘cero downtime’ sin hablar de RPO/RTO ni pruebas de recuperación.
Q: ¿Qué harías si Prometheus/Grafana (o tu stack de monitoreo) se cae durante un incidente?
Why they ask it: Buscan planes de contingencia y pensamiento de “observabilidad resiliente”.
Answer framework: Mitigación primero → fuentes alternativas → hardening posterior.
Example answer: “Si el monitoreo cae, vuelvo a señales básicas: health checks, métricas del cloud provider, logs centralizados y pruebas sintéticas desde fuera. Priorizo restaurar visibilidad mínima (un dashboard de ‘servicio arriba/abajo’ y errores) aunque sea temporal. Después del incidente, hardening: alta disponibilidad del stack, retención, y alertas fuera de banda (por ejemplo, checks externos).”
Common mistake: Quedarte paralizado porque ‘sin dashboards no se puede’.
Q: En Chile, si trabajas con datos personales, ¿qué prácticas de seguridad y cumplimiento consideras mínimas en operación?
Why they ask it: Muchas empresas están bajo presión por privacidad y auditorías; quieren higiene básica.
Answer framework: “Datos → controles → evidencia” (clasificación, acceso, trazabilidad).
Example answer: “Parto por minimizar exposición: secretos en un vault, rotación y principio de menor privilegio. En logs, evito PII y aplico mascaramiento. Aseguro trazabilidad: auditoría de accesos, cambios de infraestructura y despliegues. Y mantengo evidencia operativa: postmortems, runbooks y controles que soporten auditorías internas, alineándome a marcos como ISO/IEC 27001 cuando aplica.”
Common mistake: Responder solo con ‘encriptamos todo’ sin hablar de accesos, secretos y logging.
En estas preguntas no quieren “la respuesta correcta”. Quieren tu secuencia mental. Si tu orden es bueno, aunque no aciertes a la primera, igual te ven senior.
Q: Son las 11:55 y a las 12:00 parte una campaña masiva. Ves que la latencia p95 sube y el error budget se está quemando. ¿Qué haces?
How to structure your answer:
Example: “Declaro incidente, congelo despliegues, activo rate limiting en endpoints no críticos y aumento capacidad del componente saturado. Si el cambio fue reciente, detengo canary o hago rollback. Informo a marketing/negocio con un ‘go con mitigaciones’ o ‘no-go’ basado en SLIs, no en opiniones.”
Q: Te llega una alerta: ‘DB connections exhausted’. Desarrollo dice que ‘es un bug del driver’. ¿Cómo lo abordas sin entrar en guerra?
How to structure your answer:
Example: “Miro si hubo deploy, reviso pool size y leaks por endpoint. Mitigo bajando concurrencia y aplicando timeouts. Luego acordamos fix: cerrar conexiones, instrumentar pool y agregar prueba de carga para evitar regresión.”
Q: Producto quiere subir el SLO a 99,99% ‘porque el competidor lo dice’, pero el sistema no está listo. ¿Qué respondes?
How to structure your answer:
Example: “Muestro SLIs actuales y cuánto error budget consumimos. Explico que 99,99% exige redundancia, pruebas, y cambios de proceso. Propongo subir por etapas: primero estabilizar checkout a 99,9 con canary y observabilidad, luego invertir en multi-AZ y DR para aspirar a 99,99.”
Q: Descubres que un runbook crítico está desactualizado y el equipo lo usa igual en on-call. ¿Qué haces esta semana?
How to structure your answer:
Example: “Hoy mismo lo etiqueto como desactualizado y escribo un ‘runbook mínimo’ con pasos seguros. En 48 horas lo valido con un game day y dejo checklist de verificación. Luego asigno owner y revisión mensual ligada a cambios de arquitectura.”
En un rol de Ingeniero de Confiabilidad del Sitio, tus preguntas muestran si entiendes el negocio operativo. Además, en Chile muchas empresas están en transición: dicen “somos SRE” pero operan como soporte reactivo. Tus preguntas destapan la verdad sin confrontar.
En Chile, la conversación de renta suele aparecer temprano (a veces en la primera llamada). Tu objetivo: no regalar un número sin contexto, pero tampoco sonar evasivo. Investiga rangos mirando referencias en Glassdoor Chile y publicaciones locales/latam como Get on Board (muchas ofertas muestran banda o seniority), y contrasta con Hays Chile cuando haya guías vigentes.
Tu palanca como SRE no es “años de experiencia” a secas: es experiencia real en incidentes, Kubernetes en producción, Terraform bien gobernado, y diseño de SLO/error budget. Una frase que funciona:
“Por el alcance del rol (on-call, Kubernetes, IaC y ownership de SLOs), estoy buscando una renta líquida mensual en el rango de X a Y, pero prefiero ajustarlo cuando entendamos bien guardias, beneficios y nivel de responsabilidad.”
Si en la entrevista te dicen que “SRE es el equipo que responde tickets y reinicia pods”, eso no es SRE: es soporte con otro nombre. Otra alerta: on-call sin compensación clara o con frases tipo “aquí todos apañan” (traducción: burnout). Ojo también si evitan hablar de postmortems, o si el líder se enfoca en “encontrar al responsable” del último incidente. Y una más muy común: te prometen “migración a Kubernetes” pero no hay presupuesto, ni roadmap, ni tiempo asignado; solo esperanza.
Una entrevista de Ingeniero de Confiabilidad del Sitio en Chile se gana con claridad: cómo defines SLOs, cómo corres incidentes, y cómo reduces toil con automatización. Practica tus historias con métricas, y llega con preguntas que revelen la madurez real del equipo.
Antes de la entrevista, deja tu CV listo para pasar filtros técnicos y ATS. Crea un currículum optimizado en cv-maker.pro — y luego entra a la entrevista a operar con calma.