A entrevista técnica é a etapa em que a empresa confere se o candidato sabe fazer o que o currículo diz que ele sabe fazer. Diferente da conversa com o RH, aqui existe um problema concreto sobre a mesa: um exercício de código, um case de negócio, um procedimento de laboratório, uma aula-teste. E, diferente do que muitos candidatos imaginam, a resposta certa é só uma parte do que está sendo avaliado.
Este guia descreve os formatos mais frequentes de entrevista técnica, propõe um plano de preparação de uma a duas semanas, explica o que o avaliador observa além do resultado e percorre os erros que mais eliminam candidatos. Vale para programação, mas também para finanças, docência, design, engenharia e qualquer área em que exista uma prova prática.
Neste guia
O que é uma entrevista técnica e quando ela aparece
Em quase todo processo seletivo com mais de uma etapa, a entrevista técnica vem depois da triagem inicial do RH e antes da conversa final com o gestor. Quem conduz é alguém que faz ou supervisiona o trabalho da vaga: um tech lead, um gerente de área, um profissional sênior. O objetivo é reduzir a incerteza sobre uma única pergunta: se essa pessoa entrar no time na segunda-feira, ela consegue resolver os problemas reais do cargo?
O nome muda conforme a área. Em tecnologia, fala-se em entrevista técnica ou "teste técnico"; em consultoria, em "case"; em educação, em aula-teste ou aula demonstrativa; em saúde e laboratório, em prova prática ou avaliação de competências. O formato varia, a lógica é a mesma: mostrar o trabalho em vez de descrevê-lo.
Os tipos mais comuns de entrevista técnica
Convém confirmar o formato exato com antecedência. A maioria dos recrutadores informa quando perguntado, e passar uma semana se preparando para live coding quando o que vem é um take-home desperdiça uma semana de esforço.
Live coding ou prova ao vivo
O candidato resolve um exercício na frente do avaliador, em um editor compartilhado ou no quadro, durante 45 a 60 minutos. Os problemas costumam ter dificuldade média: manipular estruturas de dados, percorrer uma coleção, criar uma função com casos de borda. O que pesa é o processo: como a pessoa entende o enunciado, que perguntas faz antes de escrever e como reage ao próprio erro.
Take-home ou desafio para entregar
Chega um enunciado por escrito e a entrega é em dois a cinco dias. Costuma ser um projeto pequeno mas completo: uma API com dois endpoints, uma análise de um conjunto de dados, uma proposta de design para uma tela. Aqui não se avalia velocidade, e sim critério: legibilidade, testes, documentação breve e decisões justificadas. Um README de dez linhas explicando o que foi feito e o que ficou de fora por falta de tempo vale tanto quanto o código.
System design ou desenho de sistemas
Reservado a perfis com alguns anos de experiência. O avaliador apresenta um problema aberto ("desenhe um sistema de notificações para um milhão de usuários") e espera que o candidato faça perguntas, delimite o escopo, proponha uma arquitetura e discuta compromissos: consistência versus disponibilidade, custo versus latência. Não há resposta única; mede-se a capacidade de conversar sobre decisões técnicas.
Case de negócio
Comum em consultoria, finanças, marketing e produto. Apresenta-se uma situação ("um cliente perde 10% das vendas por trimestre, o que fazer?") e pede-se para estruturar a análise em voz alta, estimar grandezas e chegar a uma recomendação. A ordem do raciocínio pesa mais do que o número final, desde que o número seja defensável.
Provas práticas em outras áreas
Fora dos escritórios também existe entrevista técnica: a aula de 20 minutos diante de uma banca, o teste de praça em gastronomia, o exercício de conciliação bancária em uma vaga contábil, a tradução de uma página com tempo cronometrado, o diagnóstico de uma falha em um equipamento. A preparação segue a mesma lógica da tecnologia: conhecer o formato, praticar com tempo e explicar o que se faz enquanto se faz.
Como se preparar em uma ou duas semanas
Com o formato confirmado, uma ou duas semanas bastam para chegar em condições se o tempo for distribuído com critério. O plano a seguir supõe de 8 a 12 horas no total, em sessões curtas.
- Dias 1 e 2: reler a vaga e mapear o conteúdo. Cada tecnologia, ferramenta ou competência citada no anúncio é um tema provável. Convém anotar quais estão sólidas e quais estão fracas, e concentrar o estudo nas segundas.
- Dias 3 a 6: praticar problemas do tipo esperado. Para live coding, dois ou três exercícios por dia de dificuldade média, com cronômetro e em voz alta. Para cases, um por dia com estrutura escrita. Para aula-teste, o roteiro completo ensaiado na frente de alguém.
- Dias 7 e 8: revisar fundamentos do cargo. Os conceitos que um avaliador sênior espera que qualquer pessoa do nível domine sem hesitar. As perguntas típicas por nível estão no guia de perguntas de entrevista para programador júnior.
- Dias 9 e 10: simulação completa. Uma sessão com a duração e o formato reais, com outra pessoa ou com um simulador, seguida de uma revisão honesta do que deu errado.
- Véspera: descanso e logística. Ambiente de desenvolvimento testado, câmera e microfone verificados se for remota, e nada de estudar temas novos.
O restante da preparação não técnica (pesquisar a empresa, preparar as próprias perguntas) está no guia sobre como se preparar para uma entrevista. Não convém pular essa parte: uma entrevista técnica continua sendo uma entrevista.
O que é avaliado além da resposta
Um avaliador experiente sabe que o exercício de 45 minutos é uma amostra pequena. Por isso observa sinais que preveem o desempenho real melhor do que o resultado do exercício em si.
Raciocínio em voz alta. É o fator que mais pesa e o que menos se pratica. Explicar o que se está pensando ("primeiro vou validar a entrada, depois resolvo o caso geral e no fim vejo as bordas") permite que o avaliador acompanhe o processo e ajude se for preciso. O silêncio prolongado, mesmo que termine em uma solução correta, deixa o avaliador sem informação.
Perguntas antes de começar. Um enunciado técnico quase sempre tem ambiguidades intencionais. Perguntar sobre o tamanho dos dados, os casos de borda ou as restrições de tempo demonstra o hábito de entender o problema antes de resolvê-lo, que é exatamente o que se espera no trabalho real.
Reação ao erro. Errar durante a prova é normal e, para o avaliador, é uma oportunidade de ver algo valioso: se o candidato percebe o erro sozinho, como corrige e se aceita uma dica sem ficar na defensiva. Um candidato que trava e pede um minuto para se reorganizar fica melhor do que um que insiste em um caminho errado.
As perguntas que o candidato faz no final. Perguntar como funciona a revisão de código, quais ferramentas o time usa ou como se decide o que construir mostra interesse no trabalho concreto. O guia sobre perguntas para fazer na entrevista traz exemplos que servem também para esta etapa.
Quando não se sabe a resposta, a pior saída é inventar. Dizer "não usei, mas entendo que funciona assim e verificaria desta maneira" transmite honestidade e método. Sustentar uma resposta falsa diante das perguntas seguintes é eliminação quase certa.
Erros frequentes na entrevista técnica
As eliminações nesta etapa raramente se devem à falta total de conhecimento. Devem-se a hábitos que um avaliador percebe rápido e que a prática corrige.
| Assim não | Assim sim |
|---|---|
| Começar a escrever código assim que lê o enunciado | Reformular o problema em voz alta e fazer duas ou três perguntas antes de escrever |
| Resolver em silêncio por dez minutos | Narrar o plano e cada decisão intermediária, mesmo que pareça óbvia |
| Otimizar desde o início e nunca terminar | Entregar primeiro uma solução que funcione, depois melhorar se sobrar tempo |
| Entregar um take-home sem testes nem README | Incluir testes mínimos e um README com decisões e pendências |
| Discutir uma dica do avaliador | Aceitar, agradecer e seguir; a dica faz parte do exercício |
| Responder "não sei" e ficar em silêncio | Explicar como descobriria e o que testaria primeiro |
| Não preparar nenhuma pergunta para o final | Levar duas perguntas sobre como o time trabalha no dia a dia |
Um erro adicional, próprio do take-home, é dedicar três vezes mais tempo do que o sugerido. Os avaliadores percebem e não necessariamente valorizam: uma entrega de 40 horas para um enunciado de 6 sugere dificuldade para delimitar escopo, não dedicação.
Praticar o formato antes do dia
A diferença entre saber resolver um problema e resolvê-lo enquanto alguém observa aparece na primeira tentativa. Por isso a simulação completa dos dias 9 e 10 não é opcional: ela reproduz a pressão, obriga a falar enquanto se pensa e expõe os vícios de linguagem e os silêncios.
Há três maneiras de fazer isso. Com um colega no papel de avaliador, o mais realista, mas difícil de agendar. Gravando com o celular enquanto se resolve um exercício em voz alta, útil para detectar silêncios longos. Ou com um simulador de entrevista com IA que faz perguntas técnicas do cargo, aprofunda as respostas e devolve uma avaliação no final. O guia sobre entrevista simulada com IA explica como aproveitar. Duas rodadas costumam bastar para que o raciocínio em voz alta deixe de parecer forçado.
Perguntas frequentes
Quanto dura uma entrevista técnica?
Depende do formato. Um live coding ou uma entrevista de system design dura entre 45 e 90 minutos. Um take-home é entregue em dois a cinco dias, com carga sugerida de 4 a 8 horas de trabalho. Os cases costumam ocupar entre 30 e 45 minutos cada.
O que acontece se não der tempo de terminar o exercício?
Não é eliminação automática. Muitos exercícios são desenhados para não terminar no tempo disponível, justamente para ver como o candidato prioriza e se comunica. Uma solução parcial, bem explicada e com as pendências identificadas, costuma ser avaliada melhor do que uma completa feita em silêncio.
Pode usar internet ou documentação durante a prova?
No take-home, sim, e espera-se que use. No live coding depende da empresa: algumas permitem explicitamente, outras não. Convém perguntar antes de começar; a pergunta em si não tira pontos.
Como se preparar se a vaga não diz que tipo de prova haverá?
Perguntar ao recrutador. É uma consulta normal, quase sempre respondida, e evita preparar o formato errado. Se não houver resposta, o mais seguro é supor um exercício ao vivo de dificuldade média sobre as tecnologias ou competências centrais da vaga.
Existe entrevista técnica fora da programação?
Sim, com outros nomes: aula-teste na educação, case em consultoria e finanças, prova prática em gastronomia, saúde, ofícios e laboratório. A lógica de preparação é a mesma: conhecer o formato, praticar com tempo real e explicar o que se faz enquanto se faz.