Entrevista de RH e comportamental para seniores: 24 perguntas com respostas

Em processos seletivos para posições Seniores e de Liderança Técnica, a etapa de RH (People & Culture, Hiring Managers e liderança de engenharia) tem peso eliminatório equivalente ao teste de código ou System Design.

Muitos engenheiros com excelente capacidade técnica são reprovados nessa fase porque acreditam que o RH busca apenas saber se o candidato é “amigável” ou “trabalha bem em equipe”.

Na realidade, o RH de empresas de alta performance (FAANG, fintechs e multinacionais) está avaliando competências de impacto sênior:

1. Influência sem Autoridade: Como você alinha decisões e resolve divergências técnicas com outros seniores, arquitetos e gerentes sem depender de um cargo de chefia.
2. Propriedade Extrema (Extreme Ownership): O que você faz quando algo quebra em produção por sua causa. Você assume a responsabilidade e cria processos para evitar reincidência, ou aponta dedos para a equipe/infraestrutura?
3. Efeito Multiplicador (Multiplier Effect): Como você eleva o nível técnico dos engenheiros juniores e plenos ao seu redor através de code reviews construtivos, mentoria e documentação.
4. Julgamento de Negócio vs. Débito Técnico: Como você negocia prazos com Product Managers (PMs) sem ser o desenvolvedor que sempre diz “não” e sem deixar a base de código virar um legado insustentável.

---

O Método STAR-L: A Fórmula de Resposta para Seniores

Toda resposta a perguntas comportamentais no nível sênior deve seguir a estrutura STAR-L:

[S] Situação   ──> Contexto rápido e escala do problema (1-2 frases).
[T] Tarefa     ──> Qual era a SUA responsabilidade exata naquele cenário.
[A] Ação       ──> O que VOCÊ fez (arquitetura, negociação, testes, código).
[R] Resultado  ──> Métricas quantificáveis de negócio e impacto real.
[L] Lição      ──> O que você aprendeu e como isso mudou sua prática futura.

⚠️ A Armadilha do “Nós”: Candidatos plenos usam o tempo todo “nós fizemos”, “nós decidimos”, “nossa equipe subiu”. O recrutador não está contratando a sua equipe antiga, está contratando você. Diga claramente: “A equipe estava com o prazo apertado; eu propus a arquitetura de cache, liderei a migração e negociei o escopo com o PM.”

---

As 24 Perguntas Mais Frequentes de RH para Nível Sênior

Bloco 1: Conflitos Técnicos e Influência

1. “Conte sobre uma vez em que você discordou fortemente da abordagem técnica de outro engenheiro sênior ou arquiteto. Como você lidou com isso?”

• O que o RH avalia: Maturidade emocional, humildade intelectual e o princípio de Disagree and Commit (discordar embasado em dados e, se vencido pelo consenso, abraçar a decisão sem boicote).
• Como responder:
  • Mostre que você não levou para o lado pessoal;
  • Descreva como você usou dados, métricas, benchmarks ou testes de carga para defender seu ponto em vez de “opinião”;
  • Se a outra proposta foi escolhida, mostre que você executou com profissionalismo e sem rancor.

2. “Como você convence um Product Manager ou stakeholder de negócio a adiar uma feature para pagar débito técnico?”

• O que o RH avalia: Capacidade de traduzir termos técnicos complexos para linguagem de valor financeiro e risco de negócio.
• Resposta Sênior: Nunca diga “o código está feio e precisa de refatoração”. Diga: “Mostrei ao PM que a taxa de conversão do checkout estava caindo devido a 4 segundos de latência e que, se não isolássemos o microsserviço de pagamentos agora, o próximo lançamento teria risco de indisponibilidade de 30% na Black Friday.”

3. “Como você age quando precisa de uma entrega de outra equipe, mas a tarefa não é prioridade para eles?”

• O que o RH avalia: Influência entre silos organizacionais e capacidade de negociação sem recorrer à hierarquia (não sair correndo para reclamar com o diretor).
• Como responder: Alinhamento de objetivos comuns, definição clara de contratos de interface (APIs/Mocks) para não bloquear o seu time e visibilidade transparente em reuniões conjuntas de planejamento.

---

Bloco 2: Incidentes em Produção, Falhas e Responsabilidade

4. “Me conte sobre o maior bug ou incidente em produção que você causou ou pelo qual foi responsável. O que você fez?”

• O que o RH avalia: Honestidade brutal, calma sob crise e cultura de Post-Mortem sem culpados (Blameless Post-Mortem).
• Como responder:
  • Assuma a falha com naturalidade: todo engenheiro experiente já derrubou algo em produção;
  • Descreva o processo em 3 tempos: 1. Mitigação imediata (reverter versão ou ativar circuit breaker), 2. Comunicação transparente com suporte e clientes, 3. Causa raiz e blindagem (novos testes automatizados, alarmes no CloudWatch ou mudança no pipeline de CI/CD para que o mesmo erro seja impossível de acontecer novamente).

5. “Descreva um projeto que falhou, atrasou drasticamente ou não atingiu os resultados esperados. Qual foi a sua postura?”

• O que o RH avalia: Resiliência e capacidade de autoanálise sem culpar terceiros.
• Como responder: Focar em quando você percebeu que o projeto estava descarrilando, como sinalizou o risco com antecedência para liderança e o que implementou nos projetos seguintes para evitar a mesma armadilha.

---

Bloco 3: Liderança, Mentoria e Cultura de Engenharia

6. “Como você lida com um desenvolvedor júnior ou pleno que entrega código com problemas recorrentes de qualidade ou que resiste a feedbacks em Code Reviews?”

• O que o RH avalia: Empatia pedagógica, paciência e habilidade de liderar sem desmotivar.
• Resposta Sênior:
  • Code review não é tribunal: o feedback deve focar no código, nunca na pessoa;
  • Sugerir alternativas com justificativas claras (“O que acha de usarmos um map aqui em vez de loop aninhado para reduzir a complexidade de $O(N^2)$ para $O(N)$?”);
  • Agendar sessões de Pair Programming para entender a raiz da dificuldade (falta de contexto de negócio, lacuna de conhecimento da stack ou problemas pessoais).

7. “Conte sobre alguém que você mentorou e viu crescer profissionalmente. Qual foi a sua contribuição ativa?”

• O que o RH avalia: Se você gera o Multiplier Effect (multiplicar o impacto da equipe) ou se é um “herói solitário” que centraliza todo o conhecimento.
• Como responder: Descreva um liderado ou colega específico, o plano de desenvolvimento que vocês traçaram juntos e a promoção ou autonomia conquistada por ele.

