Duas figuras sem rosto conversam a uma mesa, uma delas gesticulando com as mãos abertas, ao lado de um teclado e de uma caneca

Por que estas etapas pesam mais do que os engenheiros imaginam

A maioria dos engenheiros se prepara demais para algoritmos e trata a etapa comportamental como conversa informal. Os comitês de contratação fazem o contrário: as etapas de código são filtros de aprovado ou reprovado, enquanto as evidências comportamentais decidem o nível e os desempates. Os avaliadores procuram sinais específicos: ownership além do seu ticket, discernimento sob incerteza, como você digere o fracasso e se trabalhar com você dá energia ou cansa. Cada pergunta abaixo corresponde a um desses sinais.

Estruture as respostas com o STAR (os pesos que funcionam estão no nosso guia da central): dez segundos de contexto, ações em primeira pessoa, resultados com números.

Perguntas sobre divergência técnica

“Conte sobre uma vez em que você discordou da abordagem técnica de um colega de equipe.” “O seu tech lead escolheu um design que você achava errado. O que você fez?”

A armadilha é contar uma história em que você simplesmente tinha razão. O sinal que os entrevistadores procuram é como você discordou: você entendeu a outra posição bem o bastante para expô-la com justiça? Transformou opinião em evidência (um benchmark, um protótipo, um cenário de falha posto no papel)? Comprometeu-se sem reservas quando a decisão foi para o outro lado?

Uma boa estrutura: “Eu achava X, eles achavam Y. Y tinha uma vantagem real, que eu reconheci: [diga qual]. Montei um pequeno benchmark para testar a minha preocupação; ele mostrou [número]. Seguimos com um Y modificado, que dava conta do caminho mais crítico (o hot path). O que eu levo disso: transformar a discussão em um experimento tomou uma tarde e poupou três semanas de debate.”

Perguntas sobre incidentes e falhas

“Conte sobre uma vez em que você derrubou a produção.” “Descreva a pior indisponibilidade que você já enfrentou.” “Um bug que você colocou em produção prejudicou usuários. Conte como foi.”

Todo engenheiro sênior já derrubou a produção; fingir o contrário passa por inexperiência ou por desonestidade. A avaliação gira inteiramente em torno da sua relação com a falha:

  • Assuma a cadeia de decisões. “Pulei o canary porque o diff parecia trivial” vale mais do que “o sistema de deploy permitiu”.
  • Mostre disciplina de incidente: detecção, mitigação primeiro, causa raiz depois, comunicação com as equipes afetadas.
  • Termine na correção sistêmica: a classe de testes que agora existe, o alerta que agora dispara, o item de checklist que agora bloqueia. A cultura de post-mortem sem culpados é a senha; a correção sistêmica é a prova de que você realmente a pratica.

Perguntas sobre ownership e iniciativa

“Conte sobre algo que você melhorou sem que ninguém pedisse.” “Uma vez em que você foi além da sua função.”

O sinal que distingue o nível pleno do sênior é o tamanho da responsabilidade que você sente como sua: o seu ticket vs. os resultados da equipe vs. a trajetória da organização. Boa matéria-prima: a suíte de testes instável que você consertou e que destravou todo mundo, a migração que você propôs e conduziu, o runbook de plantão que você escreveu depois de uma escala sofrida, a dependência entre equipes que você desembaraçou. Inclua o custo sem glamour (“gastei duas sextas-feiras nisso”): são os detalhes do custo não recompensado que tornam convincentes as histórias de iniciativa.

Perguntas sobre discernimento técnico

“Conte como foi uma decisão técnica difícil.” “Uma vez em que você escolheu o ‘bom o suficiente’ em vez do ‘certo’.” “Descreva um trade-off em que você errou.”

Estas perguntas testam se você raciocina em trade-offs ou em absolutos. Uma resposta de nível sênior nomeia os eixos de forma explícita (latência vs. custo, prazo de entrega vs. dívida técnica, desenvolver vs. comprar), aponta a restrição que predominou e descreve o processo de decisão: o que você prototipou, quem consultou, o que teria feito você mudar de ideia. Se a pergunta for sobre uma decisão errada, a lição precisa ser operacional (“hoje eu anoto os meus critérios de reversão antes de me comprometer”), não sentimental (“aprendi a ter cuidado”).

Perguntas sobre colaboração e code review

“Como você lida com um review em que o autor contesta os seus comentários?” “Uma vez em que você recebeu um feedback duro.” “Como você faz o onboarding de um engenheiro júnior?”

  • Conflito em code review: separe as questões que bloqueiam (correção, segurança) das preferências (estilo); ceda nas preferências de forma explícita. Nomear essa distinção em voz alta já é, por si só, o sinal de senioridade.
  • Receber feedback: escolha uma história em que o feedback doeu e estava certo. O arco é: postura defensiva inicial → verificação → mudança de comportamento com evidências.
  • Mentoria: mecanismos concretos valem mais do que boas intenções: cadência de pareamento, “primeiro PR na primeira semana”, escopo que cresce aos poucos, deixar a pessoa conduzir um incidente com você na retaguarda.

Um banco de 15 perguntas para praticar

Pratique em voz alta e com tempo marcado, gravando as suas respostas ou em uma simulação com um assistente de entrevista com IA que transcreve e faz um balanço com você. Mire em seis histórias reutilizáveis que cubram a lista inteira:

  1. Uma vez em que você discordou do seu tech lead e estava errado.
  2. Uma vez em que você discordou e estava certo. Como você convenceu a sala?
  3. O seu pior incidente em produção, do início ao fim.
  4. Um projeto que atrasou muito. O que você fez quando percebeu o atraso?
  5. Algo que você construiu sem que ninguém pedisse. Valeu a pena?
  6. A decisão técnica mais difícil da sua carreira.
  7. Uma vez em que você escolheu velocidade em vez de qualidade. Faria de novo?
  8. Uma vez em que você herdou um código péssimo. O que você fez de fato?
  9. Um feedback duro que você recebeu e o que mudou.
  10. Uma discussão em comentários de review que esquentou.
  11. Como você ajudou um colega com dificuldades a acompanhar a equipe.
  12. Uma vez em que você precisou dizer não a um Product Manager.
  13. O trabalho de que você mais se orgulha e a maior concessão que ele exigiu.
  14. Uma vez em que você deixou passar algo importante em um review.
  15. Por que você está saindo, e por que aqui? (Tenha esta resposta na ponta da língua; o roteiro geral está na central.)

As suas histórias, afiadas sob pressão.

O ChadFlow ouve a entrevista, entrega a você uma primeira frase baseada no seu contexto quando a pergunta chega e depois orienta você a partir da transcrição, invisível no compartilhamento de tela.

Baixar o ChadFlow