Questions to Ask in a DevOps Engineer Interview

A entrevista vai bem até o momento em que o recrutador pergunta: "tem alguma dúvida para nós?". Você diz "não, por enquanto está tudo claro", e perde a chance de parecer sênior em quinze segundos.

Perguntar bem é o sinal mais rápido de senioridade que existe em entrevista. Não é teatro, é curadoria: você está decidindo onde vai passar os próximos dois anos da sua carreira. E uma vaga de DevOps mal estruturada custa caro, em madrugadas e em burnout.

Este guia traz 12 perguntas divididas pelo que elas revelam, o que evitar, e como ler as respostas que você ouvir.

Por que perguntar muda o jogo#

Recrutador e gestor avaliam candidato pelo que ele pergunta tanto quanto pelo que ele responde. Pergunta genérica soa como quem está mandando currículo em massa. Pergunta específica sobre on-call, pipeline ou governança soa como quem já trabalhou em produção.

Além disso, entrevista é via de mão dupla. Você está avaliando se aquela empresa vai te dar trabalho interessante ou só vai te colocar para apagar incêndio o dia inteiro. As perguntas abaixo servem para isso.

Perguntas sobre a realidade do time#

Estas perguntas mostram se você entende como operação funciona de verdade.

1. Como é o processo de on-call hoje? Qual o volume médio de incidentes por semana e quando foi a última vez que o plantão foi pesado?

2. Quem é dono do quê? Existe um time de plataforma separado, ou cada squad cuida da própria infraestrutura?

3. Como vocês fazem handoff entre desenvolvimento e operação quando algo quebra em produção fora do horário comercial?

4. Qual a idade média dos sistemas que vocês mantêm? O que foi migrado nos últimos doze meses e o que ainda está rodando legado?

O que essa resposta revela

Se a pessoa desvia da pergunta sobre on-call, desconfie. Time maduro sabe quantos incidentes tem por mês porque mede isso. Se falam "aqui é bem tranquilo, quase nunca quebra", pode ser verdade ou pode ser que ninguém está medindo.

Resposta boa tem número. Resposta ruim tem adjetivo.

Perguntas sobre prioridades e direção#

Aqui você mostra que pensa em impacto, não só em tarefa.

5. O que está no topo da lista de melhorias para o próximo trimestre? Onde vocês sentem mais dor hoje?

6. Se você tivesse que contratar mais uma pessoa para o time, que perfil faria falta agora? Isso diz onde o time está esticado.

7. Como vocês decidem entre construir internamente ou comprar/adotar uma ferramenta pronta? Quem tem essa decisão?

O que essa resposta revela

Se a resposta sobre dor atual é "precisamos automatizar mais", é genérico demais. Todo mundo quer automatizar mais. Se a resposta é "nosso deploy leva 40 minutos e travamos no step de testes", você sabe exatamente onde entra.

Essa pergunta também mostra que você vai chegar resolvendo problema real, não esperando alguém te designar tarefa.

Perguntas sobre critérios de sucesso#

Perguntas que definem o que é "bom trabalho" naquela empresa. Sem isso, você fica refém de opinião.

8. Como vocês medem se a infraestrutura está saudável? Quais métricas o time olha toda semana?

9. Nos primeiros 90 dias, o que precisa estar verdade para você considerar que essa contratação deu certo?

10. Existe processo formal de revisão de arquitetura? Quem participa e com que frequência?

O que essa resposta revela

A pergunta dos 90 dias é a mais importante de todas. Se o gestor não sabe responder, provavelmente não tem plano para você. Você vai ser largado e esperado para "achar seu caminho", o que em DevOps costuma virar apagar incêndio.

Resposta boa lista duas ou três entregas concretas. Exemplo: "nos primeiros 90 dias queremos reduzir o tempo de deploy para menos de 10 minutos e ter documentação do pipeline atual".

Perguntas sobre riscos e dívida técnica#

Estas perguntas são as mais desconfortáveis e por isso as mais reveladoras.

11. Qual foi a última vez que uma mudança em produção causou incidente sério? Como o time reagiu e o que mudou depois?

12. O que existe hoje na stack que vocês gostariam de não ter? Qual a maior dívida técnica que o time carrega?

O que essa resposta revela

Se ninguém consegue citar um incidente recente, ou estão escondendo, ou não estão registrando. Ambos são problema.

