Perguntas para Entrevista de Engenheiro de Confiabilidade de Sites (SRE) — Mais de 30 Perguntas e Respostas Especializadas

O Glassdoor reporta um salário médio de SRE de US$ 169.680, com o 75º percentil superando US$ 213.000 anuais [1]. A função — nascida no Google em 2003 e agora adotada por todas as principais empresas de tecnologia — fica na interseção entre engenharia de software e operações de sistemas, e o processo de entrevista reflete essa dualidade [2]. Entrevistas SRE testam design de sistemas com restrições de confiabilidade, codificação para automação, gestão de incidentes sob pressão e a mentalidade específica de quantificar confiabilidade através de SLOs e orçamentos de erro. Este guia cobre as perguntas comportamentais, técnicas e situacionais que você enfrentará, com respostas calibradas para o nível que empresas de ponta esperam.

Principais Conclusões

• Entrevistas SRE tipicamente incluem quatro a seis rodadas: codificação, design de sistema, troubleshooting, gestão de incidentes e comportamental — distribuídas ao longo de um dia inteiro ou múltiplas sessões [3].
• O diferencial central da entrevista SRE é design de sistema focado em confiabilidade — você deve projetar sistemas que degradem graciosamente, não apenas sistemas que escalam [2].
• SLOs, SLIs, orçamentos de erro e redução de toil são vocabulário específico de SRE que entrevistadores esperam que você use fluentemente.
• Perguntas de codificação para funções SRE enfatizam automação, ferramentas de infraestrutura e scripts operacionais em vez de puzzles algorítmicos puros [3].

Perguntas Comportamentais

1. Conte sobre o incidente mais impactante que você gerenciou. Qual foi seu papel e o que o postmortem revelou?

Resposta Especializada: "Fui o comandante de incidente durante uma falha em cascata que derrubou nosso serviço de autenticação principal, afetando 2,3 milhões de usuários ativos por 47 minutos. Uma mudança rotineira de configuração do rate limiter acidentalmente definiu o limite para 10 requisições por segundo em vez de 10.000. O serviço de auth atingiu o limite, retornou 429s, e a tempestade de retries dos clientes amplificou a carga 50x. Declarei P1, estabeleci o canal de incidente, atribuí funções e coordenei a resposta. A correção foi reverter a mudança de configuração, mas também tivemos que drenar o backlog de retries aumentando temporariamente a capacidade. O postmortem identificou três causas raiz: sem validação nos valores de configuração do rate limiter, sem deploy canário para mudanças de configuração e sem circuit breaker nos retries do cliente. Implementamos todas as três correções e adicionamos um canário sintético que testa o fluxo de auth a cada 30 segundos. O incidente consumiu 40% do nosso orçamento de erro trimestral, o que acionou um congelamento de desenvolvimento até que melhorias de confiabilidade fossem entregues."

2. Descreva uma vez em que eliminou uma fonte significativa de toil.

Resposta Especializada: "Nossos engenheiros de plantão gastavam em média 6 horas por semana escalando manualmente réplicas de leitura do banco de dados durante picos de tráfego. Construí um controlador de auto-scaling usando um operador Kubernetes customizado que monitorava métricas de CPU e latência de queries, calculava a contagem necessária de réplicas e escalava automaticamente. Intervenções manuais caíram de 6 horas/semana para 0, e a carga de plantão diminuiu 30%."

3. Dê um exemplo de como você recusou um requisito de confiabilidade que considerava muito agressivo.

Resposta Especializada: "Uma equipe de produto solicitou 99,999% de disponibilidade para um novo serviço de notificações. Calculei o que cinco noves realmente significa: 5,26 minutos de downtime por ano. O custo de engenharia foi estimado em 6 meses e US$ 400K em infraestrutura adicional. Propus 99,9% de disponibilidade, que nossa infraestrutura existente podia alcançar com melhorias menores. A equipe de produto concordou após ver a curva de tradeoff custo-confiabilidade. Esta é a disciplina SRE: confiabilidade é uma feature, e como todas as features, tem um custo que deve ser justificado pelo impacto no usuário [2]."

4. Conte sobre uma vez em que melhorou o monitoramento ou observabilidade de um serviço crítico.

Resposta Especializada: "Nosso serviço de pagamentos tinha monitoramento que só rastreava health checks básicos. Após uma falha silenciosa onde o serviço retornou 200 mas com dados de cache obsoletos por 3 horas, redesenhei nosso stack de observabilidade. Defini SLIs ligados à experiência do usuário, implementei métricas Prometheus, criei dashboards Grafana com alertas de burn rate de SLO e adicionei tracing distribuído com Jaeger. O alerting multi-janela reduziu falsos positivos em 60%."