8. “O que você faz para disseminar boas práticas e elevar a barra de qualidade técnica em uma equipe?”

• O que o RH avalia: Criação de cultura duradoura (RFCs, Tech Talks internas, documentação de arquitetura, padrões de testes e lint automatizados no pipeline).

---

Bloco 4: Ambiguidade, Prazos e Tomada de Decisão

9. “Como você toma decisões técnicas importantes quando os requisitos são vagos ou incompletos e o prazo é curto?”

• O que o RH avalia: Autonomia e pragmatismo.
• Como responder: Criação de um Spike / Prova de Conceito (PoC) rápida de 2 a 3 dias, mapeamento explícito de suposições (assumptions) alinhadas por escrito com o time e adoção de arquiteturas modulares que permitam trocar componentes no futuro se os requisitos mudarem.

10. “Conte sobre uma situação em que você teve que escolher entre velocidade de entrega e perfeição arquitetural (Build vs Buy / MVP vs Solução Definitiva).”

• O que o RH avalia: Pragmatismo de engenharia. Engenheiros que querem construir sempre o “sistema perfeito que aguenta 1 bilhão de acessos” para um produto que ainda não tem 100 usuários geram prejuízo para a empresa.
• Como responder: Entregar uma solução enxuta que valide o produto no mercado rapidamente, documentando explicitamente os débitos técnicos aceitos como dívida consciente a ser quitada no ciclo seguinte.

11. “O que você faz quando percebe que o prazo acordado para uma entrega crítica não será cumprido?”

• O que o RH avalia: Comunicação antecipada de riscos.
• Resposta Sênior: Jamais esperar a véspera da entrega. Assim que o desvio for identificado (ex.: 2 semanas antes), comunicar o PM e a liderança com 3 opções claras:
  1. Reduzir o escopo não-essencial mantendo a data;
  2. Adicionar apoio técnico especializado na tarefa específica;
  3. Adiar a data com justificativa técnica embasada.

---

Bloco 5: Motivação, Fit Cultural e Carreira

12. “Por que você está querendo sair da sua empresa atual / buscando uma nova oportunidade?”

• O que o RH avalia: Profissionalismo e direcionamento de carreira.
• Regra de Ouro: Nunca fale mal da empresa atual, do chefe ou dos colegas. Fale sobre busca por novos desafios de escala, desejo de trabalhar com sistemas mais distribuídos, impacto em um produto global ou alinhamento com a cultura técnica da nova empresa.

13. “O que mais te frustra no dia a dia de trabalho em um time de engenharia e como você reage a isso?”

• O que o RH avalia: Maturidade contra desmotivação e capacidade de ser agente de mudança em vez de reclamante passivo.
• Como responder: Citar processos burocráticos ou falta de visibilidade de métricas, mostrando como você atuou ativamente para automatizar o processo ou introduzir ferramentas de observabilidade.

14. “Como você se mantém atualizado tecnologicamente diante do surgimento constante de novas ferramentas, frameworks e IA?”

• O que o RH avalia: Continuous Learning e curiosidade intelectual genuína (leitura de papers de sistemas distribuídos, projetos práticos open-source, uso pragmático de IA generativa no fluxo de trabalho).

---

Bloco 6: Comparação com Outros Candidatos e Diferencial Competitivo

Neste bloco, o entrevistador coloca você intencionalmente em confronto direto com os outros profissionais que estão concorrendo à mesma cadeira. O objetivo do RH não é saber se você “sabe programar”, mas descobrir qual é o seu valor único (Unique Selling Proposition) quando todos os currículos na mesa são tecnicamente qualificados.

15. “Temos vários candidatos seniores com o mesmo tempo de experiência e a mesma stack técnica que você. O que faz você ser a escolha certa e não eles?”

• O que o RH avalia: Se você sabe vender seu impacto além de “anos de experiência” e “lista de tecnologias”. Anos de experiência não garantem senioridade; capacidade de entrega e maturidade sim.
• A Armadilha: Falar clichês como “sou muito esforçado e tenho facilidade de aprender” (isso é o básico esperado até de um estagiário) ou desmerecer os outros concorrentes.
• A Resposta Sênior:
  • “Certamente vocês estão conversando com engenheiros muito competentes tecnicamente. O que me diferencia e traz segurança para a contratação de vocês se resume a três entregas concretas que trago desde o primeiro mês:
    1. Autonomia sem surpresas: Eu não preciso que alguém quebre os requisitos para mim. Pego problemas complexos e vagos, desenho a arquitetura, alinho os riscos com o time e entrego sem precisar de microgerenciamento;
    2. Visão de dono orientada a negócio: Não escrevo código por vaidade técnica. Antes de decidir por uma solução complexa, pergunto quanto ela custa na AWS, como impacta o cliente final e se traz retorno para a métrica de negócio da empresa;
    3. Efeito estabilizador no time: Em momentos de crise ou incidentes de produção, sou a pessoa que mantém a calma, foca em mitigação rápida sem apontar culpados e depois lidera a melhoria de processos para que a falha nunca mais se repita.”

16. “O que está no seu perfil ou na sua forma de trabalhar que nós definitivamente NÃO vamos encontrar na maioria dos outros candidatos na fila?”

• O que o RH avalia: Autoconhecimento agudo e o seu “superpoder profissional”.
• A Resposta Sênior:
  • “A maioria dos engenheiros seniores se divide em dois extremos: ou são ultra-técnicos que se isolam e têm dificuldade de falar com Produto e negócio, ou viraram generalistas que perderam a profundidade de código e infraestrutura.
  • O meu grande diferencial é ser a ponte fluida entre esses dois mundos: consigo sentar com o Product Manager para negociar escopo e métricas de conversão na mesma manhã em que sento com a equipe para debugar um gargalo de pool de conexões no PostgreSQL ou desenhar um pipeline de mensageria assíncrona. Essa capacidade de tradução reduz atritos e acelera o time inteiro.”

17. “Se outro candidato tiver mais anos de experiência em uma ferramenta específica do nosso dia a dia do que você, por que deveríamos optar por você?”

• O que o RH avalia: A diferença clássica entre dominar fundamentos de computação vs ser um mero “operador de framework”.
• A Resposta Sênior:
  • “Sintaxe e frameworks mudam o tempo todo; fundamentos de arquitetura e sistemas distribuídos não. Se alguém tem 8 anos em um framework específico e eu tenho 3, a diferença prática de entrega entre nós no dia a dia é marginal após as primeiras semanas.
  • O que eu trago são os fundamentos perenes: consistência de dados, prevenção de falhas em cascata, observabilidade, segurança e design patterns. Uma ferramenta específica eu assimilo com velocidade e profundidade em poucas semanas de imersão; o discernimento arquitetural de saber quando NÃO usar uma tecnologia complexa leva anos para ser construído.”

