Perguntas de entrevista para DevOps que testam comportamento em incidente, não lista de ferramenta
Lista de ferramenta é a coisa menos útil de um currículo de DevOps. As ferramentas mudam a cada dois anos e quem é competente pega uma nova em semanas. O que não muda é como a pessoa age durante um incidente: se comunica enquanto apaga incêndio, se busca rollback antes de uma correção esperta, e se o post-mortem dela procura falha de sistema ou pessoa para culpar. Esses três preveem a duração dos seus incidentes muito melhor que qualquer ferramenta.
O que o trabalho envolve de verdade
Quem trabalha com DevOps ou SRE constrói e opera os sistemas em que o resto da engenharia publica: pipeline, infraestrutura, monitoramento, alerta e a escala de plantão que pega o que o monitoramento não pegou. Boa parte do trabalho é invisível quando está dando certo, o que torna fácil subfinanciar e fácil subvalorizar numa entrevista.
A parte de alto risco é pequena e concentrada. A maior parte do ano é melhoria contínua; um punhado de horas são incidentes em que o custo de uma decisão ruim é medido em minutos de cliente. Triar como a pessoa age nessas horas é a maior parte do que a entrevista deveria fazer.
As perguntas, e como soa uma boa resposta
Use as perguntas como estão. Cada uma vem com o que é uma resposta forte, para que duas pessoas avaliando o mesmo candidato cheguem à mesma conclusão pelo mesmo motivo.
1. A produção está fora, você não sabe por quê, e tem uma hipótese que levaria vinte minutos para testar.
Uma boa resposta: Restabelece o serviço primeiro — rollback, failover, feature flag — e investiga depois. Resposta forte diz com todas as letras que entender não é prioridade enquanto o cliente está fora. Depurar para a frente com serviço caído é o instinto mais caro dessa função.
2. Quem você avisa, e quando, durante um incidente?
Uma boa resposta: Cedo e em cadência, com impacto em termos de cliente e não em detalhe técnico. Nomear alguém responsável pela comunicação separado de quem está corrigindo é resposta forte. Silêncio enquanto corrige heroicamente é a falha.
3. Me conta de um post-mortem que você escreveu.
Uma boa resposta: Linha do tempo, fatores contribuintes, ações sistêmicas com responsáveis: e nenhuma pessoa nomeada como causa. Se aparece uma pessoa como causa raiz, isso é a resposta, e te diz como era a cultura de onde a pessoa veio.
4. Alguém quer publicar algo numa sexta à tarde.
Uma boa resposta: Depende da maturidade do rollback e da observabilidade, não do dia. Resposta forte reformula como pergunta de confiança em reverter. Regra absoluta para qualquer lado é resposta mais fraca.
5. O seu alerta está barulhento e as pessoas começaram a ignorar.
Uma boa resposta: Trata como emergência, porque é. Alerta ignorado é pior que alerta nenhum. Apaga ou ajusta com agressividade em vez de escrever documentação sobre quais alertas importam.
6. Te pedem para construir algo que você acha superdimensionado para o momento.
Uma boa resposta: Fala, com o trade-off, e constrói o simples se for vencido. Superdimensionar é a falha característica da disciplina e autoconsciência sobre isso é bom sinal.
7. Como você mantém o plantão sustentável?
Uma boa resposta: Medidas concretas, orçamento de alerta, escala justa, folga depois de noite ruim, corrigir a causa do alerta repetido. Quem não tem opinião aqui esgota e leva o time junto.
8. Algo que você automatizou causou uma indisponibilidade.
Uma boa resposta: Assumido, com a proteção que estava faltando. Falha de automação é a categoria de erro própria da disciplina e como a pessoa fala da dela é informativo.
Uma ficha de avaliação para pontuar
Dê de 1 a 4 em cada linha, e anote a nota antes de assistir ao próximo. A nota escorrega quando ela é dada em relação a quem você acabou de ver.
| Critério | Como é uma nota 4 |
|---|---|
| Restabelecer antes de diagnosticar | Faz rollback ou failover primeiro. Nota 2 depura para a frente com cliente fora. |
| Comunicação em incidente | Comunica cedo, em cadência, em termos de cliente. Nota 2 fica em silêncio corrigindo. |
| Análise sem culpado | Post-mortem nomeia fatores sistêmicos. Nota 2 nomeia uma pessoa. |
| Higiene de alerta | Trata alerta barulhento como urgente e apaga. Nota 2 documenta em volta. |
| Plantão sustentável | Cita medidas concretas. Nota 2 trata esgotamento como inevitável. |
Como rodar a triagem
- Use a rodada gravada para as perguntas de incidente e post-mortem. Comunicação de incidente é literalmente habilidade falada, e este é um dos poucos contextos técnicos em que gravação é quase amostra de trabalho.
- Guarde uma rodada prática ou de desenho de sistema para a avaliação técnica. Nada aqui testa se a pessoa constrói o pipeline.
- Dê o maior peso à pergunta de restabelecer contra diagnosticar. É o indicador isolado mais claro de duração de incidente.
- Preste atenção se alguém é nomeado como causa raiz. É leitura rápida da cultura de onde a pessoa veio e da que ela vai trazer.
- Não trie por lista de ferramenta. Pergunte o que ela escolheria hoje e por quê, que testa julgamento e não exposição.
Rodar isso numa pilha grande de inscritos é onde a conta cresce. A VoxScreen manda essas perguntas num link só, transcreve e avalia cada resposta pelos critérios que você definiu e devolve a lista ranqueada — de graça para 50 candidatos por mês, sem cartão.
Erros comuns ao contratar para esta vaga
- Entrevistar sobre ferramenta. Elas giram a cada par de anos e quem é competente troca em semanas.
- Não testar comportamento em incidente. É onde o custo se concentra e é o que menos aparece num currículo.
- Contratar quem culpa pessoa em post-mortem. Isso suprime relato, e relato suprimido é como incidente pequeno vira grande.
- Ignorar sustentabilidade de plantão. A saída nessa disciplina é puxada por carga de alerta mais do que por qualquer outra coisa.
- Usar rodada gravada como triagem técnica. Ela mostra julgamento e comunicação. A rodada de sistema faz o resto.
Perguntas frequentes
O que perguntar para alguém de DevOps?
Pergunte o que faz quando a produção está fora e a hipótese levaria vinte minutos para testar, quem avisa e quando durante um incidente, e peça para contar um post-mortem que escreveu. Esses três cobrem instinto de restabelecer primeiro, comunicação e se a análise é sem culpado. Que juntos preveem duração de incidente melhor que qualquer pergunta de ferramenta.
Devo testar ferramenta específica em DevOps?
Não como filtro. Ferramenta gira a cada par de anos e quem é competente transfere em semanas, então lista de ferramenta mede principalmente onde a pessoa trabalhou por último. Pergunte o que ela escolheria para a sua situação e por quê, que testa julgamento e é bem mais difícil de preparar.
Como é um bom post-mortem?
Linha do tempo, fatores contribuintes e ações sistêmicas com responsáveis nomeados: e nenhuma pessoa identificada como causa raiz. Se a história do candidato termina numa pessoa que errou, isso te conta sobre a cultura de onde ele veio, e culpa suprime exatamente o relato de incidente de que você mais precisa.
Como triar sustentabilidade de plantão?
Pergunte direto como a pessoa mantém plantão sustentável e ouça mecanismo concreto — orçamento de alerta, escala justa, folga depois de noite ruim, corrigir alerta repetido em vez de documentar. Saída nessa disciplina é puxada por carga de plantão mais do que por salário, e quem não tem opinião sobre isso não vai consertar a sua.