Perguntas de entrevista técnica: como avaliar competência real

As perguntas de entrevista técnica que ainda dominam muitos processos de recrutamento medem sobretudo a memória: definições que se decoram na véspera, algoritmos que raramente aparecem no trabalho diário e enigmas que testam a calma sob pressão mais do que a capacidade de construir software. O problema não é falta de rigor — é estarmos a avaliar a coisa errada. Uma pessoa pode recitar a diferença entre uma stack e uma queue e, ainda assim, não conseguir estruturar uma funcionalidade real de raiz.

Para uma PME portuguesa, cada contratação errada custa tempo, dinheiro e moral da equipa. Vale a pena, por isso, desenhar entrevistas que revelem competência genuína: como o candidato raciocina perante a incerteza, como comunica decisões e como lida com problemas parecidos com os do vosso dia a dia. Este artigo mostra como passar da trivia para conversas que mostram trabalho real.

O problema das perguntas de entrevista técnica baseadas em trivia

Perguntas do tipo "o que é uma closure?" ou "explique a complexidade Big-O do quicksort" parecem objetivas, mas favorecem quem estudou recentemente para entrevistas, não quem produz bom código. Penalizam candidatos experientes que resolvem estes problemas há anos sem pensar na terminologia académica, e recompensam a preparação de véspera. Pior ainda: dão uma falsa sensação de rigor, porque geram respostas fáceis de classificar como certas ou erradas.

A alternativa não é abandonar o rigor, mas mudar o foco. Em vez de perguntar o que uma pessoa sabe de cor, perguntamos como ela usa o que sabe. A diferença entre memória e competência aparece quando o problema não tem uma resposta única e obriga o candidato a fazer escolhas, a justificá-las e a reconhecer os seus limites.

Não contratamos pessoas para recitarem definições. Contratamos para tomarem boas decisões quando o problema é ambíguo e ninguém tem a resposta à mão.

Avaliar raciocínio com problemas abertos

As melhores perguntas de entrevista técnica são abertas e enraizadas em situações reais. Em vez de pedir a solução ótima de um puzzle, apresente um cenário próximo do vosso produto e observe como o candidato o desmonta. O objetivo é ouvir o processo de pensamento em voz alta, não chegar a uma resposta perfeita.

Considere perguntas como estas, que convidam à discussão em vez de exigirem uma resposta memorizada:

• "Temos um endpoint que ficou lento à medida que os dados cresceram. Como investigaria a causa e por onde começaria?"
• "Precisamos de exportar relatórios que demoram minutos a gerar. Que abordagens consideraria e que compromissos tem cada uma?"
• "Como estruturaria os dados de uma funcionalidade de agendamento com fusos horários e disponibilidades? O que poderia correr mal?"
• "Descreva uma decisão técnica de que se arrependeu. O que faria de diferente hoje?"

Repare que nenhuma destas perguntas tem uma resposta única. O que interessa é a qualidade do raciocínio: o candidato faz perguntas de clarificação antes de avançar? Considera compromissos entre desempenho, simplicidade e custo? Admite quando não sabe algo e explica como o descobriria? São estes sinais que distinguem quem pensa como engenheiro de quem apenas decorou padrões.

Deixe espaço para o candidato clarificar

Um bom sinal precoce é o candidato não assumir de imediato que percebeu o problema. Perguntas sobre requisitos, volume de dados ou casos-limite mostram maturidade. Se o candidato mergulha logo numa solução sem clarificar nada, é uma oportunidade para perceber se procura entender o problema ou apenas mostrar velocidade.

Pair programming e discussão de problemas reais

Uma sessão de pair programming, mesmo curta, revela mais do que uma bateria de perguntas teóricas. Trabalhar lado a lado num problema pequeno e realista mostra como o candidato lê código existente, escolhe nomes, testa hipóteses e reage a feedback. Não avalie apenas se chega ao fim — avalie como comunica enquanto lá chega.

Prepare um exercício com contexto próximo do vosso, de preferência num pedaço de código com uma pequena imperfeição já lá dentro, para ver se o candidato a nota. Durante a sessão, procure comportamentos como estes:

• Explica o que está a fazer e porquê, sem esperar que perguntem;
• Aceita sugestões e integra-as, em vez de defender a primeira ideia a todo o custo;
• Verifica os seus pressupostos com testes ou exemplos, em vez de assumir que está correto;
• Prioriza fazer algo funcionar antes de o tornar perfeito, gerindo o tempo com sensatez.

Se preferir não fazer live coding, um take-home curto seguido de uma conversa sobre as decisões tomadas funciona igualmente bem. O valor não está no artefacto entregue, mas na discussão que ele permite: por que escolheu esta abordagem, o que deixou de fora, como o evoluiria se tivesse mais tempo.

Estruturar a entrevista para ser justa e comparável

Conversas abertas correm o risco de se tornarem subjetivas. Para as tornar justas, defina antecipadamente o que procura em cada pergunta e use os mesmos critérios com todos os candidatos. Uma grelha simples — clareza de raciocínio, qualidade das perguntas de clarificação, gestão de compromissos, comunicação — permite comparar pessoas sem cair na simpatia pessoal ou no viés de "parece-se comigo".

É aqui que testes técnicos bem desenhados complementam a entrevista humana. Um exercício estruturado, igual para todos e avaliado com critérios consistentes, dá uma base objetiva antes da conversa, liberta a entrevista para se focar no raciocínio e reduz o peso da primeira impressão. Combinar um sinal automático e comparável com uma discussão qualitativa é a forma mais fiável de medir competência real.

No fim, o objetivo de qualquer entrevista técnica é simples: prever se a pessoa vai resolver bem os problemas que a vossa equipa enfrenta. Perguntas de trivia raramente o conseguem. Problemas reais, pair programming e uma grelha de avaliação clara aproximam-vos muito mais dessa resposta — e tornam o processo mais justo para quem se candidata.