18. “Em um time com outros engenheiros seniores fortes, que papel você ocupa naturalmente frente aos seus pares?”

• O que o RH avalia: Fit de equipe e complementaridade de competências (se você vai disputar ego com os outros seniores ou somar forças).
• A Resposta Sênior:
  • “Não entro em uma equipe para disputar território ou provar que sei mais. Meu papel natural em times seniores costuma ser o de desbloqueador e articulador de consenso:
    • Quando há impasses técnicos entre duas soluções válidas, ajudo a puxar a decisão para critérios objetivos: benchmarks, custos e prazo de entrega;
    • Gosto de atuar como o guardião da resiliência: garanto que testes automatizados, esteiras de CI/CD e documentação viva não fiquem em segundo plano, aliviando a carga cognitiva de todos os engenheiros do time.”

19. “Se eu ligasse hoje para o seu gestor atual e para os desenvolvedores que trabalham com você e perguntasse: ‘Qual é o maior diferencial dele em relação aos outros seniores da empresa?’, o que eles diriam?”

• O que o RH avalia: Consistência da sua autoimagem com o seu histórico real de trabalho, preparando terreno para checagem de referências (backchannel reference).
• A Resposta Sênior:
  • “O meu gestor provavelmente diria que a maior vantagem de me ter no time é a previsibilidade e a tranquilidade: quando uma entrega crítica ou um problema espinhoso fica sob minha responsabilidade, ele sabe que será resolvido com alta qualidade e que, se houver qualquer risco de prazo ou bloqueio externo, ele será avisado com dias de antecedência, nunca na véspera.
  • Já os desenvolvedores do time diriam que sou alguém extremamente acessível para destravar problemas e mentorar: alguém que não faz code review punitivo, que compartilha contexto abertamente e que comemora as vitórias do time em vez de buscar os holofotes individuais.”

20. “Qual é o tipo de desafio técnico que você resolve com facilidade e que você percebe que a maioria dos outros seniores costuma evitar ou bater cabeça?”

• O que o RH avalia: Se você tem coragem para lidar com o “trabalho sujo de engenharia” (engineering toil, débito técnico, legados e problemas de ambiente real).
• A Resposta Sênior:
  • “Muitos desenvolvedores só gostam de criar microsserviços novos do zero em bases limpas (greenfield). Onde eu costumo me destacar frente aos meus pares é na habilidade de estabilizar sistemas legados e conduzir migrações complexas sem downtime.
  • Gosto de pegar sistemas com problemas de concorrência, queries lentas, falta de observabilidade e dependências frágeis, desenhar a estratégia de estrangulamento gradual (Strangler Fig Pattern ou Expand and Contract) e transformar um ambiente caótico em um serviço estável e monitorável sem que o usuário final perceba qualquer interrupção.”

---

Bloco 7: Outros Processos Seletivos e Tomada de Decisão

21. “Você está participando de outros processos seletivos no momento? Em que estágio você está?”

• O que o RH avalia: Nível de demanda do candidato no mercado, urgência do processo seletivo (timeline) e se você está disparando currículos aleatoriamente ou escolhendo empresas a dedo.
• A Armadilha: Dizer “Não, estou conversando só com vocês” (passa sinal de baixa atratividade no mercado) ou inventar ofertas falsas para pressionar (o RH descobre facilmente e você perde a credibilidade).
• A Resposta Sênior: Demonstrar que você é um profissional cobiçado, mas que tem critério nas escolhas:
  • “Sim, estou em conversas com outras duas empresas com desafios similares de escala em nuvem / microsserviços. Em uma delas estou aguardando a etapa final com o diretor de engenharia. No entanto, tenho sido muito seletivo: a proposta de valor e a maturidade de engenharia de vocês são a minha prioridade número 1 por causa do desafio [citar um projeto ou produto específico da empresa]. Se avançarmos para proposta, meu alinhamento com vocês está em primeiro lugar.”
  • Efeito prático: Isso acende o sinal de urgência no RH para acelerar suas entrevistas e fazer uma oferta financeira mais agressiva e competitiva.

22. “Se você receber uma oferta nossa e uma oferta de uma empresa concorrente com remuneração parecida, quais critérios você usará para decidir?”

• O que o RH avalia: Quais são seus motivadores reais de carreira (autonomia, cultura, desafio técnico, equilíbrio de vida, impacto do produto) e se você aceitará a oferta ou usará apenas como leilão salarial.
• A Resposta Sênior:
  • “Para valores financeiros equivalentes, meus critérios de desempate são três:
    1. Escopo de impacto técnico: onde terei maior liberdade para desenhar soluções arquiteturais desafiadoras e resolver gargalos reais de escala;
    2. Cultura de engenharia: valorizo times com foco em excelência técnica, código limpo, CI/CD automatizado e cultura de post-mortem sem caça às bruxas;
    3. A equipe: a sintonia que senti com os líderes técnicos e com o time durante o processo de entrevistas.”

23. “Como você avalia o produto da nossa empresa em comparação aos nossos principais concorrentes de mercado?”

• O que o RH avalia: Se você fez o dever de casa antes da entrevista. Candidatos medianos não sabem o que a empresa faz além do texto da vaga; candidatos seniores entendem o mercado, os diferenciais e os gargalos competitivos.
• A Resposta Sênior:
  • Demonstre que você usou o produto ou pesquisou as principais vantagens e pontos fracos frente à concorrência;
  • Aponte uma oportunidade técnica de melhoria com postura construtiva: “Percebo que enquanto o Concorrente X foca em volume, o produto de vocês se destaca pela estabilidade da API e facilidade de integração. No entanto, vejo que uma área onde podemos nos distanciar ainda mais deles é na experiência de onboarding de desenvolvedores e na latência de sincronização de dados…”

---

24. “Você tem alguma pergunta para nós?” (A Pergunta Final Obrigatória)

• O que o RH avalia: Candidato que não faz perguntas demonstra desinteresse ou falta de critério de seleção.
• Perguntas de Alto Nível que Impressionam o RH:
  • “Como vocês medem o sucesso de um engenheiro sênior nos primeiros 90 dias?”
  • “Qual é o maior gargalo técnico ou organizacional que o time de engenharia está enfrentando atualmente?”
  • “Como funciona a relação entre Engenharia e Produto aqui: o time de tecnologia é parceiro estratégico na definição do produto ou apenas executor de backlog?”
  • “Como é a cultura de post-mortem e erros de vocês quando ocorre um incidente de produção?”

---

