Tipos de entrevista técnica (e como treinar cada um)

O que é: você recebe um problema de lógica (ordenar um array, encontrar um padrão em uma lista, resolver um quebra-cabeça matemático) e precisa escrever código que funcione. Pode ser online, em um site como HackerRank ou LeetCode, ou enviado por email pra resolver em casa.

O que avaliam de verdade: não é se você decora fórmulas. É se você consegue quebrar um problema em passos menores, pensar em voz alta sobre suas decisões, e escrever código legível mesmo sob pressão. Importa se você testa seu próprio código mentalmente antes de submeter.

Como treinar:

• Comece com problemas fáceis, não com os difíceis. Resolva duas ou três por semana durante um mês. A constância vale muito mais que maratonas.
• Antes de sair codando, pegue um problema e escreva a lógica em português em um papel ou editor de texto. Tipo: "vou varrer a lista, comparar cada número com o próximo, trocar se o da esquerda for maior". Só depois escreve o código.
• Use sites como HackerRank ou LeetCode (com plano gratuito/básico) pra ter feedback automático.
• Não caia na armadilha da perfeição: se não conseguir otimizar a solução, uma solução mais lenta mas correta vale muito.

O que é: você entra numa videochamada com um engenheiro, recebe um problema ou precisa refatorar um código que ele mostra, e escreve tudo ao vivo enquanto ele observa. Pode ser simples (inverter uma string) ou mais envolvido (implementar uma funcionalidade).

O que avaliam de verdade: raciocínio em voz alta importa muito mais que acertar de primeira. Quando você fala "vou fazer assim, mas deixa eu pensar se tem problema nesse caso aqui", você mostra honestidade técnica. É muito normal travar: pausa, pensa, pergunta. Quem entrevista quer entender como você pensa, não testar se você é máquina.

Como treinar:

• Convide alguém (amigo, colega de estudo, até bota no Discord da Criativaria) pra simular: um faz perguntas, outro programa ao vivo.
• Grave você mesmo resolvendo um problema no seu próprio computador: fale em voz alta enquanto pensa, depois assista de volta. Parece estranho? É, mas você descobre nervosismo que não sabia que tinha.
• Quando ficar travado de verdade, não saia falando em pánico. Respire, fale "deixa eu parar um segundo e desenhar a lógica", e arruma. Isso é avaliado positivamente como calma técnica.

O que é: a empresa manda um projeto pequeno (reconstruir uma página, criar uma API simples, implementar uma funcionalidade) pra você fazer em casa durante alguns dias. Você entrega código, às vezes um README explicando suas decisões.

O que avaliam de verdade: não é só se funciona. É se o código se lê bem, se você conseguiu organizar o projeto de forma lógica, se escreveu um README que alguém entende. Capricho com detalhes conta: a pasta /src organizada, variáveis com nomes sensatos, comentário em uma lógica confusa.

Como treinar:

• Cada projeto pessoal que você faz: escreva um README. Explique o que faz, como rodar, qual foi o maior desafio que resolveu. Lê bem? Ótimo.
• Organize seu código como se outra pessoa fosse ler: pasta /components, /utils, /styles separadas. Nomes de função que falam o que fazem.
• Quanto tempo é razoável? Leia o email da empresa. Se diz "você tem 2-3 dias", coloca 3-4 horas por dia, não 20 horas numa sessão maratônica. Qualidade > velocidade.
• Se o projeto pede testes ou comentários, não sai só fazendo: coloca um comentário explicando uma decisão complicada.

[!ATENÇÃO] Não tenta completar 100% de features se vai ficar correndo. Entrega 70% com código limpo, bem testado e bom README, em vez de 100% bagunceiro. Quem vai revisar dá mais valor a "consegue ler e entender" que "copio e colo tudo correndo".

O que é: o entrevistador faz perguntas tipo "explique o que é closure", "como funciona hoisting em JavaScript", "qual é a diferença entre var, let e const". Pode ser junto com code ou separado.

