Poucas coisas dão mais frio na barriga do que a primeira leva de entrevistas técnicas. A boa notícia: elas testam muito menos decoreba do que você imagina. Este guia é para quem está começando ou mudando de carreira e quer trocar o pânico por um plano — o que estudar, como praticar e como se comportar na hora do vamos ver.

O que a entrevista técnica realmente avalia
Antes de sair resolvendo mil exercícios, entenda o jogo. Uma entrevista técnica raramente quer saber se você memorizou a solução perfeita. Ela quer ver como você pensa: se entende o problema antes de sair codando, se enxerga casos de borda, se comunica o raciocínio e se sabe dizer "não sei, mas eu tentaria assim". Candidato que trava em silêncio assusta mais do que candidato que erra falando.
Ou seja: a entrevista é uma conversa técnica, não uma prova de múltipla escolha. Isso muda tudo na hora de se preparar.
Antes de algoritmo, arrume os fundamentos
Existe uma tentação de pular direto para desafios difíceis. Resista. Primeiro, garanta o feijão com arroz da linguagem que você vai usar: estruturas de dados básicas (listas, mapas, conjuntos), laços, funções, e como você manipula strings e coleções. A maior parte dos problemas de entrevista júnior se resolve com isso mais um pouco de lógica.
Depois, entenda — não decore — as ideias mais cobradas: array, hash map, pilha, fila, e a noção de que uma operação pode ser "cara" ou "barata" conforme o tamanho da entrada. Você não precisa recitar a teoria de complexidade; precisa saber dizer "isso fica lento se a lista crescer muito, porque eu percorro tudo pra cada item".
Como praticar de verdade (e não só assistir vídeo)

Assistir alguém resolver é confortável e quase inútil sozinho. A prática que conta é a que dói um pouco: pegue um problema, feche o vídeo e tente. Trave, pesquise, resolva, e só então veja como outra pessoa fez.
Duas dicas que valem mais que dez horas de tutorial:
- Resolva em voz alta, como se tivesse alguém ouvindo. Isso treina exatamente o que a entrevista avalia.
- Reveja o que você errou. Um problema que você errou e entendeu vale mais que cinco que você acertou no chute.
E pratique no formato real: tempo limitado, escrevendo código de verdade, sem autocompletar mágico. O nervosismo diminui quando o cenário já é familiar.
Durante a entrevista: pensar em voz alta é meio caminho

Chegou a hora. Antes de escrever qualquer linha, repita o problema com suas palavras e confirme os detalhes: o que entra, o que sai, o que fazer com casos estranhos (lista vazia? valores repetidos? entrada gigante?). Perguntar não é fraqueza; é o que um bom profissional faz no trabalho real.
Depois, descreva seu plano antes de codar. Se for uma solução "força bruta" simples, tudo bem começar por ela e melhorar depois — pronto e funcionando quase sempre vence perfeito e imaginário. Enquanto escreve, narre o que está fazendo. O entrevistador não está lendo sua mente; ele está torcendo para entender seu raciocínio.
Quando você travar (porque você vai travar)
Vai dar branco em alguma. E está tudo bem — faz parte. O que separa uma boa entrevista de uma ruim não é nunca travar, é como você reage. Diga em voz alta onde emperrou, o que já tentou e o que suspeita. Muitas vezes o entrevistador te dá uma dica — e saber usar uma dica é uma habilidade valorizada, não um demérito.
Se realmente não sair, proponha um caminho: "eu resolveria testando essa hipótese primeiro". Demonstrar método sob pressão às vezes impressiona mais do que a resposta certa entregue no susto.
Depois da entrevista
Terminou? Anote enquanto está fresco: quais perguntas caíram, onde você travou, o que estudaria diferente. Esse caderninho é o seu maior atalho — cada entrevista vira material de estudo para a próxima, e você percebe rápido que os temas se repetem.
E lembre: entrevista é uma habilidade que se treina, não um talento que você tem ou não tem. As primeiras assustam; por volta da quarta ou quinta, o frio na barriga vira só um leve gelo — e aí você já está jogando o jogo, não sofrendo com ele.


