Como avaliar tecnicamente um desenvolvedor sem ser técnico

Você está entrevistando um desenvolvedor. Ele fala sobre arquitetura de microserviços, otimização de algoritmos, padrões de design. Você acena com a cabeça entendendo nada. Depois ele passa no seu processo seletivo e, três meses depois, você descobre que o código é um caos.

Esse cenário assusta porque é comum. A verdade é que você não precisa entender código para avaliar um desenvolvedor — precisa saber ouvir.

Por que avaliação técnica é crítica (mesmo para não-técnicos)

Contratar um desenvolvedor ruim é como comprar um carro sem freio. Funciona por um tempo, mas eventualmente você se lascará. A diferença é que substituir um dev custa 10x mais caro em tempo de projeto perdido, refatoração e morale da equipe.

A maioria das avaliações falha não porque faltam testes técnicos, mas porque falta estrutura clara do que você está realmente testando.

Um dev pode:

• Resolver um algoritmo de quadro branco e ser horrível em trabalho em equipe.

• Ser brilhante em discussão teórica e ser lento em produção.

• Escrever código perfeito individualmente e não conseguir mentorear ninguém.

Você precisa de um método que funcione mesmo se você não for técnico.

O que qualquer fundador consegue avaliar (sem entender código)

Esqueça aquela ideia de que você precisa entender programação para avaliar programadores. Você precisa entender três coisas que não têm nada a ver com sintaxe:

1. Clareza de pensamento

Um dev sênior consegue explicar decisões complicadas em linguagem simples. Se ele não consegue explicar para você (não-técnico), ele não vai conseguir para o time dele.

O que avaliar: Quando você pergunta "como você resolveria X?", ele começa pelo problema de negócio ou pelo detalhe técnico? Devs sênior contextualizam.

2. Capacidade de aprender

Dev bom não sabe tudo. Mas aprende rápido. Quando ele não sabe algo (e todo dev vai não saber), como ele reage?

O que avaliar: Ele tem humildade para dizer "não sei"? Ele pergunta onde procurar ou já foi googlar? Ele volta com o que aprendeu ou ignora?

3. Responsabilidade pessoal

Devs ruins culpam especificações, culpam o designer, culpam o mercado. Devs bons dizem "aqui foi onde eu falhei".

O que avaliar: Quando você pergunta sobre um projeto que deu errado, ele reconhece seu papel ou vira acrobacia de culpar outros?

As perguntas que revelam tudo

Você não precisa fazer perguntas técnicas. Essas 5 perguntas simples revelam muito mais:

Pergunta 1: "Como você documentaria seu código para que outro dev entendesse em 6 meses?"

Por que funciona: Separar devs que se importam com qualidade dos que só escrevem código que "funciona agora". A resposta também revela se ele pensa na equipe além de si.

O que escutar: Se ele responde com comentários, testes e arquitetura clara, bom sinal. Se ri e diz "código bom é auto-documentado", preocupe-se.

Pergunta 2: "Conte sobre um projeto onde você começou errado e teve que refazer. O que aprendeu?"

Por que funciona: Sêniors reconhecem erros. Juniores negam ou não percebem. Devs tóxicos culpam outros.

O que escutar: Se ele fala sobre o erro com maturidade e o que mudou depois, ótimo. Se ele não consegue dar exemplo, talvez não aprenda.

Pergunta 3: "Se você discordasse do arquiteto de um projeto, como você comunicaria?"

Por que funciona: Avalia se ele consegue ter opinião própria mas comunicar respeitosamente.

O que escutar: Devs sênior dizem algo como "Eu marcaria uma conversa, explicaria meu ponto de vista com dados e deixaria claro que respeitaria a decisão final". Devs juniores dizem "Eu teria feito diferente" ou "Eu não discordaria porque ele sabe mais".

Pergunta 4: "Qual é seu maior medo em trabalhar em uma startup?"

Por que funciona: Ele pensa realisticamente sobre o contexto? Ou veio apenas pela oportunidade de salário?

O que escutar: Se ele menciona velocidade, falta de processos, incerteza técnica — bom, ele pensou sobre startups. Se diz "nenhum, estou pronto pra qualquer coisa", cuidado.

Pergunta 5: "Como você se mantém atualizado em um mercado que muda o tempo todo?"

Por que funciona: Separar devs que para de aprender dos que crescem.

