Entrevista técnica de desenvolvedor: etapas e preparação

Você recebeu um convite para uma entrevista técnica, mas ainda não sabe se vai resolver algoritmos, explicar projetos ou construir uma aplicação? Confirme o formato antes de escolher os exercícios.

A entrevista técnica de desenvolvedor é uma avaliação de como você entende problemas, escreve ou analisa código e justifica decisões relacionadas à vaga. Pode incluir programação ao vivo, conversa sobre experiência, revisão de código e desenho de solução. Este roteiro ajuda a preparar evidências concretas, sem decorar respostas nem tratar um processo seletivo como medida definitiva da sua capacidade.

Quais etapas podem aparecer na entrevista técnica

Não existe uma sequência obrigatória para todas as empresas. Um processo pode começar com recrutamento, seguir para uma avaliação prática e terminar com conversa com a equipe. Outro reúne tudo em uma chamada. Pergunte quais etapas são eliminatórias, quem participa, qual a duração prevista e quando a empresa pretende responder. A resposta orienta sua preparação e permite avaliar se o investimento cabe na sua rotina.

Na conversa inicial, confirme responsabilidades, nível esperado, regime de contratação e faixa salarial. Na triagem técnica, prepare uma apresentação curta de um projeto: problema, sua participação, decisão difícil e resultado que você consegue demonstrar. Projetos acadêmicos e pessoais servem quando você explica suas escolhas, em vez de atribuir a si o trabalho de uma equipe inteira.

Na avaliação prática, o foco pode ser uma função, um defeito ou uma funcionalidade pequena. A conversa posterior costuma explorar o raciocínio por trás da entrega. Em desenho de sistemas, alinhe requisitos e restrições antes de escolher tecnologias. Para uma vaga júnior, não presuma a mesma profundidade exigida de uma pessoa responsável por decisões de arquitetura: peça o recorte esperado.

A orientação pública da Microsoft ilustra um processo específico, não uma regra do mercado: recomenda esclarecer ambiguidades, planejar antes de implementar, usar uma linguagem conhecida e testar a solução. A página menciona rodadas de 45 minutos. Use essas recomendações como exercício, mas confirme o tempo real do seu convite.

Confirme ferramentas, critérios e acessibilidade antes do teste

Envie uma mensagem objetiva: “A etapa envolve programação ao vivo ou entrega assíncrona? Qual é o limite de tempo, quais critérios serão avaliados e posso consultar documentação? Há alguma regra sobre assistentes de IA?” Pergunte também sobre linguagem, ambiente, compartilhamento de tela e possibilidade de executar testes. Não interprete a ausência de proibição como autorização.

Se precisar de adaptação por deficiência, tempo adicional ou uma plataforma acessível, solicite com antecedência e descreva o recurso necessário. Descreva a adaptação sem expor informações médicas desnecessárias. Em entrevista remota, combine como retomar a chamada se a conexão cair.

Teste técnico: o que cada formato mostra e deixa de fora

Programação ao vivo permite observar perguntas, hipóteses e reação a uma mudança de requisito. Também coloca pressão de tempo e exposição, que podem atrapalhar a execução de quem trabalha bem em outras condições. Treine explicar suas decisões sem narrar cada linha de código. Explique o próximo passo, implemente e retome a conversa quando houver uma escolha relevante.

Uma tarefa para fazer em casa permite consultar referências e organizar uma entrega mais próxima da rotina. Em compensação, pode favorecer quem dispõe de mais horas livres. Combine um teto de esforço e registre o que ficou fora dele. Não transforme um exercício pequeno em produto completo para tentar adivinhar critérios invisíveis. No README, explique como executar a solução, quais decisões tomou e o que ficou pendente.

Para praticar essa etapa, veja o guia de teste técnico em TI: live coding e take-home. Ele traz um exercício comentado, um recorte de aplicação e um modelo de README para preparar a entrega.