🚩 Red Flags que Eliminam Candidatos Seniores no RH

respostas

Esta parte traz o lado de quem responde. Para cada pergunta, o que o entrevistador busca, como pensar a resposta e as perguntas de follow-up mais prováveis. Os números que aparecem em exemplos de frase, como uma queda de 30% na Black Friday, são ilustrativos e não fatos de ninguém.

As perguntas estão em sete blocos. O bloco 1 trata de conflitos técnicos e influência, o bloco 2 de incidentes e falhas, o bloco 3 de liderança e mentoria, o bloco 4 de ambiguidade e prazo, o bloco 5 de motivação e carreira, o bloco 6 de diferencial frente a outros candidatos e o bloco 7 de processos paralelos e critérios de decisão. Ao fim estão as perguntas que você deve fazer ao entrevistador e uma tabela de red flags com a postura correta para cada uma.

Bloco 1: conflitos técnicos e influência

1. discordância técnica com sênior ou arquiteto

“Conte sobre uma vez em que você discordou fortemente da abordagem técnica de outro engenheiro sênior ou arquiteto. Como você lidou com isso?”

O entrevistador quer saber se você consegue divergir sem transformar a divergência em conflito pessoal e se consegue ceder quando o grupo decide diferente. Ele procura maturidade, não um vencedor de debate.

A armadilha desta pergunta é contar uma história em que você tinha razão e o outro estava errado. O recrutador ouve isso e pensa no que acontece na próxima discordância com você. Uma boa resposta mostra três coisas: você levou a divergência para critérios objetivos (um protótipo, uma medição, uma estimativa de custo), tratou o outro como alguém com contexto válido e, se a decisão foi contra a sua proposta, executou sem boicote. Na estrutura STAR-L, a situação deve caber em duas frases. A tarefa precisa deixar claro qual era a sua responsabilidade, por exemplo ser o dono do módulo afetado ou o revisor técnico escolhido. A ação concentra o que você fez para testar a sua hipótese. O resultado é a decisão final e o que aconteceu depois. A lição mostra o que mudou na sua forma de discordar. Cuidado com o “nós” usado para esconder a sua parte: diga “eu propus”, “eu testei”, “eu defendi”. Evite também caricaturar o outro, porque isso denuncia imaturidade mais rápido que qualquer frase.

Não diga que estava certo e que o outro não entendia. Não critique a pessoa, nem a equipe. Não cite métrica de desempenho que você não mediu.

Follow-up provável: “E se a evidência não tivesse aparecido?” Responda que a decisão seria tomada por consenso e com o risco registrado por escrito, e que essa era a regra que você aceitaria. Outro follow-up comum é o nome do colega. Não dê o nome. Descreva o papel dele (“o arquiteto do módulo”) sem julgamento.

2. convencer o PM a adiar feature para pagar débito técnico

“Como você convence um Product Manager ou stakeholder de negócio a adiar uma feature para pagar débito técnico?”

O entrevistador quer saber se você consegue traduzir um problema técnico em linguagem de risco e de custo que o negócio entende. Ele também observa se você apresenta opções ou se apenas pede tempo.

Débito técnico é um termo que o PM pode ouvir como “o time quer refatorar por vaidade”. A resposta forte tira o termo do centro e coloca o efeito no cliente, no prazo e no custo de adiar. A sequência que funciona é: qual área de negócio sofre com o problema, o que você mediu ou observou (tempo de resposta, chamados de suporte, retrabalho, incidentes), quais opções você apresentou com o custo de cada uma, e o que foi decidido. Repare que a pergunta pede “convencer”, mas o que o recrutador avalia é a qualidade da conversa. Um PM convencido porque você apresentou três caminhos com prós e contras é a resposta que se quer ouvir. Um PM que cedeu porque você insistiu não serve de exemplo.

Não diga “o código está feio e precisa de refatoração”. Não prometa um número de conversão ou de receita sem ter a medição. Se você não mediu nada, descreva o risco em termos de cenário, por exemplo “um módulo que todo release precisava tocar”, e diga que não havia número.

Follow-up provável: “Você tem números?” Se não tiver, responda sem constrangimento: “Não medi na época. O que eu tenho é o cenário e a decisão, e hoje eu meço antes de propor.” Só use essa frase se ela for verdade.

3. entrega de outra equipe que não é prioridade para ela

“Como você age quando precisa de uma entrega de outra equipe, mas a tarefa não é prioridade para eles?”

O entrevistador avalia se você consegue influenciar sem autoridade formal e sem recorrer à hierarquia. Quem sobe a reclamação para o diretor na primeira semana de atraso mostra que não tem confiança na própria capacidade de negociação.

A resposta boa começa pelo objetivo comum. Antes de cobrar, você descobre o que faz a outra equipe funcionar e por que a sua entrega ficou de fora da prioridade dela. Muitas vezes a solução é reduzir a dependência: definir um contrato de interface (um schema, um mock ou uma API combinada) para que o seu time avance enquanto o outro entrega. Por fim, a visibilidade: você leva o pedido para a reunião de planejamento conjunta, com o impacto escrito, e não para um canal privado. Em STAR-L, a situação mostra a dependência, a tarefa mostra o seu papel no resultado, a ação descreve a conversa e o contrato, o resultado é o desfecho do prazo e a lição é o que você passou a combinar antes.

Não diga que foi ao gestor reclamar. Não diga que a outra equipe “não ligava”. Não descreva o colega como obstáculo.

Follow-up provável: “E se o outro time continuasse sem prioridade?” Responda com a escalada como último recurso, feita com dados e com o gestor dos dois times juntos. Essa é a resposta que mostra maturidade.

Bloco 2: incidentes em produção, falhas e responsabilidade

4. maior incidente em produção que você causou ou foi responsável

“Me conte sobre o maior bug ou incidente em produção que você causou ou pelo qual foi responsável. O que você fez?”

O entrevistador quer ver honestidade e calma. Ele também quer saber se você conhece a cultura de post-mortem sem culpados (blameless post-mortem), na qual o objetivo é entender o sistema e não encontrar quem apertou o botão. Quem diz que nunca causou um incidente grave ou não tem experiência ou não é honesto, e os dois sinais pesam contra.

A resposta organiza o caso em três tempos. Primeiro, a mitigação imediata: o que você fez para parar o dano, como reverter o deploy, desligar uma feature com flag ou abrir um circuit breaker. Segundo, a comunicação: com quem você falou, em que canal, com que frequência e o que disse sobre o impacto, sem maquiá-lo. Terceiro, a causa raiz e a blindagem: o teste que faltava, o alarme que não existia, a mudança no pipeline de CI/CD que impede o mesmo erro. Em STAR-L, a situação descreve o sistema e o impacto, a tarefa deixa claro o que era sua responsabilidade, a ação é a sequência dos três tempos, o resultado é o tempo de recuperação e o que mudou, e a lição é a prática que você adotou depois. Se o tempo de recuperação não foi registrado, diga que não foi medido e descreva a ordem dos fatos.

