O que avaliar antes de entrevistar um desenvolvedor de software

Você abre o currículo de um candidato a desenvolvedor e ali está tudo o que esperava: linguagens, frameworks, uma nuvem de siglas que parece cobrir cada item da vaga. Mas essa lista não responde à única coisa que de fato importa quando o código entra em produção: como essa pessoa raciocina diante de um problema que nunca viu? Como ela se move quando o requisito está mal escrito, o bug não se reproduz e o resto da equipe espera uma resposta?

Em desenvolvimento, a stack se aprende; a forma de pensar e de colaborar, muito menos. Você contrata alguém que domina a tecnologia da moda e descobre tarde que escreve código que ninguém mais consegue manter, que não pergunta quando algo não fecha, ou que trava diante de um problema que não estava no tutorial. Por isso convém avaliar antes de entrevistar: chegar à conversa sabendo onde estão as dúvidas reais, em vez de acumular siglas.

Por que o currículo não basta para este cargo

O currículo de um desenvolvedor é enganosamente sólido. As tecnologias se listam fácil e quase todas se aprendem com documentação e prática. O difícil de adquirir —e o que o currículo nunca mostra— é como a pessoa raciocina: como decompõe um problema ambíguo, o que faz quando uma solução não funciona, como decide entre o rápido e o sustentável.

Você também não verá no currículo como ela colabora. Um desenvolvedor tecnicamente forte que não explica suas decisões, não lê o código dos outros com abertura ou não pergunta a tempo acaba custando mais do que agrega. O código vive em equipe. O currículo te dá insumos sobre o que a pessoa diz ter tocado; você precisa de evidência além do currículo para saber como ela pensa e como trabalha com os outros.

Quais sinais observar além da stack

Mais do que confirmar linguagens, convém olhar sinais de raciocínio e de ofício, comparáveis entre todos os candidatos. Três que costumam marcar a diferença:

• Raciocínio para resolver problemas: como enfrenta um cenário que não conhece, que hipóteses testa e como reage quando a primeira ideia falha.
• Pensamento estruturado: como divide um problema grande em peças gerenciáveis, em vez de atacá-lo inteiro ou copiar a primeira solução que encontra.
• Colaboração e comunicação técnica: se explica suas decisões com clareza e deixa o código e o contexto prontos para que outro continue sem adivinhar.

Esses sinais são comparáveis quando você os observa com o mesmo critério para todos, não conforme a impressão que deixa uma única entrevista. É aí que uma avaliação prévia te dá um ponto de partida comum para todo o painel.

Como combinar competências conforme o cargo

Um desenvolvedor não se define por uma única competência. O perfil útil combina raciocínio para resolver problemas, pensamento estruturado e colaboração, com pesos que mudam conforme o cargo: um perfil de backend próximo da arquitetura pede mais rigor estrutural, enquanto um que toca produto e conversa com negócio valoriza mais a comunicação. Combinar competências conforme o cargo evita o erro de avaliar todos com a mesma régua.

O que olhar no relatório antes da entrevista

Quando você revisa um relatório, o objetivo não é um número que decida por você, e sim uma leitura que te prepare. Repare no sinal de aderência ao cargo como ponto de partida para priorizar quem entrevistar primeiro, e depois desça ao detalhe por competência. Se alguém mostra raciocínio forte mas comunicação mais fraca, não se descarta: entrevista-se com foco nessa lacuna.

O relatório também inclui controles de integridade, para que a evidência que você compara seja confiável entre candidatos. Isso te dá um critério comum dentro da equipe de seleção, em vez de três opiniões que não se podem contrastar. Se você trabalha em um ambiente técnico, em soluções para tecnologia verá como isso se encaixa em perfis de desenvolvimento. O relatório apoia a decisão; a equipe mantém a decisão final.

Perguntas de entrevista baseadas na evidência

A entrevista rende muito mais quando você chega com a avaliação lida. Em vez de re-perguntar o que já sabe, você aprofunda onde o relatório mostrou dúvidas. Algumas linhas que funcionam para desenvolvimento:

• “Na avaliação você resolveu o caso por um caminho direto. Me conte como o mudaria se o sistema tivesse que escalar para dez vezes o tráfego.”
• “Descreva uma vez em que a sua primeira solução não funcionou. Como você percebeu e o que fez depois?”
• “Como você explica uma decisão técnica a alguém de produto que não programa?”
• “Seu resultado foi alto em raciocínio e mais baixo em colaboração. Como você trabalha quando herda código de outra pessoa?”

Cada pergunta nasce de um sinal observado. Assim você decide com respaldo e contrasta as respostas com um critério comum, em vez de depender da química do momento. Na biblioteca de recursos você encontrará mais guias por cargo para montar essas conversas.

Em resumo

O currículo de um desenvolvedor te diz quais tecnologias ele tocou, não como raciocina nem como colabora diante de um problema que ainda não tem resposta. Antes de entrevistar, observe resolução de problemas, pensamento estruturado e comunicação com sinais comparáveis; combine as competências conforme o tipo de desenvolvedor que você precisa; use o relatório para priorizar e para preparar perguntas concretas; e entre na entrevista com evidência, não com palpites. Assim você investe suas horas de entrevista nos candidatos certos. Você pode começar vendo a combinação de competências para desenvolvedor.