O que avaliam de verdade: você não precisa recitar uma definição de dicionário. Explique com suas palavras, como se estivesse ensinando pra um amigo. Se você entendeu de verdade, consegue dar um exemplo concreto ou desenhar a ideia. Se não entendeu, pode falar "não tenho certeza, mas meu palpite é..." e pensar em voz alta.

Como treinar:

• Pegue um conceito que você aprendeu (variáveis, funções, async/await) e explica em voz alta, como se estivesse gravando um vídeo. Não escreve, fala mesmo.
• Escreva em um documento: "closure é quando..." "hoisting é...". Depois lê de volta. Fica natural? Se ler estranho, você ainda não entendeu bem.
• Vê vídeos e artigos que explicam sem decoreba: blogs de pessoas que ensinam com analogia, não com jargão.

O que é: perguntam como você resolveria um problema de design de sistema: "como você faria uma API para listar produtos", "como organizaria o banco de dados de um chat". Assusta porque parece coisa de sênior, mas pra júnior é bem mais simples.

O que avaliam de verdade: não é complexidade, é se você consegue pensar em decisões (por que escolher esse banco de dados, como organizar essa informação). Literalmente é uma conversa sobre suas escolhas, não um exame de memorização.

Como treinar:

• Quando você faz um projeto, anote as decisões: por que escolheu esse framework, por que organizou o banco assim, o que mudaria se fosse pra 1000 usuários.
• Vê o guia Processo seletivo: do CV à entrevista e foca na seção "Perguntas sobre o que você já fez" - é a mesma lógica.
• Desenha no papel: "Cliente → API → Banco de dados". Explica em voz alta. Pronto, é isso.

Pergunte. Serio mesmo. Envie um email pro recrutador: "oi, qual é o formato da etapa técnica? É coding ao vivo, take-home, perguntas de conceito?". Recrutador quer que você chegue preparado, não de surpresa.

Se não conseguir descobrir com antecedência, treina um pouco de cada um, não desespera. Você já conhece os fundamentos, agora é só ajustar o jeito.

Você consegue usar IA pra treinar qualquer um dos formatos:

• Lógica e algoritmos: "me passa um problema fácil de array/string" e vai resolvendo
• Live coding: simula uma entrevista: "vou descrever um problema e você escreve ao vivo enquanto eu observo"
• Take-home: "me passa um projeto pequeno pra fazer em 3 horas, depois você critica o código"
• Conceitos: "fala sobre closure sem pesquisar" e depois IA dá feedback
• System design: "como você estruturaria uma API para...?" e discute as decisões

A IA não substitui a prática, mas é ótima pra não ficar nervoso na primeira vez.

Aqui está o segredo: ninguém espera que você saiba tudo. Se perguntam algo que você não sabe:

• Não finge que sabe (descobrem na próxima pergunta).
• Fala direto: "não sei responder isso, mas gostaria de aprender".
• Se é um conceito que tem ideia: "meu palpite é... mas deixa eu confirmar".
• Se é um detalhe que você esqueceu: "tinha visto isso, mas não lembro de cabeça agora. Sei que existe por que X motivo".

Honestidade técnica é avaliada positivamente. Mostra maturidade: você reconhece seus limites, não disfarça, e quer aprender. Exatamente o tipo de pessoa que as empresas querem no time.

• Você sabe qual formato vai ser? Se não, já enviou o email perguntando?
• Resolveu pelo menos três problemas de lógica fáceis recentemente?
• Praticou explicar um conceito técnico em voz alta (sem ler)?
• Se for live coding: já simulou com alguém, ou pelo menos gravou você mesmo resolvendo?
• Se for take-home: revisou um projeto antigo seu pra ver se o README tá bom?
• Tem exemplos reais de decisões técnicas que tomou em um projeto?
• Sabe que honestidade técnica é mais importante que fingir que sabe tudo?

A maioria do nervoso sai quando você entende as regras do jogo. Entrevista técnica não é teste surpresa: é conversa estruturada sobre como você pensa e como você trabalha. E você aprende isso treinando, não decorando.

Boa sorte.