Não diga que a culpa foi da infraestrutura, do time de QA ou da documentação. Não minimize o impacto para parecer confiável. Não invente um incidente dramático só para responder.

Follow-up provável: “Quanto tempo ficou fora?” Se você não sabe, diga que não tem o número registrado e explique como o tempo era acompanhado na época. Se a pergunta for sobre quem causou, responda que o foco foi no processo que deixou o erro passar.

5. projeto que falhou, atrasou ou não atingiu o esperado

“Descreva um projeto que falhou, atrasou drasticamente ou não atingiu os resultados esperados. Qual foi a sua postura?”

O entrevistador quer ver se você consegue fazer uma autoanálise honesta. A pergunta não pede um projeto que deu certo com um pequeno ajuste. Ela pede um projeto em que você percebeu o problema, comunicou e mudou alguma coisa. Ela separa quem conhece os próprios sinais de alarme de quem só descobre o problema quando ele já está na mesa do diretor.

Uma resposta forte tem um momento claro em que você percebeu que o projeto estava saindo do trilho: uma estimativa que não fechava, um requisito que mudava toda semana, uma dependência que não respondia. Depois, mostre como você sinalizou o risco com antecedência e com opções, não com lamento. Por fim, diga o que fez nos projetos seguintes para não repetir a armadilha. Em STAR-L, a situação descreve o projeto e o resultado frustrado, a tarefa diz o que era seu, a ação mostra o sinal percebido e a comunicação, o resultado é o desfecho real (inclusive se foi parcial) e a lição é a mudança concreta na sua prática.

Não culpe o PM, a empresa ou a falta de verba. Não escolha um projeto que deu errado por um motivo que você não controlava e apresente como se fosse falha sua, nem o contrário.

Follow-up provável: “Você faria igual de novo?” Responda com o que mudaria e por quê. Quem diz que faria exatamente igual mostra pouca autocrítica.

Bloco 3: liderança, mentoria e cultura de engenharia

6. júnior ou pleno com problemas recorrentes de qualidade ou que resiste a feedback

“Como você lida com um desenvolvedor júnior ou pleno que entrega código com problemas recorrentes de qualidade ou que resiste a feedbacks em Code Reviews?”

O entrevistador quer saber se você tem empatia pedagógica e se consegue corrigir sem desmotivar. A pergunta também testa se você entende que a dificuldade de uma pessoa raramente é só técnica. Ela pode ser falta de contexto de negócio, lacuna na stack ou um problema fora do trabalho.

A boa resposta separa o código da pessoa. Um code review que aponta “esse loop aninhado” é útil, e um que diz “você sempre faz isso errado” não é. Sugira alternativas com a justificativa: se o problema é complexidade, mostre a troca de uma estrutura por outra e o que ela muda na leitura e no custo de execução. Quando o problema persiste, o passo seguinte é uma conversa fora do review e, se preciso, uma sessão de pair programming para entender onde o gargalo está. Em STAR-L, a situação descreve o padrão de problema, a tarefa mostra o seu papel como revisor ou colega mais experiente, a ação é o feedback e a conversa, o resultado é a evolução observada (com cuidado para não exagerar) e a lição é o que você mudou no jeito de dar feedback.

Não diga que a pessoa “não tinha capacidade”. Não cite o nome dela. Não descreva a conversa como se fosse um confronto.

Follow-up provável: “E se ele continuasse sem melhorar?” Responda que a conversa passa para o gestor com exemplos concretos e um plano combinado, e que o foco continua sendo o trabalho, não a pessoa.

7. alguém que você mentorou e viu crescer

“Conte sobre alguém que você mentorou e viu crescer profissionalmente. Qual foi a sua contribuição ativa?”

O entrevistador quer saber se você multiplica o time ou se é um herói que centraliza o conhecimento. A pergunta exige um caso específico com uma pessoa, um plano e um desfecho. Sem nome, sem plano e sem desfecho, a resposta vira uma declaração de intenção.

A resposta forte tem começo, meio e fim. O começo é o ponto de partida da pessoa e a lacuna que você percebeu. O meio é o plano que vocês combinaram, com tarefas, pares de revisão, leituras e a autonomia que foi sendo dada. O fim é o que ela conseguiu fazer sozinha, e aqui você pode mencionar uma promoção ou um papel novo apenas se for verdade e se a pessoa autorizar a menção. Em STAR-L, a situação descreve a pessoa em termos de nível e de contexto, sem expor vida pessoal, a tarefa é o papel que você assumiu, a ação é o plano concreto, o resultado é a autonomia conquistada e a lição é o que você aprendeu sobre orientar.

Não cite o nome sem autorização. Não invente uma trajetória de promoção. Não diga que “ensinou tudo” a alguém, porque isso sugere que você não deixou a pessoa decidir.

Follow-up provável: “O que você faria diferente?” Responda com algo real sobre o processo, como ter combinado metas antes de começar a revisar, e não com uma falsa autocrítica.

8. disseminar boas práticas e elevar a barra técnica

“O que você faz para disseminar boas práticas e elevar a barra de qualidade técnica em uma equipe?”

O entrevistador quer saber se você cria cultura que sobrevive à sua presença no time. Ele procura práticas que outras pessoas usam sem você: documentação de decisões, padrões de teste, lint no pipeline, rituais de compartilhamento. Responder com “eu sempre dou exemplo” é a versão mais fraca de todas, porque exemplo não é sistema.

A resposta boa lista poucas práticas, cada uma com o motivo de existir e o que ela resolveu. Comece pela que você realmente fez. Depois explique como ela ficou no processo do time (um checklist de review, uma regra de lint, um template de documentação) e, se houve, como o time adotou. Se você participa de uma liga ou comunidade interna, a participação é um canal de disseminação e pode ser descrita com o que você levou de lá para o time. Em STAR-L, a situação mostra a lacuna de qualidade, a tarefa é a sua contribuição, a ação é a prática criada, o resultado é a adoção e o efeito observado, e a lição é o que você faria para a prática sobreviver sem você.

Não cite uma lista de ferramentas da moda como se fosse cultura. Não diga que escreveu RFCs ou palestras se não escreveu. Não invente adoção.

Bloco 4: ambiguidade, prazos e tomada de decisão