O que escutar: Lê blogs, faz cursos, experimenta side projects, participa de comunidades. Devs estagnados respondem "confio no que conheço" ou "a empresa deveria treinar".

Reunião de equipe técnica

O que as respostas revelam sobre comunicação

Aqui está um secret: comunicação clara é tão importante quanto código bom em um dev sênior.

Quando ele está respondendo, observe:

• Ele reformula suas próprias respostas quando você não entende? Devs bons sabem que se você não entendeu, é responsabilidade deles.

• Ele faz perguntas antes de responder? "Você quer saber sobre a arquitetura ou sobre a decisão de design?" Mostra que pensa na sua realidade.

• Ele admite quando algo é muito técnico para explicar aqui? Sêniors sabem o que dá para simplificar e o que não dá.

Estruturando um teste prático (mesmo sem saber avaliar código)

Aqui está o melhor: você consegue fazer um teste técnico prático sem entender código.

Estrutura simples:

1. Defina um problema real do seu produto: "Precisamos refatorar a página de checkout porque está lenta. Qual seria sua abordagem?"

2. Dê 2-3 horas: Deixe o dev trabalhar. Se possível, remotamente, no seu ambiente.

3. Peça documentação do raciocínio: "Explique sua solução em um documento de texto para que alguém da equipe possa entender." Isso força ele a comunicar.

4. Traga alguém técnico para analisar, mas não para julgar a sintaxe: Seu CTO ou um dev confiável olha o resultado. Mas a pergunta não é "o código está perfeito?" e sim "ele pensou bem? Que tal a estrutura de pensamento?"

5. Você avalia a entrega e a comunicação: Ele conseguiu entregar em tempo? O documento era claro? Ele pediu ajuda quando precisou ou ficou preso? Você consegue avaliar isso sem saber programação.

O método de pair programming para não-técnicos

Aqui está a magia: pair programming não é apenas para técnicos.

Deixe o dev resolver o problema de teste enquanto alguém da sua equipe (pode ser você!) senta do lado e observa.

O que avaliar (você consegue):*

• Ele explica o que está fazendo enquanto digita?

• Quando bate em um problema, como reage? Pensa em voz alta, googleia, pede ajuda?

• Ele é paciente em explicar para o observador?

• Qual é a velocidade dele? Está confiante ou hesitante?

Você vai ver em 90 minutos coisas que um currículo não mostra em um ano.

Quando trazer um especialista para avaliar

Aqui está a verdade: em algum ponto, você precisa trazer alguém técnico. A questão é trazer no momento certo, pelo motivo certo.

Traga um especialista quando:

• Você chegou aos últimos 2-3 candidatos e precisa diferenciar.

• A senioridade solicitada é muito alta (sênior/lead).

• A skill específica é crítica (você vai contratar alguém para arquitetura em cloud, por exemplo).

Como estruturar essa avaliação:

Dê ao seu especialista um briefing claro: "Eu avaliei X, Y, Z como não-técnico. Eu preciso que você valide se ele realmente sabe resolver problema A." Não peça avaliação geral, peça validação de hipóteses específicas.

O erro mais comum (e como evitar)

O erro número 1 que founders não-técnicos cometem: depender 100% da avaliação técnica.

Um dev tecnicamente excelente pode ser tóxico, lento, ou incapaz de trabalhar em equipe. Seu processo não pode ser só testes.

Combine:

1. Entrevista comportamental (a parte que você faz bem)

2. Teste prático (a parte que você consegue estruturar)

3. Avaliação técnica especializada (a parte que você traz help)

4. Referência de antigos colegas (a parte que ninguém leva a sério mas é ouro puro)

Conclusão: você consegue avaliar

Aqui está a verdade confortante: você não precisa ser desenvolvedor para saber se um desenvolvedor é bom. Você precisa fazer as perguntas certas, estruturar um teste prático, trazer especialista no momento certo, e confiar em seu instinto sobre comunicação e responsabilidade.

Os melhores devs são os que conseguem equilibrar excelência técnica com humildade, comunicação clara e trabalho em equipe. E você consegue avaliar essas coisas em qualquer entrevista.

A BuildLab estrutura avaliações técnicas que funcionam mesmo quando você não é técnico — porque sabemos que contratar bem é tão importante quanto contratar rápido.

Quer conversar sobre como estruturar sua próxima avaliação de dev? Entre em contato com a BuildLab — vamos desenhar um processo que revela quem é realmente bom.