5. Descreva como equilibrou velocidade de desenvolvimento de features com trabalho de confiabilidade.

Resposta Especializada: "Implementei uma política de orçamento de erro onde trabalho de confiabilidade e desenvolvimento de features eram governados pela mesma métrica. Acima de 50% do orçamento, velocidade total em features. Abaixo de 50%, dividimos 50/50. Abaixo de 25%, todo esforço vai para confiabilidade. Em um ano, a taxa de incidentes P1 caiu 45% enquanto a equipe de produto entregou 12% mais features."

6. Como você aborda rotações de plantão e como melhorou a experiência de plantão da sua equipe?

Resposta Especializada: "Vejo plantão como um problema de engenharia. Implementei ajuste de alertas, automação de runbooks e handoff estruturado. Páginas caíram de 14/semana para 4/semana, e a satisfação com plantão subiu de 2,1/5 para 4,3/5."

Perguntas Técnicas

1. Explique SLOs, SLIs e orçamentos de erro. Como se relacionam?

Resposta Especializada: "Um SLI é uma métrica quantitativa que mede um aspecto específico da qualidade do serviço. Um SLO é um valor-alvo para um SLI. O orçamento de erro é o inverso do SLO. Para um serviço com SLO de 99,9% atendendo 1 milhão de requisições por dia, você pode tolerar 1.000 falhas diárias. O orçamento de erro cria uma linguagem compartilhada entre SRE e equipes de produto [2]."

2. Projete um sistema de monitoramento e alerting para uma arquitetura de microsserviços com 50 serviços.

Resposta Especializada: "Construiria em três camadas: coleta de dados com Prometheus e métricas RED, agregação de logs via Loki, tracing distribuído via Jaeger. Alerting baseado em SLOs com burn rate multi-janela. Dashboards de sinais dourados por serviço e dashboard SLO de nível superior. Princípio: alertar em sintomas, não em causas."

3. Um serviço está respondendo lentamente. Me explique sua abordagem de troubleshooting.

Resposta Especializada: "Começo pelo impacto no usuário, depois aplico os métodos USE e RED sistematicamente. Verifico o serviço, dependências downstream, rede. Uso tracing distribuído para identificar o gargalo no caminho da requisição."

4. Como você projetaria um sistema para alcançar 99,99% de disponibilidade em múltiplas regiões?

Resposta Especializada: "Deploy ativo-ativo em pelo menos 3 regiões. Load balancing global com redirecionamento baseado em health check. Replicação síncrona intra-região, assíncrona inter-região. Deploys canário por região. Engenharia de caos regular para verificar failover."

5. Qual a diferença entre escalonamento horizontal e vertical, e quando você prefere cada um?

Resposta Especializada: "Escalonamento vertical aumenta recursos de uma instância. Horizontal adiciona mais instâncias. Prefiro horizontal para serviços stateless e vertical para componentes stateful onde horizontal introduz complexidade."

6. Explique infraestrutura como código (IaC) e como a usou para melhorar confiabilidade.

Resposta Especializada: "IaC trata configuração de infraestrutura como software: versionada, revisada, testada e reproduzível. Uso Terraform para provisionamento e Ansible para gestão de configuração. Benefícios: reprodutibilidade, auditabilidade e testabilidade."

7. Como você aborda planejamento de capacidade para um serviço em crescimento rápido?

Resposta Especializada: "Framework de quatro etapas: estabelecer modelo de carga, modelar crescimento, identificar recurso gargalo e automatizar resposta. Reviso planos de capacidade mensalmente."

Perguntas Situacionais

1. O orçamento de erro do seu serviço está esgotado faltando duas semanas no trimestre. A equipe de produto quer lançar uma feature importante. O que você faz?

Resposta Especializada: "O esgotamento aciona congelamento de confiabilidade. Apresento os dados e ofereço alternativas: feature flag com rollout gradual ou priorizar melhoria de confiabilidade. A política existe exatamente para isso [2]."

2. A mudança de um engenheiro júnior causou uma queda em produção. Como você conduz o postmortem?

Resposta Especializada: "O princípio é blamelessness — examinar o que aconteceu e por que o sistema permitiu, nunca quem é culpado. Ações corretivas melhoram o sistema, não punem o engenheiro [2]."

3. Você herda um sistema legado sem monitoramento, documentação e testes. Por onde começa?