Este bloco mede pragmatismo. O entrevistador quer saber se você consegue andar com informação incompleta sem parar o trabalho e sem fingir que a incerteza não existe. Em todas as três perguntas, a diferença entre um sênior e um pleno aparece na forma de registrar suposições e de comunicar riscos cedo.

9. decisão técnica com requisitos vagos e prazo curto

“Como você toma decisões técnicas importantes quando os requisitos são vagos ou incompletos e o prazo é curto?”

O entrevistador quer autonomia e pragmatismo. Ele quer ver que você não espera o requisito perfeito para começar e também não passa semanas construindo uma arquitetura para um problema que ainda não está claro.

A resposta forte tem três movimentos. Primeiro, você reduz a incerteza com um spike ou uma prova de conceito curta, de dois a três dias, com uma pergunta clara a responder. Segundo, você escreve as suposições (assumptions) e as alinha com o time e com quem define o produto, por escrito, para que a suposição errada apareça cedo. Terceiro, você escolhe uma arquitetura que permita trocar uma parte quando o requisito mudar, por exemplo isolando a integração externa atrás de uma interface. Em STAR-L, a situação descreve a ambiguidade e o prazo, a tarefa é a decisão que era sua, a ação mostra o spike, as suposições e a escolha de isolamento, o resultado é o que o spike revelou e o que aconteceu com os requisitos depois, e a lição é a regra que você passou a usar. Se o spike mudou a decisão, diga isso, porque mostra que você não estava defendendo a primeira ideia.

Não diga “eu decidi sozinho” sem mencionar quem validou as suposições. Não diga que sempre espera o requisito fechar. Não diga que fez tudo “do jeito certo” sem mostrar o que foi descartado.

Follow-up provável: “E se o spike falhasse?” Responda que o resultado negativo também é informação e que o time seguiria com a alternativa seguinte, registrada na mesma nota de suposições.

10. velocidade de entrega ou perfeição arquitetural

“Conte sobre uma situação em que você teve que escolher entre velocidade de entrega e perfeição arquitetural (Build vs Buy / MVP vs Solução Definitiva).”

O entrevistador quer saber se você entende que engenharia existe para sustentar um negócio e não para satisfazer uma ideia de sistema perfeito. Quem sempre quer a solução definitiva para um produto sem usuários gera prejuízo, e quem sempre entrega o atalho gera dívida que ninguém paga. A pergunta procura o equilíbrio.

A resposta forte mostra que você escolheu a solução enxuta com um critério claro (o que precisava validar, quanto tempo havia, quem dependia daquilo) e que documentou a dívida aceita. Dívida consciente é a expressão que resume o ponto: você sabe o que deixou de fazer, por que deixou e quando pretende pagar. Em STAR-L, a situação descreve o trade-off, a tarefa mostra a sua decisão, a ação é a solução enxuta e o registro da dívida, o resultado é o que o produto validou ou a pagamento da dívida no ciclo seguinte, e a lição é o critério que você usa para decidir de novo. Se a dívida nunca foi paga, diga isso com franqueza, porque é um fato que o entrevistador pode checar.

Não diga que a solução perfeita sempre foi a sua escolha. Não diga que o atalho nunca causou problema. Não compare o que você fez com “o que a concorrência faria” sem ter dados.

Follow-up provável: “Se o produto tivesse dado certo, você teria refeito tudo?” Responda com o que seria refeito e o que seria mantido, mostrando que você pensa em evolução e não em reescrita total.

11. prazo crítico que não será cumprido

“O que você faz quando percebe que o prazo acordado para uma entrega crítica não será cumprido?”

O entrevistador avalia a comunicação antecipada. A resposta certa nunca é “esperei a véspera para avisar”. Quem percebe o desvio duas semanas antes e chega com opções claras é o tipo de pessoa que o gestor quer ter perto de um projeto importante.

A resposta boa segue um roteiro simples: você identifica o desvio com dados (o que foi entregue, o que falta, o que a estimativa mostra), comunica ao PM e à liderança com antecedência e apresenta três caminhos. O primeiro é reduzir o escopo não essencial e manter a data. O segundo é pedir apoio técnico especializado para a parte crítica. O terceiro é adiar com justificativa técnica. Em STAR-L, a situação mostra o prazo e o risco, a tarefa diz qual era o seu papel na entrega, a ação é a comunicação e as opções, o resultado é a decisão e o desfecho, e a lição é o gatilho de alerta que você passou a usar (por exemplo, um marco intermediário que dispara a conversa).

Não diga que escondeu o atraso para não preocupar ninguém. Não culpe a estimativa de outra pessoa. Não diga que “deu tudo certo” se a data foi cumprida com horas extras não combinadas, porque isso passa a impressão de que o processo depende de heroísmo.

Bloco 5: motivação, fit cultural e carreira

12. por que está buscando uma nova oportunidade

“Por que você está querendo sair da sua empresa atual / buscando uma nova oportunidade?”

O entrevistador quer saber se você tem direção e se a sua saída tem motivo que não seja fuga. A regra de ouro, que vale em qualquer roteiro, é nunca falar mal da empresa atual, do gestor ou dos colegas. A pergunta é sobre o que você busca, não sobre o que falta onde está.

Uma resposta boa parte do que você já fez e vai para o que quer fazer. Quatro projetos em sequência dão uma história de adaptação a contextos diferentes, e a próxima etapa é aprofundar uma direção. Se a vaga for de back-end em Go, diga que quer ir mais fundo em serviços. Se for de front-end em escala, diga isso. Não é necessário mencionar outros países ou planos de imigração. Se o entrevistador perguntar sobre mobilidade internacional, a decisão de falar é sua. A frase “busco um mercado internacional” é verdadeira e não compromete nada.

Não diga que a empresa atual não oferece desafio, nem que o projeto ficou ruim. Não mencione salário como motivação principal.

Follow-up provável: “Você tem processo aberto em outra empresa?” Vá para o bloco 7, pergunta 21. Follow-up sobre salário: responda que a conversa sobre remuneração é natural em etapa avançada e que você tem critérios além dela.

13. o que mais frustra no dia a dia e como você reage

“O que mais te frustra no dia a dia de trabalho em um time de engenharia e como você reage a isso?”

O entrevistador avalia se você é agente de mudança ou reclamante passivo. Toda equipe tem atrito, e a pergunta não quer que você diga que não tem frustração. Ela quer uma frustração real, específica, e uma ação que você tomou para mudá-la.

Não diga que o gestor não ouve. Não diga que a empresa é burocrática, porque o entrevistador vai ouvir isso como aviso sobre a empresa dele. Não escolha uma frustração que seja um colega específico.