Revisão de código e depuração são alternativas úteis quando a vaga exige manutenção. Você pode localizar uma falha, propor um teste e explicar o risco da alteração. Essas atividades mostram leitura e priorização, mas não substituem toda avaliação de implementação. Uma conversa sobre portfólio revela contexto e autoria; sozinha, também não demonstra como a pessoa reage a um problema novo.

Nenhum desses formatos mede sozinho colaboração cotidiana, manutenção ao longo de meses ou domínio de todo um produto. Se a tarefa parece uma demanda comercial real, envolve dados de clientes ou exige esforço desproporcional sem critérios, pergunte sobre finalidade, uso da entrega e alternativa. Uma sessão curta de pareamento ou a análise de um projeto existente pode reduzir o custo para os dois lados.

Perguntas de programação e uma resposta comentada

“Como remover registros duplicados?” Antes de programar, confirme as regras da tarefa: “Vou considerar duplicados os registros com o mesmo identificador textual, preservar a ordem e manter a primeira ocorrência. Identificadores diferenciam maiúsculas de minúsculas; um identificador ausente é entrada inválida. Essas hipóteses atendem ao enunciado?” Não escolha o nome como chave: duas pessoas podem ter o mesmo nome. Se a regra fosse manter a versão mais recente, o resultado e a solução precisariam mudar.

Com essas regras confirmadas, explique a solução: “Percorro a entrada na ordem original. Para cada registro, verifico se seu identificador está em um conjunto de identificadores já vistos. Se não estiver, adiciono o identificador ao conjunto e o registro à saída; se estiver, ignoro essa ocorrência.” Na entrada com identificadores A, B, A e C, a saída contém o primeiro A, depois B e C. Se os dois registros A tiverem campos diferentes, o segundo continua descartado: isso decorre de manter a primeira ocorrência, não de comparar todos os campos.

A solução faz uma passagem pelos n registros. Se o conjunto usa uma tabela hash com consulta e inserção de tempo constante esperado, são esperadas O(n) operações, além do trabalho de ler e calcular o hash dos identificadores. O conjunto ocupa O(u) entradas para u identificadores distintos, fora a saída. Identificadores longos custam mais para processar; O(n) aqui não é uma garantia de pior caso. Uma alternativa é comparar cada registro com os já aceitos: evita o conjunto auxiliar, mas pode fazer O(n²) comparações. Ordenar e remover vizinhos pode servir a outro contrato, porém altera a ordem se ela não for restaurada e exige discutir o custo da ordenação.

Para verificar, proponha casos antes de implementar: entrada vazia produz saída vazia; A, A produz só o primeiro A; A, B preserva ambos; A e a permanecem distintos. Um registro sem identificador deve seguir o erro de validação combinado, não virar silenciosamente outro duplicado. Além dos exemplos, confira duas propriedades: nenhum identificador se repete na saída e cada registro retido é a primeira ocorrência da entrada, na mesma ordem relativa. Se o entrevistador pedir igualdade sem distinguir maiúsculas, explicite a nova normalização e seu custo antes de ajustar o conjunto. Confira também se a mudança mantém a primeira ocorrência e a ordem combinadas.

A insatisfação com testes não significa que fundamentos sejam inúteis

Depois do exercício, use o gráfico para preparar uma pergunta à empresa: a avaliação se aproxima das tarefas da vaga? O relatório HackerRank de 2025 registra percepções de uma comunidade global, com respostas distintas, não parcelas de um total. Esses números contextualizam a conversa sobre formato; não invalidam todo teste de algoritmo nem descrevem o processo de uma empresa brasileira.

A metodologia combina dados da plataforma com uma pesquisa de desenvolvedores, estudantes, recrutadores e lideranças em 102 países. Os percentuais deste gráfico vêm da pesquisa, não de admissões observadas. O fornecedor vende soluções de avaliação e sua comunidade não representa automaticamente todas as pessoas desenvolvedoras. Não use esses números como probabilidade de aprovação ou contagem de vagas no Brasil.