Resposta Especializada: "Priorizo por raio de impacto. Semana 1: monitoramento básico. Semanas 2-4: documentar arquitetura. Mês 2: testes de integração. Mês 3: CI/CD. Princípio: não reescreva, estabilize."

4. Seu monitoramento mostra um vazamento lento de memória em produção. O serviço crasha e reinicia a cada 72 horas. Como aborda?

Resposta Especializada: "Quantifico impacto, habilito profiling de heap, comparo snapshots em intervalos regulares. Mitigação: restart graceful a cada 48h. Correção definitiva após identificar tipo de objeto vazando."

5. A liderança pede para reduzir custos de infraestrutura em 30% mantendo confiabilidade. Como aborda?

Resposta Especializada: "Right-sizing, capacidade reservada, instâncias spot e otimização de arquitetura. Confiabilidade não é negociável — redução de custo vem de eficiência, não de remover redundância."

Perguntas Para o Entrevistador

1. "Quais são os SLOs dos serviços desta equipe e como os orçamentos de erro são gerenciados?"
2. "Como é a rotação de plantão — quantos engenheiros, volume de páginas, política de escalonamento?"
3. "Como a equipe equilibra trabalho de projeto com trabalho operacional?"
4. "Qual é a relação da equipe com equipes de desenvolvimento — SRE embedded ou centralizado?"
5. "Qual é a abordagem da equipe para postmortems — são blameless e qual percentual de ações é completado?"
6. "Que infraestrutura e ferramentas a equipe gerencia?"
7. "Quais são os maiores desafios de confiabilidade que a equipe enfrenta atualmente?"

Formato da Entrevista e O Que Esperar

Entrevistas SRE em grandes empresas de tecnologia tipicamente duram 4-6 horas [3]. A rodada de codificação testa Python/Go/Java com problemas de automação. Design de sistema requer confiabilidade explícita. Troubleshooting apresenta cenário de produção. Comportamental avalia experiência de plantão e gestão de incidentes. O processo completo leva 3-6 semanas.

Como se Preparar

• Estude o livro Google SRE. Capítulos sobre SLOs, orçamentos de erro, toil e gestão de incidentes são fundamentais [2].
• Pratique design de sistema com restrições de confiabilidade.
• Prepare histórias de incidentes. 3-5 narrativas detalhadas.
• Revise fundamentos de Linux.
• Pratique codificação para automação.
• Conheça seu stack de observabilidade.

Erros Comuns em Entrevistas

1. Projetar para escala sem projetar para falha [2].
2. Não quantificar confiabilidade.
3. Tratar incidentes como problemas puramente técnicos.
4. Ignorar toil.
5. Super-engenheirar soluções [2].
6. Não entender o modelo de orçamento de erro.
7. Não demonstrar habilidade de codificação [3].

Principais Conclusões

• Entrevistas SRE testam uma mentalidade de engenharia específica: quantificar confiabilidade, fazer tradeoffs baseados em dados e tratar operações como problemas de engenharia de software.
• SLOs, SLIs, orçamentos de erro e toil são o vocabulário de SRE — use fluentemente.
• Prepare histórias detalhadas de incidentes.
• Respostas de design de sistema devem incluir modos de falha explícitos e estratégias de degradação graciosa.

Quer garantir que seu currículo leve você à entrevista? Experimente o verificador gratuito de pontuação ATS do ResumeGeni para otimizar seu currículo de SRE antes de se candidatar.

FAQ

Qual a diferença entre SRE e DevOps?

SRE é uma implementação específica dos princípios DevOps com práticas prescritivas: SLOs, orçamentos de erro, budgets de toil e um modelo de engajamento definido com equipes de desenvolvimento [2].

Quais linguagens de programação devo conhecer para entrevistas SRE?

Python e Go são as mais usadas em SRE [3].

Qual faixa salarial devo esperar como SRE?

Salários variam de US$ 128.842 a US$ 169.680, com o 75º percentil em US$ 213.272 [1].

Quão importante é o livro Google SRE para preparação?

Muito importante. Define os conceitos que a maioria das entrevistas SRE testa [2].

Preciso de experiência de plantão para conseguir uma vaga SRE?

Preferível, mas nem sempre obrigatório para posições de nível inicial.

Quais certificações são úteis para entrevistas SRE?

Google Cloud Professional Cloud DevOps Engineer, AWS DevOps Engineer Professional e CKA são as mais relevantes.

Como uma entrevista SRE difere de uma entrevista de engenharia de software?

Entrevistas SRE incluem design de sistema com restrições de confiabilidade explícitas, rodadas de troubleshooting e perguntas comportamentais sobre gestão de incidentes [3].