Imagine dois candidatos numa entrevista técnica. Os dois resolvem o exercício. Os dois conhecem a linguagem, acertam a lógica, entregam código que funciona. E, no fim, um recebe a proposta e o outro, um “obrigado, vamos seguir com outros perfis”. Se saber programar fosse o único critério, isso não faria sentido. Mas faz — e entender por quê muda a forma como você se prepara.
A entrevista técnica raramente é sobre chegar na resposta certa. Na maioria das vezes, ela é sobre tudo o que acontece em volta da resposta. Vamos ao que os avaliadores realmente observam quando o código, por si só, empata.
Como você pensa em voz alta
O erro mais comum é mergulhar no código em silêncio e só voltar à tona com a solução pronta. Do outro lado da mesa, isso é frustrante — o avaliador não faz ideia de como você chegou lá, e o “como” é justamente o que ele veio ver.
Narrar o raciocínio muda o jogo. “Deixa eu entender o problema primeiro”, “acho que dá para resolver com um mapa, mas isso gasta memória, então vou pesar”, “vou começar pelo caso simples e depois trato as exceções”. Isso mostra estrutura de pensamento. E tem um efeito prático: se você começa a ir para o lado errado, quem está avaliando consegue te dar uma pista — coisa impossível quando você trabalha mudo.
Na entrevista técnica, o avaliador não está contratando a sua solução. Está contratando a cabeça que vai resolver os mil problemas que ele ainda nem sabe que vai ter.
As perguntas que você faz antes de codar
Bons enunciados de entrevista costumam ser propositalmente vagos. E a reação a essa vagueza diz muito. O candidato apressado assume tudo e sai codando. O candidato maduro pergunta: a lista pode vir vazia? Os valores podem se repetir? Existe limite de tamanho? O que devo fazer se a entrada for inválida?
Essas perguntas não são enrolação — são o que a gente faz o dia inteiro no trabalho real. Requisito nunca chega completo. Quem esclarece antes de construir economiza retrabalho e evita construir a coisa errada com perfeição. Numa entrevista, esse comportamento sinaliza exatamente o profissional que a empresa quer no time.
Como você lida com o que não sabe
Vai travar em algum momento. É de propósito, muitas vezes — o avaliador quer ver o que acontece quando o chão some. E o que ele observa não é se você sabe tudo, mas como você reage a não saber.
Fingir é o pior caminho. Um “não lembro a sintaxe exata disso, mas a ideia é…” é infinitamente melhor que um blefe confiante que desmorona na primeira pergunta. Admitir a lacuna com tranquilidade e propor um caminho para contorná-la mostra maturidade. É, aliás, o que se espera de um profissional no dia a dia: ninguém sabe tudo, todo mundo pesquisa, o que importa é saber navegar a dúvida.
Os detalhes que empurram a decisão
Quando o resto empata, pequenos sinais desempatam:
- Você testa o próprio código? Passar alguns exemplos na mão, incluindo o caso-limite, antes de dizer “terminei”, mostra cuidado.
- Você nomeia bem as coisas? Variáveis com nome claro dizem que você pensa em quem vai ler depois.
- Você aceita uma sugestão? Reagir bem a “e se você fizesse assim?” mostra que você trabalha em equipe, não na defensiva.
Como treinar isso antes da entrevista
Como quase tudo o que importa aqui é comportamento, dá para ensaiar. Pegue um problema qualquer e resolva-o em voz alta, sozinho, narrando cada passo como se alguém estivesse ouvindo. É estranho no começo e quase mágico depois: você percebe onde o seu raciocínio embola e treina a articulação que a entrevista vai cobrar.
Se puder, faça entrevistas de mentira com um colega, um de cada lado da mesa. Sentir a pressão de explicar enquanto pensa, com outra pessoa olhando, é um treino que nenhuma quantidade de exercícios resolvidos sozinho substitui. E não ignore o básico: dormir bem, testar câmera e microfone antes, ter água por perto. Nervosismo técnico já basta; não some a ele um problema de conexão que dava para evitar.
Prepare o entorno, não só os algoritmos
A conclusão prática é libertadora, na verdade. Você não precisa ser um gênio dos algoritmos para ir bem numa entrevista técnica. Precisa comunicar com clareza, fazer boas perguntas, lidar com honestidade com o que não sabe e mostrar cuidado com quem vai conviver com o seu código.
Isso é uma ótima notícia, porque tudo isso se treina — e se treina mais rápido do que anos de estudo de estrutura de dados. Da próxima vez que for se preparar, não gaste todo o tempo decorando soluções. Pratique pensar em voz alta, pratique perguntar, pratique dizer “não sei” com elegância. É esse conjunto, e não o algoritmo perfeito, que faz um candidato ser lembrado quando a mesa se reúne para decidir.
