O guia definitivo de entrevistas comportamentais para engenheiros
A diferença entre pleno e sênior não está no seu código - está em como você conta suas histórias
Quando entrei na Brex, a entrevista que eu tive o melhor desempenho foi a comportamental.
E isso foi fundamental para que eu me destacasse no meio de outros candidatos.
Isso não foi coincidência. Em 2020, com apenas 3 anos de experiência, aconteceu a mesma coisa. Haviam muitos candidatos com mais bagagem técnica que eu. Mas fui escolhido devido à minha performance na entrevista comportamental.
Ainda assim, é o assunto que menos discutimos.
Falamos sobre leetcode, system design, linguagens de programação. Mas raramente sobre como contar nossas histórias de forma que demonstrem senioridade e preocupação com o produto.
Hoje vou compartilhar exatamente como me preparar para dominar essa etapa. O mesmo método que uso há anos.
✨ O que esperar do artigo
A estrutura exata para transformar qualquer experiência em uma história de impacto
As 7 perguntas que sempre aparecem (com templates de resposta prontos)
Como nossa adaptabilidade brasileira é um superpoder em startups internacionais
Por que a comportamental decide seu nível (e salário)
Vou ser direto: para cargos senior+, a comportamental tem mais peso que a técnica.
Por quê? Senior é a primeira posição de liderança. Você deixa de ser apenas um executor. Passa a influenciar, mentorar, tomar decisões que impactam o time inteiro.
Se você falhar na comportamental, dois cenários possíveis:
Rejeição completa - não atendem as expectativas mínimas
Down-level - fez processo para senior, recebe oferta como pleno
Ambos custam caro. Literalmente. A diferença entre L4 e L5 pode ser R$10k/mês ou mais.
O que empresas realmente avaliam
Quando estão crescendo uma equipe, duas preocupações principais:
Caráter que se identifique com a cultura
Capacidade de aprender as habilidades necessárias
Note a ordem. Caráter vem primeiro.
"Hire for character, train for skill" - Peter Schutz, ex-CEO da Porsche
Ouvi essa frase num onboarding em 2016. Nunca esqueci.
É muito mais difícil mudar o caráter de alguém do que ensinar uma nova tecnologia. Um desenvolvedor tóxico com código perfeito destrói times inteiros.
Por isso entrevistadores são aversos ao risco. Preferem perder uma boa contratação do que fazer uma contratação ruim.
Como exploro no artigo sobre senior de 3 vs pleno de 10 anos, senioridade não é sobre anos de experiência. É sobre impacto e liderança.
A Estrutura U-Shape + SBI que sempre funciona
Esqueça o método STAR. Use-o apenas como um linter para suas histórias.
Vou te ensinar duas estruturas poderosas: U-Shape e SBI.
O Framework U-Shape
Suas histórias devem formar um "U" narrativo:
*1. Anchor Your Status*
Comece estabelecendo seu papel e responsabilidades. Use termos da própria vaga quando possível.
"Como único desenvolvedor frontend da squad de pagamentos..."
*2. Layer in Conflict*
O vale do U. Descreva o problema REAL e os obstáculos. Quanto mais profundo o vale, maior o problema que você consegue resolver.
"Nossa página de pagamentos levava 500ms para carregar. Descobri que power users acessavam ela 500 vezes por sessão. Isso significava 4 minutos de espera só olhando loading..."
3. Achieve Success
A subida. Sua ação específica e o resultado mensurável.
"Implementei cache no Apollo que já tínhamos mas não usávamos direito. Reduzi o tempo de espera em até 195 segundos por sessão. Mantive a atualização em segundo plano para garantir precisão dos dados financeiros."
Se você quer ter mais exemplos de histórias nesse formato, recomendo esse vídeo do A Life Engineered.
O Framework SBI (mais simples)
Para respostas mais diretas:
Situation: O contexto e objetivo
Behavior: O que VOCÊ fez especificamente
Impact: O resultado quantificado (mais sobre como quantificar em breve)
Os 3 pontos que sempre demonstrar
Em TODA resposta, reforce pelo menos um destes pontos:
Paixão pela Engenharia de Software - entusiasmo genuíno pelo que faz
Contribuição para o Sucesso da Empresa - alinhamento com objetivos de negócio
Cuidado com as Pessoas - respeito e consideração pelos outros
Veja a diferença:
Resposta genérica:
"Sou desenvolvedor há 5 anos, trabalho com React e Node, já passei por 3 empresas..."
Resposta com propósito:
"Sou apaixonado por resolver problemas reais dos usuários. Nos últimos 5 anos, sempre busquei entender o impacto do meu código no negócio - como quando reduzi o tempo de checkout em 40% e melhorei a experiência para nossos usuários. Adoro compartilhar conhecimento e ver júniors crescerem..."
Ambas são honestas. Mas só uma avança a conversa.
O superpoder brasileiro: Fazer o que precisa ser feito
Nós nascemos no Brasil, e sabemos que não é um país para amadores.
Mas, isso trás uma vantagem: aprendemos a ser resilientes.
Sabemos nos adaptar para vários tipos de situações.
E isso é algo extremamente bem visto para vagas em qualquer startup.
Em várias empresas que já trabalhei, não tive o luxo de dizer "isso não é minha área". E isso trás aprendizados enormes e adaptabilidade imprescindível para vagas em empresas menores.
História real de adaptabilidade
"Quando entrei na Brex, notei que não tínhamos nenhuma analytics no serviço de pagamentos. Nunca tinha usado Amplitude antes, mas vi a oportunidade. Criei um RFC, implementei tracking em todos os pontos críticos do fluxo. O que começou como iniciativa pessoal virou o dashboard principal do time todo. Hoje usamos para todas as decisões de produto."
Isso demonstra:
Identificou lacuna além das suas tarefas
Aprendeu ferramenta nova por conta própria
Criou solução que beneficiou time inteiro
Ownership além do esperado
Empresas internacionais valorizam MUITO essa proatividade. É o que nos diferencia de devs de outros países que são mais especializados mas menos flexíveis.
O diferencial: Se importe com o resultado, não só com a entrega
A maioria dos devs entrega a feature e segue em frente. Seniors se importam se resolveu o problema de verdade.
Exemplo de ownership real
"Implementamos permissões customizadas para pagamento de boletos. Mas não parei na entrega - criei dashboard para medir adoção. Descobri que 40% dos clientes usavam a feature. Mais importante: desbloqueamos deal de $1M/ano que estava travado por falta dessa funcionalidade."
Perguntas que você deveria sempre fazer:
Os usuários estão usando?
Resolveu o problema original?
Qual foi o impacto no negócio?
O que aprendemos para próxima vez?
Como exploro em "Como medir o impacto do seu trabalho", métricas transformam "fiz X" em "gerei Y de valor".
Essa mentalidade de ownership é o que separa plenos eternos de seniors de verdade.
Sem acesso a métricas? Como demonstrar impacto mesmo assim
Nem todo dev tem acesso ao Google Analytics ou dashboards de negócio. Isso não é desculpa para não quantificar.
Opção 1: Estime baseado no que você observa
Em vez de: "Melhorei o sistema de login"
Diga: "O sistema de login que refatorei é usado por ~5000 usuários diários da plataforma. Reduzi de 3 cliques para 1, economizando aproximadamente 10 segundos por login."
Opção 2: Use métricas internas do time
Em vez de: "Criei ferramenta de debug"
Diga: "Criei ferramenta de debug para time de 8 devs. Antes, gastávamos ~2h para encontrar erro em produção. Com a ferramenta, 15 minutos. Economia de 10h/semana para o time."
Opção 3: Descreva o escopo do impacto
Em vez de: "Implementei novo relatório"
Diga: "Implementei relatório usado pelo C-level para decisões semanais. 5 diretores dependem dele toda segunda para definir prioridades da semana."
Opção 4: Use proxies visíveis
Número de usuários afetados: "Feature usada por todos os 200 clientes enterprise"
Frequência de uso: "Tela acessada ~50 vezes por dia por cada vendedor"
Tamanho da empresa: "Sistema crítico para empresa de 500 funcionários"
Redução de reclamações: "Não recebemos mais os ~5 tickets/semana sobre esse problema"
Tempo economizado: "Processo que levava 1h agora leva 10 minutos"
Exemplo prático de como estimar
"Implementei cache na API de produtos. A empresa tem 10k usuários ativos. Se cada um acessa produtos 5x por dia, e economizei 200ms por request, são 10k 5 0.2s = 2.7 horas de espera eliminadas por dia."
Não precisa ser 100% preciso. O importante é mostrar que você pensa em impacto.
Frases úteis quando não tem números exatos
"Baseado no tamanho da nossa base (~X usuários)..."
"Considerando que o time tem Y pessoas..."
"A feature é acessada aproximadamente Z vezes por dia..."
"Eliminamos a principal reclamação dos usuários que era..."
"O CEO mencionou que isso desbloqueou..."
"Mas eu só faço CRUD na consultoria"
Toda experiência pode virar uma história de impacto. Veja como transformar trabalho "simples":
CRUD básico →
"Padronizei componentes de formulário reduzindo bugs em 30% e tempo de desenvolvimento de telas novas de 3 dias para 1"
Manutenção →
"Identifiquei que 60% dos bugs vinham do módulo de autenticação. Refatorei por iniciativa própria, eliminando 15h/mês de retrabalho"
Feature simples →
"Implementei filtros no relatório. Mas também instrumentei analytics e descobri que salvava 2h/semana para o time de vendas"
Bug fixing →
"Criei documentação de 'bugs comuns e soluções' que reduziu tempo de onboarding de novos devs de 1 mês para 2 semanas"
O segredo: sempre conecte com impacto no negócio ou no time.
As 7 perguntas que sempre aparecem (com respostas práticas)
1. "Tell me about a time you disagreed with your manager"
O que avaliam: Sua capacidade de discordar respeitosamente e defender ideias com dados.
Template:
"Meu manager queria [solução A]. Eu propus [solução B] porque [dados/evidências]. Apresentei um POC demonstrando [benefícios]. Chegamos num meio termo que [resultado positivo]."
Exemplo real:
"Manager queria adicionar mais campos no formulário. Mostrei que 70% dos usuários abandonavam com os campos atuais. Propus primeiro melhorar conversão, depois adicionar campos. Teste A/B provou: conversão subiu 25%."
Nunca diga: "Meu chefe estava errado e eu provei isso."
2. "What's your biggest failure?"
O que avaliam: Autocrítica, aprendizado e responsabilidade.
Template com exemplo real:
"Estimei 4 semanas para projeto de permissões. Não mapeei todas as entidades afetadas - descobri conexões só durante implementação. Atrasou 4 semanas. Mas comuniquei semanalmente no canal público, criei documentação de todos os componentes afetados, e entregamos desbloqueando $1M em vendas. Hoje sempre faço system mapping antes de estimar."
Nunca diga: "Nunca falhei" ou culpe outros.
3. "How do you influence without authority?"
O que avaliam: Liderança informal e habilidades de persuasão.
Exemplo prático:
"Precisava convencer 3 times a adotar novo padrão de logs. Criei dashboard mostrando que levávamos 2h para debugar problemas. Com padrão novo: 15 minutos. Fiz demo em cada time mostrando o benefício específico deles. Todos adotaram em 2 sprints."
4. "Describe a project with ambiguous requirements"
O que avaliam: Navegação em incerteza e proatividade.
Exemplo real:
"Recebi pedido vago: 'melhorar experiência de pagamento'. Analisei dados: 30% abandonavam no upload de boleto. Prototypei 3 soluções. Teste com 5 usuários. Implementamos a vencedora: abandono caiu para 5%."
5. "What's your proudest achievement?"
Template com exemplo realista:
"Reduzi loading da página mais acessada de 500ms para instantâneo usando cache que já existia mas não usávamos. Usuários power economizavam 3-4 minutos por dia. Orgulho porque identifiquei o problema sozinho, aprendi a ferramenta e o impacto foi imediato."
6. "Tell me about a time you had to learn something quickly"
Exemplo prático:
"Cliente grande precisava integração com SAP em 2 semanas. Nunca tinha tocado em SAP. Montei plano: documentação oficial, videos YouTube, 1:1 com dev que conhecia. Em 3 dias fiz POC. Em 2 semanas, integração completa em produção."
7. "Describe a conflict with a teammate"
Template realista:
"Colega insistia em microserviços para projeto pequeno. Entendi a preocupação dele: escalabilidade futura. Propus monolito modular que poderíamos quebrar depois. Documentei prós/contras. Concordamos e economizamos 3 meses de desenvolvimento."
Diferença Cultural: Brasil vs Internacional
No Brasil: Valorizamos humildade, às vezes excessiva.
Lá fora: Esperado que você "se venda" mais.
O que parece arrogância aqui é considerado confiança normal lá. Ajuste seu dial:
Brasil: "Ajudei um pouco no projeto..."
Internacional: "Liderei a implementação que economizou R$200k"
Não é mentir. É dar crédito ao seu trabalho.
Como brasileiros se sabotam
Minimizam conquistas: "não foi nada demais"
Compartilham crédito excessivamente: "o time fez tudo"
Evitam falar de números: "melhorou bastante"
Pedem desculpa por sucessos: "tive sorte"
Corrija isso. Você trabalhou duro. Merece reconhecimento.
Preparação prática: Seu checklist completo
Passo 1: Documente suas histórias
Escreva 5-6 experiências diferentes cobrindo:
Conflito resolvido
Falha e aprendizado
Liderança sem autoridade
Projeto ambíguo
Maior sucesso
Mentoria oferecida
Aprendizado rápido
Adaptação/fazer além do esperado
Passo 2: Adicione métricas sempre (ou as melhores estimativas)
❌ "Melhorei a performance"
✅ "Reduzi tempo de resposta de 3s para 200ms (93% mais rápido)"
✅ "Sistema usado por ~1000 usuários/dia agora carrega 3x mais rápido"
Não tem analytics? Estime baseado em:
Tamanho da empresa/base de usuários
Frequência de uso da feature
Tempo economizado para pessoas
Tickets/reclamações eliminados
Passo 3: Pratique em voz alta
Grave você mesmo contando cada história
Objetivo: 2-3 minutos por resposta
Natural > Perfeito
Passo 4: Misture seus exemplos
Não use a mesma história para todo entrevistador no mesmo dia. Se você tem 5 entrevistas, precisa de pelo menos 5 histórias diferentes.
O que NUNCA fazer
1. Mentir ou usar histórias dos outros
As follow-ups vão te expor. É impossível dar detalhes de algo que não viveu.
2. Criar "vilões"
"Meu colega era incompetente" = red flag gigante. Mantenha profissional sempre.
3. Descrever sucesso perfeito
Vida real é bagunçada. Adicione: "Não foi perfeito, tivemos que ajustar X, mas no final..."
4. Não ter histórias preparadas
"Hmm, deixa eu pensar..." repetido = despreparo.
5. Focar só na técnica
"Usei React com Redux" não impressiona. "Reduzi tempo de checkout em 40%" impressiona.
Recursos para praticar
A Life Engineered - Canal excepcional no YouTube
Tech Interview Handbook - Seção comportamental completa
Método STAR - Use como "linter" para verificar se sua história está completa
Nossa comunidade - Pratique com outros devs brasileiros. Mande sua história, peça feedback.
🌟 Resumo
Prepare 5-6 histórias que cubram diferentes situações e demonstrem crescimento
Use a estrutura U-Shape para criar narrativas impactantes (status → conflito → sucesso)
Quantifique tudo - números convencem mais que adjetivos (estime se não tiver dados exatos)
Mostre adaptabilidade - nossa vantagem competitiva como brasileiros
Demonstre ownership - se importe com resultados, não só entregas
Ajuste para cultura internacional - venda suas conquistas sem medo
Pratique em voz alta - naturalidade vem com repetição
Transforme qualquer experiência - até CRUD pode virar história de impacto
Lembre-se do melhor conselho: Se divirta. Tente não levar as coisas tão a sério.
A entrevista comportamental é apenas uma conversa entre dois profissionais. Você contando suas experiências para alguém genuinamente interessado em conhecer seu trabalho.
Como exploro em "Como se destacar em qualquer processo seletivo", o melhor sinal de sucesso é quando parece uma conversa entre amigos.
E como sempre digo: trate todo este processo como apenas uma quest no enorme RPG que é a vida.
Mesmo se der errado, você ganha experiência. E na próxima vez, suas histórias serão ainda melhores.
Checklist final de preparação:
Documentei 5-6 histórias diferentes
Cada história tem números/métricas específicas (ou estimativas razoáveis)
Pratiquei em voz alta (2-3 min cada)
Gravei e ouvi minhas respostas
Tenho uma história para cada arquétipo
Cada história mostra adaptabilidade ou ownership
Tenho pelo menos uma história de "fiz além do pedido"
Sei o impacto real (ou estimado) de pelo menos 3 projetos
Ajustei tom para contexto internacional
Próxima vez que entrar numa comportamental, você não vai só passar - vai definir seu nível. E seu salário.
Boa sorte! 🚀
P.S.: Se você ainda está pensando "mas meu trabalho não é interessante", volte nas seções "Mas eu só faço CRUD" e "Sem acesso a métricas?". Toda experiência pode ser uma história de crescimento. É só questão de como você conta.
Fico feliz que você leu o artigo até o final! 🙏
Você também pode clicar no botão de curtir ❤️ e compartilhar este artigo com outras pessoas.
Temos também um programa de indicação.
Indicando 5 pessoas: 1 mês grátis de acesso (valor de R$99,90)
Indicando 15 pessoas: 3 meses (valor de R$299,70)
Indicando 30 pessoas: mentoria individual comigo de 1h (valor de R$750)