Sobre dívida técnica: resposta saudável é específica e sem drama. "Nosso Terraform está com módulos duplicados e queremos consolidar" é normal. "Está tudo uma bagunça, ninguém sabe mais como funciona" é sinal para correr.

Exemplo de como usar as perguntas na prática#

Não é preciso fazer as 12. Escolha quatro ou cinco e adapte para o contexto. Veja como soa natural:

"Pelo que entendi da descrição da vaga, vocês estão expandindo o time de plataforma. Duas coisas que me interessam entender: como está organizado o on-call hoje, e qual é a maior dor do time no próximo trimestre. Também queria saber como vocês medem se a infraestrutura está saudável, porque gosto de trabalhar com meta clara."

Isso leva 30 segundos para falar e posiciona você acima de 90% dos candidatos.

Perguntas que você deve evitar#

Algumas perguntas parecem boas e sabotam você. Vale saber quais.

• Qual é o salário? Não como primeira pergunta. Espere a empresa abrir o assunto ou pergunte no final, junto com benefícios.
• Vocês usam [ferramenta X]? Pergunta fechada que mostra que você está caçando stack, não problema. Prefira "como vocês escolhem ferramentas".
• Tem possibilidade de home office? Importante, mas pergunte depois de demonstrar valor. No começo soa como quem quer o mínimo.
• O que a empresa faz? Pesquise antes. Perguntar isso diz que você não se preparou.
• Qual é o próximo passo do processo? Pergunta administrativa válida, mas deixe para o final e não use como sua principal contribuição.

Como ler o que você ouvir

Três sinais de alerta que aparecem nas respostas:

• Vagueza consistente. Se nenhuma resposta tem número, nome de ferramenta ou processo concreto, o time provavelmente não sabe o que está fazendo.
• Culpa sempre externa. "O dev escreve código ruim", "a gestão não entende", "o fornecedor é péssimo". Cultura de culpa é tóxica.
• Elogio vago à cultura. "Aqui é uma família" costuma significar fronteira entre trabalho e vida pessoal inexistente.

Três sinais positivos:

• O entrevistador admite o que não sabe ou o que está melhorando. Isso mostra maturidade.
• As respostas citam trade-offs. "Escolhemos X sabendo que ia custar Y" é fala de quem decide de verdade.
• Você é tratado como par, não como candidato pedindo favores.

Preparação antes da entrevista#

Vale chegar pronto. Algumas coisas concretas que ajudam:

• Leia a descrição da vaga com atenção e anote três termos técnicos que você quer explorar nas perguntas. Um decodificador de descrições de vaga ajuda a entender o que a empresa realmente pede.
• Pesquise a empresa em sites de vagas para ver se outras posições abertas revelam stack e prioridades. Nosso painel de vagas é um bom ponto de partida.
• Simule a entrevista em voz alta. Parece bobo, funciona.
• Teste seu currículo em um verificador de ATS antes de se candidatar a outras vagas. Currículo que não passa no filtro nunca chega na entrevista.
• Continue lendo nosso blog para mais conteúdo sobre carreira em engenharia e DevOps.

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Quantas perguntas devo fazer numa entrevista?

Quatro ou cinco perguntas bem escolhidas bastam. Mais que isso vira interrogatório e toma tempo que seria de conversa. Escolha perguntas de categorias diferentes, uma sobre o time, uma sobre prioridade, uma sobre sucesso.

Devo perguntar sobre salário na primeira entrevista?

Não como pergunta principal. Espere a empresa trazer o assunto, ou pergunte junto com benefícios no final. Se a faixa não for informada até a segunda etapa, pergunte de forma direta: "qual é a faixa prevista para essa posição?".

O que fazer se o entrevistador não souber responder?

Normal. Nem todo gestor conhece o processo de on-call em detalhe. Agradeça e pergunte se há outra pessoa no time que poderia responder na próxima etapa. O que importa é se a empresa se dispõe a buscar a resposta.

Essas perguntas servem para vaga júnior também?

Servem, mas adapte o tom. Em vez de perguntar sobre trade-offs de arquitetura, pergunte como é o processo de revisão e quem te ajudaria nos primeiros meses. Mostre que quer aprender com estrutura, não que já domina.

É ruim perguntar sobre home office e benefícios?

Não é ruim, é só mal posicionado. Faça isso no final, depois das perguntas técnicas e de contexto. Assim você sinaliza que está avaliando o trabalho primeiro e as condições depois, o que muda a percepção sobre você.