LeetCode numa entrevista real: por que 400 problemas não salvam
Um padrão que se repete em quase toda história de reprovação: a pessoa já tinha feito exatamente aquele problema. Sabia o truque dos dois ponteiros. Aí o entrevistador disse “pode começar”, e quarenta minutos desapareceram dentro de um editor em branco. O que faltava não era prática — era prática sob observação.
O que muda de verdade na sala
Em casa você resolve com o aparato inteiro: relê as restrições duas vezes, rola até os exemplos, tenta algo, apaga, e ninguém vê o que foi apagado. Não existe um relógio que você sinta. Se travar quatro minutos, os quatro minutos não custam nada.
Na entrevista tudo isso se inverte. O travamento é visível. A linha apagada foi vista. E uma parte grande da sua atenção passa a modelar o que a outra pessoa está pensando de você — atenção que deixou de estar disponível para o problema.
É por isso que quem fez quatrocentos problemas ainda trava no número cento e sete. O problema não é novo. As condições são.
Os primeiros sessenta segundos decidem o resto
A maioria começa a digitar imediatamente, porque o silêncio parece fracasso. É o pior movimento possível: você se compromete com uma abordagem antes de entender o formato da entrada, e quando ela se mostra errada no minuto vinte não há tempo de recuperar.
Quem vai bem gasta o primeiro minuto em voz alta, com três coisas: reformular o problema com as próprias palavras, nomear a restrição que importa e dizer o que está otimizando. “Então preciso de todo par que soma o alvo, o array está ordenado e n pode chegar a cem mil — logo O(n²) está fora.”
Essa frase faz três trabalhos de uma vez: confirma que você entendeu a pergunta, mostra que seu raciocínio está ancorado nas restrições, e compra sessenta segundos de pensamento que soam como competência, não como congelamento.
Dizer “ainda não achei” sem perder a sala
Existe uma versão de estar travado que custa a entrevista e uma que não. A diferença é se o entrevistador consegue ver onde você está.
Travado em silêncio é fatal. Dois minutos de nada, e quem assiste não sabe dizer se você está pensando ou se afogando — então assume o pior.
Travado narrado é sobrevivível e às vezes até pontua. “Brute force is clearly O(n²). I want to trade space for time, and I keep reaching for a hash map — but I haven’t worked out what the key should be yet.” Você acabou de dizer que sabe a direção, sabe o trade-off, e que falta um passo específico. Entrevistadores costumam dar a dica nesse ponto, porque você fez uma pergunta real em vez de desistir.
A parte que não é sobre algoritmo nenhum
Pergunte a quem já conduziu cem entrevistas o que separa um “contrata” de um “não contrata” no mesmo nível técnico, e quase ninguém vai falar da solução ótima. Vão falar de algo sobre ser possível trabalhar com aquela pessoa por quarenta minutos.
Perguntou sobre casos de borda antes de escrever, ou depois de ser avisado? Quando a primeira ideia quebrou, defendeu ou largou? Ao receber uma dica, pegou e seguiu, ou discutiu?
Nada disso está no LeetCode. Tudo isso é avaliado.
Como treinar aquilo que é realmente testado
Resolver mais problemas treina a metade que você já tem. Para treinar a outra, mude as condições em vez do volume.
Resolva em voz alta, sozinho, com cronômetro. Parece absurdo nos primeiros dez minutos e depois deixa de parecer. Se você não consegue narrar seu raciocínio para uma sala vazia, não vai conseguir com um estranho olhando.
Depois pegue problemas que você já resolveu e resolva de novo explicando. O objetivo não é a resposta — você sabe a resposta. O objetivo é a frase que sai enquanto você pensa.
Os três modos de falhar, e a cara de cada um
- O congelamento. Você lê o problema, não vem nada, e o silêncio se acumula: cada segundo torna o próximo mais difícil, porque agora você também está pensando em há quanto tempo está calado. A saída é mecânica, não inspiracional — comece a descrever a força bruta mesmo que seja constrangedor: “The obvious thing is to check every pair, which is O(n²) and too slow, but let me start there and improve it.” Força bruta em voz alta ganha do silêncio sempre, e muitas vezes destrava a solução real porque você começou a se mover.
- O compromisso errado. Você trava numa abordagem no minuto dois, descobre no minuto vinte e cinco que ela não lida com duplicatas, e não sobrou pista. Esse se previne antes: diga o que sua abordagem assume antes de escrever. “This works if the values are unique — is that guaranteed?” O entrevistador responde, e você acabou de desviar da armadilha que ele montou.
- A reescrita silenciosa. Dez minutos dentro, você percebe que a estrutura está errada, seleciona tudo e apaga. De fora isso parece pânico. Narrado, parece critério: “This is getting tangled because I chose the wrong container. I’m going to restart with a heap — two minutes.” Mesma ação, leitura oposta.
Quando você realmente nunca viu aquilo
Às vezes o problema é genuinamente desconhecido e nenhuma narração faz o truque aparecer. Isso acontece com engenheiros fortes e não é reprovação automática.
O que funciona é mostrar como você ataca um problema desconhecido, porque é isso que o trabalho é de fato. Comece pela menor entrada e resolva na mão. Escreva n igual a um, n igual a dois, n igual a três, e olhe o que muda entre eles. Diga o que está fazendo enquanto faz. Padrões emergem de exemplos com muito mais frequência do que de encarar o enunciado — e mesmo quando não emergem, o entrevistador viu você progredir com disciplina sob pressão, que é boa parte do que ele veio descobrir.
A resposta que perde é a invenção confiante: um algoritmo plausível que não funciona, entregue sem ressalva. O entrevistador verifica, aquilo desmorona, e agora ele duvida de tudo o que você disse antes.
Complexidade: diga antes de perguntarem
Quase toda rodada de código termina com alguma versão de “qual é a complexidade?” — e responder só quando provocado é uma perda pequena e evitável. Sinaliza que você não estava pensando em custo enquanto escrevia.
Diga no caminho. Quando pegar um hash map, diga o que ele compra e o que custa: “This makes lookups constant, at the price of O(n) extra space — worth it here because n is large and memory isn’t the constraint.” Agora o trade-off está registrado como decisão sua, não como fato que arrancaram de você.
E se o entrevistador perguntar se dá para melhorar, normalmente não é pegadinha: é convite. A melhor primeira reação é perguntar o que ele quer otimizar — tempo, espaço ou legibilidade. Esses puxam para lados diferentes, e notar isso em voz alta já é sinal.
Onde um copiloto se encaixa
O Interview Copilot escuta a rodada e coloca uma estrutura na sua tela enquanto o entrevistador ainda fala: o que a pergunta está realmente pedindo, a restrição que elimina uma abordagem e o trade-off que vale dizer em voz alta. Não é uma solução para ler — ler solução é evidente para quem está assistindo. É o apoio de onde você fala quando o branco chega e as suas palavras ainda não voltaram.
FAQ
Por que quem faz muito LeetCode ainda reprova?
Porque a sala testa algo que a prática não treina: falar enquanto resolve, lidar com uma dica e se recuperar quando a primeira abordagem falha. São habilidades separadas de produzir uma solução correta sozinho e sem cronômetro.
O que digo quando nunca vi o problema?
Diga isso e comece pela força bruta: “I haven’t seen this one — let me get something working and then improve it.” É normal e esperado; fingir o contrário costuma terminar em silêncio.
Devo dizer a complexidade sem me perguntarem?
Sim. Dizer “this is O(n log n) because of the sort, O(n) space” antes da pergunta preenche uma linha da rubrica e mostra que você pensa em custo, não só em saída.
Travei e deu branco. O que fazer?
Torne a saída mecânica em vez de esperar inspiração: descreva em voz alta a solução mais óbvia, mesmo que seja ingênua. Começar a falar recoloca o raciocínio em movimento; o silêncio só torna o segundo seguinte mais difícil.