Follow-up provável: “E quando a mudança que você propõe não é aceita?” Responda que você testa a proposta em escala pequena, com dados, e aceita a decisão do time quando ela vem com justificativa.

14. como se mantém atualizado com novas ferramentas, frameworks e IA

“Como você se mantém atualizado tecnologicamente diante do surgimento constante de novas ferramentas, frameworks e IA?”

O entrevistador quer curiosidade intelectual genuína e um método. Ele não quer uma lista de cursos feitos. Quer saber como você decide o que aprender e como usa o que aprendeu. A resposta que se destaca separa o que é perene (fundamentos, arquitetura, dados, sistemas distribuídos) do que é passageiro (a ferramenta da semana) e mostra a sua escolha para cada um.

Não liste cursos como se fossem aprendizado sem aplicação. Não diga que lê tudo sobre tecnologia. Não diga que “a IA vai fazer tudo”, porque isso soa como ingenuidade.

Follow-up provável: “Qual foi a última coisa nova que você aprendeu?” Tenha uma resposta concreta e recente, com o que fez com ela.

Bloco 6: comparação com outros candidatos e diferencial

Neste bloco o entrevistador quer saber qual é o seu valor quando o currículo na mesa é parecido com o de outros candidatos. Ele não pergunta se você sabe programar, pergunta o que você entrega que os outros talvez não entreguem. Por isso a regra é a mesma para as seis perguntas: cada diferencial que você afirma precisa de um caso que o sustente. Afirmação sem caso vira clichê, e o clichê da pergunta 15, “sou esforçado e aprendo rápido”, é justamente o que o entrevistador já espera de qualquer um.

15. o que faz você ser a escolha certa entre candidatos parecidos

“Temos vários candidatos seniores com o mesmo tempo de experiência e a mesma stack técnica que você. O que faz você ser a escolha certa e não eles?”

O entrevistador quer saber se você consegue vender impacto além de anos de experiência e de lista de tecnologias. A armadilha é desmerecer os concorrentes, e a segunda armadilha é recitar clichês. Você não precisa dizer que os outros são piores. Precisa mostrar três coisas que você traz e que pode provar.

Um caminho honesto é organizar a resposta em torno de três pontos concretos. O primeiro é autonomia com problemas vagos: você pega uma necessidade mal definida, desenha a solução e alinha os riscos sem depender de alguém que quebre o requisito para você. O segundo é visão de negócio: você pergunta o custo e o efeito para o cliente antes de escolher uma solução complexa. O terceiro é a combinação de frentes que você tem, já que trabalhou com front-end em React e TypeScript e também com serviços em Go, o que permite conversar com produto e com a arquitetura na mesma semana. Cada um desses pontos precisa de um caso seu. Se você não tem o caso, não use o ponto.

Não diga “sou muito esforçado” nem “aprendo rápido”. Não diga que os outros candidatos são menos preparados.

Follow-up provável: “Dê um exemplo do primeiro ponto.” Use o caso de ambiguidade do bloco 4 (pergunta 9).

16. o que você tem que não se encontra na maioria dos candidatos

“O que está no seu perfil ou na sua forma de trabalhar que nós definitivamente NÃO vamos encontrar na maioria dos outros candidatos na fila?”

O entrevistador quer autoconhecimento e o seu superpoder profissional. A resposta precisa ser específica e não pode ser uma frase que serve a qualquer pessoa. O risco é cair em “sou ponte entre negócio e técnica”, que todo sênior diz.

Não diga que é “um generalista de coração”. Não diga que é ultra-técnico se a sua força é a ponte. Não invente um superpoder que não aparece no seu histórico.

Follow-up provável: “Você está confortável com back-end?” Seja direto: Go você usou em projeto real e estudou na pós; Java e C# não são o seu foco, e isso deve ser dito sem rodeio se a vaga depender deles.

17. outro candidato tem mais anos em uma ferramenta específica

“Se outro candidato tiver mais anos de experiência em uma ferramenta específica do nosso dia a dia do que você, por que deveríamos optar por você?”

O entrevistador quer saber se você domina fundamentos ou se é só operador de framework. Essa é uma pergunta em que o candidato com menos anos precisa reconhecer a diferença sem se diminuir. A resposta defende que fundamentos (consistência, falhas em cascata, observabilidade, segurança, padrões de projeto) duram mais que a ferramenta, e que a ferramenta específica se aprende em semanas de imersão.

Não diga que os anos de experiência não importam. Não diga que a ferramenta é ruim.

Follow-up provável: “Qual ferramenta você ainda não domina?” Responda com a verdade e com o que faria para chegar lá, sem exagerar.

18. que papel você ocupa entre outros seniores fortes

“Em um time com outros engenheiros seniores fortes, que papel você ocupa naturalmente frente aos seus pares?”

O entrevistador avalia o encaixe e se você disputa território ou soma. A resposta que funciona descreve um papel de articulação, e não de dono do conhecimento. O risco é soar como quem quer ser o árbitro de tudo.

Não diga que vai liderar os outros seniores. Não diga que é o mais experiente da sala se não for.

Follow-up provável: “E se você discordar do sênior do time?” Use a resposta do bloco 1, pergunta 1.

19. o que seu gestor e seus colegas diriam sobre o seu diferencial

“Se eu ligasse hoje para o seu gestor atual e para os desenvolvedores que trabalham com você e perguntasse: ‘Qual é o maior diferencial dele em relação aos outros seniores da empresa?’, o que eles diriam?”

O entrevistador prepara uma checagem de referência (backchannel). Ele quer saber se a sua autoimagem bate com o que as pessoas dizem de você. Por isso, a resposta não deve prometer o que os outros vão dizer. Você não sabe o que eles vão falar, e a sua resposta pode ser desmentida na primeira ligação.

A forma segura é descrever o que você faz e deixar que as referências confirmem. Diga o que você acredita ser o seu diferencial com base em casos, e sugira que o entrevistador pergunte às referências. Antes da entrevista, converse com um ex-gestor ou um colega de confiança e pergunte, com franqueza, qual é a característica que ele associa a você. Use a frase dele, se ela bater com a sua, e diga que foi isso que ele apontou.

Não escreva o que o gestor “diria” sem tê-lo consultado. Não escolha como referência alguém que não tenha trabalhado de perto com você.

Follow-up provável: “Você sabe o que eles falariam de ruim?” Responda com uma fraqueza real e o que está fazendo para melhorar. Não diga que não há nada.

20. desafio técnico que você resolve e que a maioria evita

“Qual é o tipo de desafio técnico que você resolve com facilidade e que você percebe que a maioria dos outros seniores costuma evitar ou bater cabeça?”

