A entrevista de Site Reliability Engineer é o híbrido mais estranho da contratação em tecnologia: metade engenheiro de software, metade bombeiro de produção, com um estatístico escondido no fundo. Você vai escrever código, depurar um sistema que nunca viu sob pressão de incidente simulado e depois discutir de quantos noves um serviço realmente precisa. Este guia cobre as perguntas que de fato aparecem em 2026 e como responder como alguém que já carregou um pager.
O que as entrevistas de SRE realmente testam em 2026
A contratação em confiabilidade mudou. Cinco anos atrás dava para passar com trivia de Linux e uma pergunta de Big-O. Hoje a régua é se você consegue raciocinar sobre falhas em sistemas distribuídos e quantificar confiabilidade em vez de falar por cima.
Os entrevistadores em 2026 investigam quatro coisas. Você pensa em SLIs, SLOs e error budgets, ou ainda persegue "100 por cento de uptime" como se fosse uma virtude? Você consegue depurar um sistema ao vivo de forma metódica sem contexto prévio, do jeito que faria às 3 da manhã? Você entende os sistemas por baixo das abstrações (load balancers, filas, caches, consenso, retries, backpressure)? E você consegue operar a stack moderna: Kubernetes, Terraform, pipelines de observabilidade e o ferramental de alerta e auto-remediação assistido por IA que virou padrão nos últimos dois anos?
A camada cultural também pesa mais do que os candidatos esperam. Comportamento pós-incidente, ausência de culpabilização e como você equilibra velocidade e confiabilidade são avaliados tão a sério quanto o seu código, então um engenheiro que aponta culpados ou que congelaria todos os deploys depois de uma noite ruim reprova na régua de valores por mais limpo que seja o bash.
O processo de entrevista
A maioria dos processos de SRE em 2026 tem de quatro a seis etapas e difere de forma relevante de um processo puro de engenharia de software.
- Triagem com recrutador. Logística, motivação e "por que SRE e não backend ou plataforma?". Tenha uma resposta de verdade.
- Triagem técnica por telefone. Código com sabor de sistemas mais algumas perguntas de Linux, redes ou troubleshooting. Alguns trocam por um exercício de script: parsear um log, calcular uma taxa, achar a anomalia.
- Rodada de código. SREs ainda codam. Espere um problema de algoritmo moderado e, cada vez mais, uma tarefa de "escreva uma ferramentinha": um rate limiter, um wrapper de backoff ou parsing de log.
- Rodada de sistemas e troubleshooting. A entrevista assinatura do SRE. Você é jogado num sistema quebrado ou hipotético e tem que diagnosticá-lo em voz alta, muitas vezes num cenário ao vivo de "a latência acabou de disparar, me explique o que você faz".
- Design de sistemas com foco em confiabilidade. Projete para metas explícitas de disponibilidade, latência e escala. O ângulo de confiabilidade (domínios de falha, raio de impacto, folga de capacidade) é o que separa isso de uma rodada de design genérica.
- Rodada comportamental e de plantão. Histórias de incidente, conflito e como você lida com ser acionado, sempre sob uma lente sem culpabilização.
Google, Meta e as casas maiores dão bastante peso à rodada de sistemas. Startups juntam etapas e se apoiam em troubleshooting prático e no seu histórico real de plantão.
As perguntas
Fundamentos de confiabilidade: SLOs, error budgets e a matemática
Qual é a diferença entre um SLI, um SLO e um SLA? Como abordar: o SLI é a medição (requisições atendidas em menos de 300ms), o SLO é a sua meta interna para ela e o SLA é o contrato externo com consequências. Mantenha o SLO mais rígido que o SLA para ter aviso antecipado.
Um serviço tem um SLO de disponibilidade mensal de 99,9 por cento. Quanta indisponibilidade isso permite e o que você faz quando o budget está quase no fim? Como abordar: faça a conta em voz alta (99,9 por cento de cerca de 30 dias dá uns 43 minutos por mês) e depois observe que um budget gasto significa congelar lançamentos arriscados e repriorizar confiabilidade.
Como você escolheria um SLO para um serviço novo em folha, sem dados históricos? Como abordar: comece pela jornada crítica do usuário, defina uma meta conservadora, meça o comportamento real por algumas semanas e depois aperte. Um SLO que ninguém consegue bater só ensina todo mundo a ignorar alertas.
Por que mirar em 100 por cento de disponibilidade costuma ser a meta errada? Como abordar: raramente justifica o custo e não deixa espaço para entregar, e os usuários não conseguem distinguir isso de 99,99 por cento porque a rede deles falha com mais frequência. É essa diferença que faz os error budgets existirem.
Resposta a incidentes e plantão
Me explique como você conduziria um incidente grave sendo o engenheiro de plantão. Como abordar: avalie a severidade, nomeie um comandante do incidente e papéis se ele for grande, comunique aos stakeholders, priorize mitigação sobre causa raiz (primeiro estanque o sangramento) e depois conduza um postmortem.
Você é acionado por latência alta num serviço em que nunca mexeu. Quais são os seus primeiros cinco minutos? Como abordar: confira dashboards e alertas recentes, procure um deploy ou mudança de config recente (o gatilho de sempre), verifique as dependências acima e abaixo e formule uma hipótese a partir dos sinais enquanto narra a árvore de decisão. Aqui o método vale mais que a resposta.
O que faz um bom postmortem e o que "sem culpabilização" significa de verdade? Como abordar: um bom postmortem tem linha do tempo, fatores contribuintes, o que deu certo e itens de ação com donos, e sem culpabilização significa tratar erro humano como sintoma de lacunas do sistema.
Como você reduz a fadiga de alertas numa escala de plantão barulhenta? Como abordar: alerte sobre sintomas que o usuário sente em vez de sobre cada métrica, amarre os acionamentos à taxa de queima do SLO e apague alertas que nunca levam a ação.
Depuração e internals de sistemas
Uma máquina Linux está respondendo devagar. Como você descobre por quê? Como abordar: vá de cima para baixo pelos recursos, CPU (top, mpstat), memória e swap (free, vmstat), I/O de disco (iostat), rede, depois o processo, e confira logs e mudanças recentes. Citar o método USE (utilização, saturação, erros) sinaliza maturidade.
Requisições estão dando timeout de forma intermitente entre dois serviços. Como você isola a causa? Como abordar: localize primeiro (todas as requisições ou um subconjunto, uma instância ou todas), depois cheque esgotamento do pool de conexões, DNS, tempestades de retry e uma dependência lenta causando timeouts em cascata que circuit breakers contêm.
O que acontece, de ponta a ponta, quando você digita uma URL e aperta enter? Como abordar: cubra a resolução de DNS, os handshakes de TCP e TLS, a requisição, o processamento no load balancer e no servidor e a renderização, mas como SRE puxe para onde mora a confiabilidade: camadas de cache, reuso de conexão e quais saltos falham mais.
Explique o que é um thundering herd e como você preveniria um. Como abordar: defina o problema (muitos clientes batendo num recurso ao mesmo tempo depois de um cache expirar ou de um restart) e dê defesas concretas: backoff com jitter, coalescência de requisições e TTLs de cache escalonados.
Design de sistemas com foco em confiabilidade
Projete um sistema para atender 1 milhão de requisições por segundo com meta de disponibilidade de 99,95 por cento. Como abordar: declare as premissas e o SLO primeiro, depois projete para a falha (redundância entre zonas de disponibilidade, balanceamento de carga, cache, degradação graciosa). O sinal é se você raciocina sobre raio de impacto e pontos únicos de falha, não só sobre o caminho feliz.
Como você projetaria um rate limiter global? Como abordar: esclareça o escopo (por usuário, por IP, global), depois discuta token bucket versus janela deslizante e onde o estado mora (store compartilhada tipo Redis versus local com sincronização), aceitando que precisão global perfeita custa latência.
Como você libera com segurança uma mudança arriscada num serviço crítico? Como abordar: use entrega progressiva, canary para uma porcentagem pequena, acompanhe os SLIs e a queima do error budget e mantenha um rollback rápido e testado que aborta sozinho quando a métrica piora.
Erros comuns que afundam candidatos de SRE
O maior é tratar isso como uma entrevista puramente de código. Bons programadores reprovam em processos de SRE porque não conseguem depurar em voz alta nem quantificar disponibilidade.
Logo atrás vem perseguir 100 por cento de confiabilidade. Diga que você nunca toleraria indisponibilidade e acabou de anunciar que não entende error budgets nem o custo do último nove.
O terceiro é depurar no feeling. Reiniciar serviços aleatoriamente sem hipótese soa como pânico; os entrevistadores querem uma árvore de decisão calma e narrada mesmo quando você não chega à resposta.
O quarto é culpar. Qualquer história de incidente cuja moral seja "um desenvolvedor fez besteira" em vez de "o nosso sistema deixou um erro chegar à produção" reprova na régua cultural de qualquer casa séria.
O quinto é ficar no abstrato. "Eu adicionaria monitoramento" não significa nada, então nomeie o sinal, o limiar e o que o acionamento diria.
Como se preparar (e onde um copiloto ao vivo ajuda)
Monte um plano em camadas. Treine a matemática de confiabilidade até que as conversões de disponibilidade para indisponibilidade e o raciocínio de error budget saiam no automático, e releia os capítulos de tratamento de falhas do material de SRE do Google para aplicar, não para recitar. Pratique depurar em voz alta, porque a habilidade testada é a sua narração, não o acerto em silêncio. Mantenha o código afiado e escreva três incidentes reais em forma de linha do tempo, enquadrados sem culpabilização, com o que você mudou depois.
Entrevistas simuladas expõem as lacunas mais rápido, principalmente o músculo de falar enquanto pensa que as rodadas de troubleshooting exigem. É também aqui que um copiloto ao vivo se justifica. O GhostPilot roda no painel lateral do Chrome durante a sua entrevista real, escuta a conversa e mostra uma dica estruturada quando você trava: o próximo passo de depuração a verificar, uma conversão de SLO ou o modo de falha que você esqueceu numa rodada de design. Ele mantém o seu raciocínio andando quando o nervosismo apaga tudo, em vez de te entregar um script. Leia mais em ghostpilotai.com.
FAQ
Quão difícil é a entrevista de SRE comparada a uma de engenharia de software? Ela é mais ampla, não mais difícil. Você ainda encara código, mas soma troubleshooting de sistemas, matemática de confiabilidade e comportamento em incidentes, que é onde engenheiros de software preparados de forma estreita escorregam.
Engenheiros de confiabilidade de sites ainda precisam passar em rodadas de código em 2026? Sim. Quase todo processo de SRE inclui uma rodada de código, normalmente algoritmo moderado mais uma tarefa prática de ferramenta. A diferença para um processo puro de SWE é que o código é um pilar entre vários.
Como eu respondo perguntas comportamentais de SRE sobre incidentes? Use uma linha do tempo clara, foque em causas sistêmicas em vez de pessoas e termine com as melhorias concretas que você fez. O enquadramento sem culpabilização é o sinal que os entrevistadores escutam, então nunca deixe a história cair em cima de uma pessoa.
Qual é a melhor forma de praticar a rodada de troubleshooting de SRE? Ensaie depurar em voz alta contra cenários simulados de sistema quebrado, narrando cada hipótese e o sinal que a confirmaria ou mataria. A rodada avalia método e comunicação, então narrar vale mais que resolver em silêncio.
Experimente o GhostPilot AI
Entrevistas de SRE premiam raciocínio calmo e estruturado sob pressão, que é exatamente quando uma dica discreta ajuda mais. O GhostPilot roda no painel lateral do Chrome e não entra na captura de uma aba compartilhada, com um app de desktop para Windows opcional que é invisível para captura de tela no Windows 10 (build 2004 ou posterior) e no Windows 11. Comece grátis com sessões ao vivo de 10 minutos e respostas de IA ilimitadas, pegue um Session Pass por $29 (três entrevistas completas de duas horas, pagamento único, sem assinatura) ou vá de Pro por $59/mês ou $192/ano ($16/mês na cobrança anual).