Entrevista comportamental: o método STAR que me destravou

Reprovei em mais entrevista comportamental do que em live coding. Isso me incomodava, porque behavioral parece a parte fácil: é só conversar sobre você. Cento e tantas entrevistas depois, discordo. Live coding tem resposta certa. Behavioral tem estrutura, e quem chega sem estrutura enrola.

A estrutura tem nome: STAR. Situation, Task, Action, Result. Quatro blocos, nessa ordem:

• Situation: o contexto, em duas frases. Onde você estava, o que estava pegando fogo.
• Task: qual era a sua responsabilidade ali. Sua, não do time inteiro.
• Action: o que você fez, passo a passo. É o miolo da resposta.
• Result: o que aconteceu no fim. De preferência com número.

O erro clássico: a novela sem final

Vexame registrado no caderno. Perguntaram: "tell me about a time you had to deal with a production issue." Falei por cinco minutos. Contexto da empresa, história do sistema, o que cada colega fazia, um detalhe do deploy. O entrevistador esperou educadamente e perguntou: "so... what was the outcome?" Eu tinha contado uma novela e esquecido o final. Situation de quatro minutos, Result de zero segundos.

Depois dessa, virou regra: Situation e Task, juntas, duram no máximo trinta segundos. O tempo de verdade é do Action e do Result. E se uma história não tem Result concreto, ela não entra no repertório. Sem exceção.

Um exemplo completo, do jeito que eu conto hoje

Pergunta que ouvi mais de uma vez: "tell me about a time you disagreed about priorities."

• Situation: a gente estava fechando uma feature prometida pro fim da sprint quando apareceu um bug em produção no fluxo de login. Parte dos usuários não conseguia entrar.
• Task: eu era o dev que conhecia aquele módulo. Precisava decidir o que atacar primeiro e alinhar com o PM, que queria manter a feature no prazo.
• Action: reproduzi o bug, medi quantos usuários eram afetados e levei número pro PM em vez de opinião. Propus pausar a feature por dois dias. Corrigi o bug e escrevi um teste de regressão pra ele não voltar.
• Result: o bug saiu de produção em um dia, a feature atrasou exatamente os dois dias combinados, e o time criou uma regra escrita de prioridade pra bug de produção. Em inglês, eu fecho assim: "the fix shipped in a day, and we turned the lesson into a written priority rule."

Uma história, quatro blocos, menos de dois minutos falando. O conflito aparece, a atitude aparece, o final existe.

Como montar 6 a 8 histórias reutilizáveis

O que mudou meu aproveitamento foi parar de preparar respostas e começar a preparar histórias. As perguntas mudam de casca, mas caem num punhado de temas. Meu repertório final tinha oito:

• Um bug ou incidente em produção
• Um conflito com colega ou PM
• Um prazo que não fechava
• Um erro meu, assumido, com o que mudei depois
• Uma tecnologia que aprendi rápido por necessidade
• Um projeto de que me orgulho
• Um feedback difícil que recebi
• Uma decisão tomada sem ter chefe pra perguntar

A mesma história do bug de login me serviu pra "conflict", pra "pressure", pra "difficult decision" e pra "tell me about a mistake". Só muda a ênfase. Escrevi as oito em inglês, li em voz alta até parar de soar decorado e passei a revisar antes de cada call. As perguntas mais comuns em inglês se repetem tanto que oito histórias cobrem quase tudo.

Dois avisos de quem errou os dois: não decore palavra por palavra. Decore os quatro marcos e improvise o resto, senão vira teatro. E treine o idioma antes: metade dos meus tropeços em behavioral era inglês de entrevista, não falta de história.

Quando o entrevistador terminar, a mesa vira. Os minutos finais são seus, e as perguntas que você faz também contam ponto.

Behavioral não mede quem você é. Mede se você conta o que fez com começo, meio e fim. Parece injusto, e talvez seja. Mas é treinável. Mesmas histórias, mesmo candidato: o que mudou entre as dezenas de reprovações e as aprovações foi só a estrutura.