Dicas de entrevista de programação

Se o seu instinto sob pressão é começar a digitar imediatamente, é exatamente esse instinto que esta seção corrige. Os candidatos mais fortes passam os primeiros minutos sem programar de forma alguma, e os entrevistadores percebem isso.

Comece reformulando o problema com suas próprias palavras e confirme com o entrevistador. Pergunte sobre as restrições: tamanho da entrada, intervalos de valores, se a entrada está ordenada, como tratar entradas vazias ou malformadas. Em seguida, nomeie a abordagem pretendida e sua complexidade antes de escrever qualquer coisa. Essa breve etapa de planejamento detecta mal-entendidos cedo e demonstra pensamento estruturado, o que representa uma grande parte da nota.

O silêncio é a forma mais comum de um bom solucionador de problemas parecer fraco. Mantenha um comentário contínuo do que está escrevendo e por quê, para que o entrevistador possa acompanhar sua lógica e orientá-lo caso se desvie.

Chegue a uma resposta correta antes de uma engenhosa. Uma solução de força bruta simples que funciona vale mais do que uma ideia elegante que nunca compila, e você pode otimizar depois que algo funcionar. Escreva em pequenos trechos testáveis, use nomes de variáveis claros e, se ficar travado, diga o que está considerando em vez de ficar em silêncio. Os entrevistadores costumam dar dicas, mas apenas quando conseguem ouvir onde você está.

Uma solução não está pronta quando compila; está pronta quando você tentou quebrá-la. Percorra seu código com uma entrada normal e depois com entradas deliberadamente hostis: entrada vazia, um único elemento, duplicatas, números negativos, o maior caso permitido pelas restrições.

Considere um engenheiro frontend entrevistando para um cargo de nível intermediário que escreve uma solução de dois ponteiros funcional e, sem ser solicitado, percorre um array vazio e um array de um único elemento, declarando o tempo de execução como O(n). Esse último minuto de autoteste e análise de complexidade muitas vezes separa uma contratação de um talvez, porque sinaliza que o engenheiro identificará seus próprios bugs no trabalho. Diga a complexidade de tempo e espaço em voz alta mesmo sem ser solicitado.

Ler dicas é fácil; executá-las nervoso não é. A solução é o ensaio em condições próximas da real: um cronômetro correndo, sua solução falada em voz alta e sem pausas para pesquisar. Após cada problema de prática, revise não só se você o resolveu, mas se esclareceu, narrou e testou, já que esses são os hábitos avaliados.

Rodadas cronometradas e faladas contra um entrevistador de IA são uma forma de construir esse reflexo; você pode praticá-las na ferramenta de entrevista simulada. Um alerta que vale a pena repetir: rodadas de programação reais costumam ocorrer em um editor compartilhado monitorado ou são gravadas, então nenhum assistente ao vivo é seguro durante elas, e o objetivo da prática é não precisar de um. Mais respostas sobre rodadas de programação estão no hub de tipos de entrevista, e orientação de prática está no hub de entrevistas simuladas.