Erro nº 1: partir para o código sem esclarecer os requisitos
A pergunta chega. Seu instinto é começar a programar imediatamente para demonstrar velocidade e confiança. Isso quase sempre é um equívoco.
Problemas de entrevista técnica quase nunca são tão simples quanto parecem à primeira vista. Restrições ficam escondidas, casos de borda são deliberadamente omitidos e a interpretação “correta” muitas vezes depende de informações que você ainda não tem. Partir direto para a implementação do problema como você o entendeu — antes de confirmar que entendeu certo — é como candidatos passam 20 minutos resolvendo o problema errado.
Mais importante: entrevistadores deixam requisitos ambíguos de propósito para ver se você reconhece a ambiguidade e faz boas perguntas. Um candidato que pergunta “devo assumir que o array de entrada está ordenado?” antes de programar demonstra o mesmo julgamento que um bom engenheiro leva a projetos reais. Um candidato que assume silenciosamente que o array está ordenado — e constrói tudo em cima disso — demonstra o oposto.
Antes de escrever uma única linha, verbalize seu entendimento do problema e faça pelo menos duas perguntas de esclarecimento: uma sobre restrições (tamanho da entrada, tipos de dados esperados, casos de borda) e uma sobre requisitos (o que a função deve retornar para uma entrada vazia? e se houver duplicados?). Depois confirme: “então meu objetivo é retornar X dado Y — é isso?” Só então comece a programar.
Erro nº 2: ficar em silêncio durante a resolução
Este é o erro que custa mais propostas, porque é invisível para quem o comete. Você está pensando. Com afinco. Está progredindo de verdade. Mas está fazendo tudo isso na sua cabeça, e o entrevistador está observando você digitar em silêncio, sem conseguir saber se você está no caminho certo, completamente perdido ou apenas lento.
Entrevistadores técnicos não avaliam apenas a sua solução — avaliam como seria trabalhar com você. Um colega que emudece diante de um problema difícil é alguém que você não consegue calibrar, ajudar nem colaborar. O candidato silencioso envia exatamente esse sinal, mesmo que a solução final esteja correta.
Pense em voz alta. Diga o que está considerando e por que está descartando: “estou pensando primeiro em uma abordagem de força bruta O(n²) só para estabelecer a corretude, depois vou olhar a otimização.” Diga quando travar: “sei que preciso rastrear quais elementos já vi — estou decidindo entre um hash map e um array ordenado para isso.” Essa narração permite que o entrevistador acompanhe o seu raciocínio, te ajude se você estiver desviando e avalie a sua abordagem independentemente de você chegar ou não à solução ótima.
Se o silêncio é um hábito seu sob pressão, pratique com uma ferramenta de simulado ao vivo — o InterviewAce sinaliza quando você está ficando quieto demais e te lembra de verbalizar o raciocínio.
Erro nº 3: não testar nem depurar a sua solução
Muitos candidatos escrevem a solução, olham brevemente para ela e dizem “acho que está certo” — e entregam. Isso sinaliza que você não tem o instinto de testar o próprio trabalho, que é um dos instintos mais importantes na engenharia de software.
Entrevistadores em empresas fortes costumam ter uma política silenciosa: uma solução que não foi testada pelo candidato é considerada incompleta, independentemente de parecer correta. Eles querem ver você aplicar os mesmos hábitos que levaria a um pull request real.
Depois de escrever a solução, sempre percorra o código manualmente com pelo menos dois casos de teste: um caso normal e um caso de borda. Passe por cada linha, acompanhe os valores das variáveis e verifique a saída. Narre enquanto faz: “ok, se a entrada é [3, 1, 4], neste passo i é 0 e current_max é 3, então...” Esse processo captura bugs reais e demonstra maturidade de engenharia. Para casos de borda, pense sistematicamente em: entrada vazia, entrada com um único elemento, todos os elementos iguais, números negativos (quando aplicável) e o maior tamanho de entrada possível.
Erro nº 4: comunicação fraca em design de sistemas
Entrevistas de design de sistemas diferem das de código em um ponto crucial: não existe uma única resposta correta. O entrevistador avalia o seu processo de raciocínio, a sua consciência dos trade-offs e a sua capacidade de conduzir uma conversa de arquitetura. Candidatos que apresentam um único desenho com confiança, sem explorar alternativas nem reconhecer trade-offs, frequentemente reprovam nessa rodada mesmo quando a arquitetura é tecnicamente sólida.
Modos de falha comuns: pular direto para diagramas de componentes antes de estabelecer requisitos e escala, usar palavras da moda (“vamos usar Kafka para o fluxo de eventos”) sem explicar o raciocínio, e não mencionar trade-offs (“um banco relacional funciona aqui, mas a 10 vezes a escala atual começaríamos a ver contenção de escrita nesta tabela”).
Estruture toda resposta de design de sistemas com a mesma abordagem em cinco passos: (1) esclareça requisitos e restrições — funcionais e não funcionais, expectativas de escala. (2) estime a escala — requisições por segundo, volume de dados, proporção leitura/escrita. (3) proponha um desenho de alto nível — componentes principais, fluxos de dados. (4) aprofunde nas partes interessantes — onde quer que a complexidade esteja. (5) discuta trade-offs e alternativas — o que você escolheu e por que não escolheu as alternativas.
Pratique dizer “escolhi X em vez de Y por causa do trade-off Z” como hábito. Entrevistadores em níveis sênior avaliam se você entende por que o seu desenho faz os trade-offs que faz — não apenas que ele funciona.
Erro nº 5: desistir em vez de pensar em voz alta
Quando candidatos batem em uma parede de verdade — não enxergam o caminho adiante — muitos emudecem, congelam e acabam dizendo “não sei como prosseguir”. Isso encerra a entrevista e elimina a chance de recuperação, mesmo que eles fossem descobrir a saída com mais 2 minutos de raciocínio estruturado.
Eis algo que a maioria dos candidatos não sabe: a maior parte dos entrevistadores quer dar dicas. Eles não estão ali para assistir você fracassar — estão tentando avaliar onde está o seu teto, e um bom entrevistador vai te guiar para além de um bloqueio para ver até onde você chega com apoio. Mas só conseguem ajudar se souberem onde você travou.
Em vez de silenciar quando travar, narre a sua situação: “sei que preciso guardar algum estado entre as iterações, mas não estou vendo de imediato a estrutura de dados certa. Deixa eu pensar em quais propriedades importam aqui...” Isso sinaliza que você continua engajado, dá ao entrevistador a abertura para ajudar e frequentemente destrava a sua própria solução — o ato de articular onde você travou muitas vezes revela a resposta.
Se você realmente precisa de uma dica, peça diretamente e sem constrangimento: “acho que preciso de um empurrão aqui — existe alguma propriedade de estrutura de dados em que eu deveria estar pensando?” Isso é profissional. Ficar em silêncio não é.
Bônus: como se preparar para que esses erros não aconteçam
Conhecer esses erros intelectualmente não impede que eles ocorram sob a pressão da entrevista. É por isso que praticar em condições realistas importa tanto. Alguns princípios de preparação para entrevistas técnicas que funcionam:
- Pratique em um quadro branco ou documento compartilhado, não na sua IDE. Sua IDE tem autocompletar, destaque de sintaxe e retorno instantâneo de erros. Plataformas de entrevista não têm. Pratique sem a rede de segurança para não depender dela.
- Sempre se cronometre. Uma solução que você resolve em 45 minutos relaxado pode levar 20 minutos em uma entrevista — ou pode levar 55. Conheça a sua velocidade real em problemas de dificuldade média antes de estar em um cenário real.
- Faça pelo menos 5 entrevistas simuladas com um humano ou uma IA — não apenas LeetCode sozinho. Os hábitos de comunicação (pensar em voz alta, esclarecer requisitos, testar) precisam ser construídos em prática realista, não em exercícios solitários de código.
- Faça uma análise depois de cada sessão. Qual destes cinco erros você cometeu? Onde você ficou em silêncio? O que assumiu sem perguntar? Cada erro cometido na prática é um erro a menos na entrevista real.
Para prática técnica assistida por IA, o InterviewAce oferece sessões técnicas simuladas em que você pratica pensar em voz alta com uma IA que avalia tanto a sua solução quanto o seu processo de comunicação. Combine com o guia geral de preparação para entrevistas para cobrir também o lado comportamental e a logística.