Revise estruturas de dados quando o formato exigir e pratique escolher uma para cada problema. Um conjunto pode ajudar a identificar valores repetidos; um mapa pode associar identificadores a registros. Explique custos de memória e operações esperadas. Ao mudar um requisito, confira se a estrutura continua adequada.

Como se preparar para entrevista técnica em cinco sessões

Use as sessões abaixo como proposta de organização, não como prazo obrigatório. Se a entrevista estiver próxima, priorize o formato confirmado e uma simulação completa. Se ainda estiver buscando oportunidades, escolha duas descrições em vagas de tecnologia e identifique os fundamentos recorrentes. Use os requisitos comuns para escolher o que revisar primeiro.

1. Mapeie a avaliação. Separe responsabilidades reais, requisitos essenciais e assuntos que ainda precisa confirmar. Abra dois projetos seus e escolha qual mostra melhor o trabalho pedido.
2. Revise os fundamentos relevantes. Para uma vaga web, pratique HTTP, estado, tratamento de erros, dados e testes conforme o anúncio. Resolva poucos exercícios e explique por que a solução funciona.
3. Simule o formato. Reproduza a ferramenta e o tempo informados, sem atalhos que estarão proibidos. Grave apenas seu treino, se isso ajudar, e observe pausas, dúvidas e tempo gasto.
4. Revise a entrega como outra pessoa. Comece pelas instruções de execução, depois confira comportamento normal, entrada vazia, limites e falhas. Anote decisões que precisariam de contexto.
5. Refaça o ponto mais fraco. Prepare perguntas para a equipe e organize ambiente, conexão e agenda. Não troque uma boa noite de descanso por uma sequência de assuntos novos na véspera.

Em um treino de depuração, por exemplo, escolha um defeito pequeno de um projeto próprio. Reproduza o erro, escreva a hipótese e tente reduzir o caso antes de alterar o código. Depois, explique a causa da falha e por que a alteração a corrige. Essa sequência ajuda a contar a experiência sem decorar um relato.

Use IA para treinar, respeitando as regras da avaliação

Um assistente pode gerar perguntas, apontar lacunas em uma explicação e atuar como entrevistador no treino. Peça uma pergunta por vez e responda antes de solicitar avaliação. Depois confira a correção em documentação confiável. Ler uma resposta pronta e reconhecê-la como familiar não demonstra que você consegue reconstruir o raciocínio sem ajuda.

No exercício de duplicados, peça ao assistente uma entrada que contrarie sua hipótese; depois feche a ferramenta e resolva a variação sozinho. Confira se ainda consegue justificar igualdade, ordem e custo. O gráfico abaixo contextualiza esse uso como recurso de estudo no relatório HackerRank 2025, não como recomendação de produto: mostra uso declarado entre usuários de cada ferramenta, com grupos diferentes e possivelmente sobrepostos. Não mede qual ensina melhor nem a eficácia desse treino.

Durante a conversa, mostre como decide e como aprende

Ao receber o problema, repita o objetivo com suas palavras, apresente um exemplo e confirme restrições. Proponha a solução mais simples que atende ao recorte. Se travar, descreva onde está a dúvida e reduza a entrada. Pedir um esclarecimento específico preserva a conversa; fingir que entendeu pode levar você a resolver outra tarefa.

Reserve tempo para executar a solução e mostrar seus limites. Se não terminar, apresente o que funciona, o que falta e o próximo passo verificável. No fim, pergunte como a equipe revisa código, acompanha quem está entrando e decide prioridades. Você também está avaliando as condições em que precisará entregar trabalho.

Depois, registre duas observações: um conhecimento a reforçar e um ajuste no modo de comunicar. Solicite retorno sem presumir que haverá resposta detalhada. Uma reprovação não identifica sozinha sua lacuna, pois envolve critérios, concorrência e decisões internas que você não conhece. Antes da próxima oportunidade, refaça o exercício em que travou e anote o que agora consegue explicar.