O entrevistador quer saber se você tem coragem para o trabalho sujo da engenharia: legado, débito, dependências frágeis, ambiente real. Muitos seniores preferem greenfield. A pergunta procura quem não tem medo de mexer no que já está em produção.

Não diga que legado é fácil. Não diga que reescreveria tudo do zero. Não descreva um desafio que você não resolveu de fato.

Follow-up provável: “Como você decide o que refatorar primeiro?” Responda com o critério de risco e de frequência de mudança, com um caso.

Bloco 7: outros processos seletivos e tomada de decisão

Estas perguntas tratam de fatos que só você conhece. A regra é uma só: não afirme processo que não existe, nem oferta que não recebeu. O entrevistador costuma checar, e a credibilidade perdida numa mentira dessas não volta na mesma etapa. Responda com o que é verdade hoje, mesmo que a verdade seja menos vistosa, porque ela também mostra critério.

21. você está participando de outros processos seletivos?

“Você está participando de outros processos seletivos no momento? Em que estágio você está?”

O entrevistador quer saber o seu nível de demanda, a urgência do seu processo e se você se candidata a qualquer vaga ou escolhe com critério. Ele não está pedindo nomes de empresas. Não é obrigatório citar nomes, e é normal não dar detalhes de processos de terceiros.

Se você tem processos em andamento, o caminho é dizer o número e o estágio sem os nomes, e explicar o critério de escolha. Se você não tem processo em andamento, a resposta honesta é outra, e ela não é fraca: você está avaliando oportunidades com critério e quer entender bem a vaga antes de avançar. A Armadilha que o arquivo de origem descreve é dizer “não, estou conversando só com vocês” sem nenhuma outra informação, porque isso passa a impressão de baixa procura. Por isso, a frase deve trazer o que você busca. Nunca invente oferta para pressionar.

Resposta pronta, se você tiver processos abertos: “Estou em [CONFIRMAR: número] conversas em estágio [CONFIRMAR: estágio]. Sou seletivo: busco um desafio em engenharia de produto com [CONFIRMAR: o que você busca], e este é um dos que mais se encaixam nisso.”

Resposta pronta, se não tiver processos abertos: “Estou avaliando oportunidades com critério. Quero um próximo passo que me dê [CONFIRMAR: o que você busca], e a vaga de vocês é uma das que eu quero entender melhor antes de avançar.”

Follow-up provável: “Você tem oferta?” Só responda sim se tiver. Se não tiver, diga que não.

22. critérios para escolher entre duas ofertas parecidas

“Se você receber uma oferta nossa e uma oferta de uma empresa concorrente com remuneração parecida, quais critérios você usará para decidir?”

O entrevistador quer saber o que motiva você de verdade: autonomia, cultura, desafio técnico, equilíbrio, impacto do produto. Ele também quer saber se você aceitaria a oferta ou usaria a outra como leilão de salário. A resposta precisa ser clara e não pode fingir que a remuneração não importa.

Os critérios sugeridos no arquivo de origem funcionam: escopo de impacto técnico, cultura de engenharia e a sintonia com o time durante o processo. Para você, eles podem ganhar um conteúdo específico. Escopo técnico pode ser um problema de arquitetura que você quer resolver, como serviços em Go com responsabilidade de desenho, ou front-end em escala com design system. Cultura pode ser code review sem punição, post-mortem sem caça às bruxas e pipeline automatizado. Time pode ser a conversa que você teve com os líderes técnicos. Conclua dizendo que você decide pelo conjunto e que a remuneração entra como um dos critérios, sem ser o único.

Não diga que decide só pelo dinheiro. Não diga que a outra oferta é melhor sem explicar em quê. Não use o nome da outra empresa como argumento de negociação antes de ter a oferta por escrito.

Resposta pronta: “Com remuneração parecida, eu decido por três critérios. Primeiro, o escopo técnico, ou seja, onde eu tenho liberdade para desenhar solução em problema real de escala. Segundo, a cultura de engenharia, com code review sem punição, pipeline automatizado e post-mortem sem caça às bruxas. Terceiro, a sintonia com o time que vai me receber, que eu avalio pelas conversas do processo.”

Follow-up provável: “Você negociaria?” Responda que sim, com um pedido concreto e justificado, e que você negocia o pacote inteiro, não só o número.

23. como você avalia o nosso produto frente aos concorrentes

“Como você avalia o produto da nossa empresa em comparação aos nossos principais concorrentes de mercado?”

O entrevistador quer saber se você fez o dever de casa. Candidato mediano repete o texto da vaga, candidato sênior entende o mercado e aponta um gargalo com postura construtiva. A pergunta também exige honestidade: se você não usou o produto, diga isso e fale a partir do que pesquisou.

A resposta forte tem três partes. Primeiro, o que você conhece do produto, com fonte: a documentação pública, a experiência de uso, um post técnico. Segundo, uma comparação concreta com os concorrentes citados no site ou no material da empresa, falando de diferenciais que você pode sustentar, como estabilidade da API ou facilidade de integração, se for o caso. Terceiro, uma oportunidade técnica formulada como pergunta ou como hipótese, não como crítica. Antes da entrevista, preencha as lacunas com a pesquisa que você fizer, porque esta resposta não pode ser escrita de memória.

Não diga que o produto é melhor que todos sem evidência. Não critique o produto com dureza. Não finja que usou se não usou.

Follow-up provável: “Você usaria o nosso produto?” Responda com a verdade e com o que faria para testar na prática.

24. você tem alguma pergunta para nós?

“Você tem alguma pergunta para nós?”

Esta pergunta é obrigatória e quase sempre aparece no fim. Ter perguntas prontas mostra interesse e critério. A lista completa está na seção “Perguntas para fazer ao entrevistador”, logo abaixo. Escolha duas ou três, adequadas ao que já foi conversado, e não use todas. Se as respostas da entrevista já responderam uma pergunta, não a repita, porque isso mostra falta de atenção.

Follow-up provável: “Tem mais alguma coisa que queira saber?” Pergunte o que ainda está em aberto sobre o processo, como o formato das próximas etapas.

Perguntas para fazer ao entrevistador

A pergunta 24 só funciona se as suas perguntas forem específicas. As do arquivo de origem são boas, e vale usá-las com a sua voz. A ideia por trás de todas é a mesma: descobrir como a empresa realmente funciona, e não como ela se apresenta no site. Uma boa pergunta mostra que você já pensa como quem trabalharia lá.

Red flags que eliminam candidatos seniores no RH

O arquivo de origem lista cinco comportamentos que pesam contra. A tabela abaixo mantém cada um e acrescenta a postura que você deve adotar na entrevista.