Como Contratar Desenvolvedor Sênior:
O Processo Que Funciona

O erro mais caro no recrutamento de devs

Contratar a pessoa errada para uma posição sênior custa em média 6 meses de salário quando você inclui o tempo do time em entrevistas, o onboarding, o trabalho perdido na saída e o recrutamento novamente. Mas o custo mais alto é o menos visível: o impacto no time durante o período em que a pessoa errada estava no cargo — código entregue com problemas, decisões técnicas ruins, desmotivação de desenvolvedores que precisam compensar.

O problema é que a maioria dos processos seletivos de TI foi desenhada para avaliar o que é fácil de avaliar — conhecimento técnico testável em uma hora — e não o que realmente determina se um desenvolvedor sênior vai ser bem-sucedido: capacidade de trabalhar com ambiguidade, de tomar decisões de trade-off, de elevar o nível do time ao redor.

Como escrever uma JD que atrai sêniores (não júniors com pretensão)

Job descriptions de desenvolvedor sênior são frequentemente sabotadas por dois problemas opostos: são genéricas demais (lista de requisitos que qualquer dev pleno poderia atender) ou são assustadoras demais (listam 15 tecnologias obrigatórias quando na prática usarão 4).

Uma JD que atrai sêniores de verdade comunica três coisas claramente: qual é o problema técnico real que precisa ser resolvido ("estamos migrando um monólito de 8 anos para microserviços e precisamos de alguém que já fez isso"), qual é o espaço de autonomia disponível ("o time define a arquitetura, não há imposição de cima"), e o que distingue o trabalho de outros ("nosso maior desafio técnico atual é X, e temos intenção de abordá-lo de Y forma").

Requisitos de tecnologia específica como obrigatório quando a pessoa pode aprender em semanas afasta sêniores que reconhecem o padrão de empresa que confunde ferramenta com competência.

"Desenvolvedor sênior de verdade avalia se a empresa tem problemas interessantes e se terá autonomia para resolvê-los. A JD é o primeiro sinal de como a empresa pensa sobre trabalho técnico."

As etapas que fazem sentido

O processo ideal para contratar desenvolvedor sênior tem no máximo 3 etapas, cada uma com propósito claro:

• Etapa 1 — Conversa de contexto (30-45 min): entender a trajetória do candidato, o tipo de problema que ele resolve com mais prazer, o ambiente que o faz prosperar. Essa etapa é mútua — o candidato também está avaliando a empresa.
• Etapa 2 — Avaliação técnica (60-90 min): discussão de design de sistema ou code review de um trecho de código real (pode ser código open source ou um problema análogo ao que a empresa enfrenta). O objetivo não é testar conhecimento de trivia técnica, mas ver como a pessoa pensa, articula trade-offs e reage a feedback durante a sessão.
• Etapa 3 — Conversa com o time (60 min): o candidato fala com 2-3 membros do time. Essa etapa avalia compatibilidade de forma de trabalho e dá ao candidato informações para tomar uma decisão informada sobre aceitar ou não a oferta.

A entrevista técnica que avalia o que importa

LeetCode como critério único de avaliação técnica tem sido amplamente criticado — e com razão. Resolver problemas de algoritmo em 45 minutos sob pressão avalia uma habilidade específica que raramente é necessária no trabalho real de um desenvolvedor sênior. Os melhores desenvolvedores que você já contratou muito provavelmente não passariam em um processo de LeetCode medium/hard sem preparação específica.

O que avalia melhor: discutir um problema de design de sistema real da empresa (como vocês resolveriam esse problema de escalabilidade?), pedir ao candidato que revise um trecho de código com problemas reais e explique o que melhoraria e por quê, ou pedir que explique uma decisão técnica que tomou em projeto anterior, incluindo as alternativas que considerou e por que escolheu aquela.

Como avaliar soft skills em contexto técnico

Soft skills em devs sêniores não são sobre ser simpático. São sobre capacidade de colaborar em contexto técnico — como a pessoa reage quando seu design é questionado, como explica conceitos técnicos complexos, como lida com informação incompleta, como pede ajuda quando está travado.

Algumas perguntas que revelam isso com mais precisão do que perguntas genéricas:

• "Conte sobre uma decisão técnica que você tomou e depois se arrependeu. O que você faria diferente hoje?"
• "Quando você discorda de uma decisão técnica que o time ou seu gestor tomou, como você lida com isso?"
• "Como você explica dívida técnica para alguém de produto que não tem contexto técnico?"
• "Qual foi a última coisa significativa que você aprendeu no trabalho e como você aprendeu?"

Debrief de banca: como tomar a decisão

O debrief é onde processos seletivos costumam falhar silenciosamente. Cada entrevistador deu ao candidato uma nota de 1 a 5 e a decisão vai para quem tem a nota mais alta ou mais baixa — mas ninguém discutiu o que cada nota significa.

Um debrief bem estruturado começa com cada entrevistador compartilhando a avaliação de forma independente antes de ouvir a dos outros (para evitar viés de âncora). Em seguida, discute os pontos de discordância — não para chegar ao consenso artificial, mas para entender se cada entrevistador está avaliando os mesmos critérios. A decisão final deve ser baseada em evidências específicas de comportamento, não em "senti que a pessoa era boa".