Entrevista de emprego para desenvolvedor: guia completo 2026

Entrevista de emprego para desenvolvedor: etapas, perguntas comuns, teste técnico, live coding e respostas comportamentais com o método STAR.

Este conteúdo é independente. Alguns links são de parceiros (marcados com ↗): se você comprar por eles, o Mobgeek pode ganhar uma comissão sem custo extra para você.

Uma entrevista de emprego para desenvolvedor costuma ter quatro etapas: triagem com recrutador, avaliação técnica (teste para casa ou live coding), conversa com o time ou gestor e entrevista comportamental. Para passar, você precisa de duas coisas que pouca gente treina: pensar em voz alta durante a parte técnica e contar histórias concretas na parte comportamental, de preferência no formato STAR.

A boa notícia é que entrevista é uma habilidade treinável, separada de programar. Muita gente boa reprova por falta de prática, não por falta de conhecimento. Vamos etapa por etapa.

As etapas de um processo seletivo típico

Nem toda empresa segue essa ordem, e startups pequenas às vezes resolvem tudo em duas conversas. Pergunte logo na triagem: "como são as próximas etapas?". É uma pergunta normal e te ajuda a se preparar.

Antes da entrevista: a preparação que faz diferença

1. Leia a vaga com atenção e marque as três ou quatro tecnologias e responsabilidades centrais. Prepare um exemplo seu para cada uma.
2. Pesquise a empresa: o que vende, quem são os clientes, se tem blog técnico, notícias recentes.
3. Revise seus próprios projetos. Parece óbvio, mas muita gente trava ao explicar o próprio código de um ano atrás.
4. Prepare de 5 a 7 histórias no formato STAR (mais abaixo) que você possa adaptar para várias perguntas.
5. Defina sua pretensão salarial com antecedência. Leia quanto ganha um programador e, se a vaga for PJ, faça a conta na calculadora CLT x PJ para não aceitar um valor que parece alto mas vira pouco no fim do mês.
6. Teste o setup se for remoto: câmera, microfone, internet, compartilhamento de tela e o editor que você vai usar.

Triagem com recrutador: não subestime

A triagem é onde mais gente é cortada sem perceber. O recrutador quase nunca é técnico, então seu objetivo é ser claro e objetivo.

Perguntas comuns:

• "Me fala um pouco sobre você." → Responda em 1 a 2 minutos: quem você é profissionalmente, o que faz hoje, o que está buscando e por que essa vaga. Não conte a vida desde a escola.
• "Por que você quer sair do emprego atual?" → Fale do que você busca, não do que você odeia. Nunca fale mal da empresa atual.
• "Qual sua pretensão salarial?" → Dê uma faixa e o modelo (CLT ou PJ). Se puder, pergunte antes qual é a faixa da vaga.
• "Quando poderia começar?" → Seja honesto sobre aviso prévio.

Teste técnico para casa (take-home)

É um projeto que você faz no seu tempo, geralmente em alguns dias. O que diferencia um teste aprovado de um reprovado quase nunca é a funcionalidade — é o capricho.

O que os avaliadores olham:

• README explicando como rodar, decisões tomadas e o que você faria com mais tempo.
• Testes automatizados, mesmo que poucos e focados no essencial.
• Organização clara de pastas e nomes.
• Commits pequenos e com mensagens decentes, mostrando o caminho.
• Escopo respeitado. Não entregue uma arquitetura de microserviços para um CRUD de três telas. Simplicidade bem feita impressiona mais.

Atenção: sobre IA no teste, pergunte se é permitido. Se for, mencione no README como usou. Se não for, não use. Em ambos os casos, a etapa seguinte costuma ser uma conversa sobre o código, e quem não entende o que entregou é eliminado ali.

Uma regra pessoal saudável: se o teste exige mais de um fim de semana inteiro de trabalho para uma vaga júnior ou pleno, é razoável perguntar se há uma versão menor ou desistir. Seu tempo também vale.

Live coding: como não travar

Live coding é resolver um problema ao vivo, compartilhando a tela, com o entrevistador assistindo. Dá nervoso em todo mundo — inclusive em sênior. O segredo é ter um roteiro:

1. Repita o problema com suas palavras e confirme que entendeu.
2. Pergunte sobre os limites: a entrada pode ser vazia? Tem números negativos? Qual o tamanho esperado?
3. Faça um exemplo à mão antes de escrever código.
4. Proponha primeiro a solução mais simples, mesmo que ineficiente. "Eu faria assim com força bruta, depois otimizamos."
5. Pense em voz alta o tempo todo. Silêncio é o pior inimigo. O entrevistador precisa ver seu raciocínio.
6. Teste com os exemplos quando terminar, incluindo casos de borda.
7. Fale da complexidade (tempo e memória) e de como melhoraria.

O que estudar para live coding

Não precisa virar máquina de LeetCode para a maioria das vagas no Brasil. Domine:

• Arrays, strings e manipulação básica.
• Hash maps (objetos/dicionários) — resolvem metade dos problemas.
• Ordenação e busca binária.
• Recursão simples.
• Noção de complexidade (Big O).

Entendendo Algoritmos cobre quase tudo isso com uma didática ótima. Para praticar, resolva alguns problemas fáceis e médios por semana, sempre falando em voz alta, como se tivesse alguém assistindo. Parece bobo, mas é exatamente isso que você vai fazer na entrevista.

Empresas grandes e vagas internacionais costumam cobrar mais algoritmos. Se é o seu alvo, veja também o guia de como trabalhar para o exterior.

Entrevista técnica com o time

Aqui a conversa é mais aberta. Perguntas frequentes:

• "Me explica um projeto que você fez e as decisões técnicas." → Fale do problema, das alternativas que você considerou e por que escolheu a sua.
• "Como funciona [conceito da stack]?" → Por exemplo: event loop no JavaScript, ciclo de vida de componentes no React, índices em banco de dados, diferença entre autenticação e autorização.
• "O que acontece quando digito uma URL no navegador?" → Clássico. DNS, TCP/TLS, requisição HTTP, servidor, resposta, renderização.
• "Como você debuga um problema em produção?" → Logs, reprodução, isolamento, hipótese, correção, prevenção.
• "Como você usa IA no seu trabalho?" → Pergunta cada vez mais comum em 2026. Seja específico: onde ajuda, onde você não confia e como revisa o que foi gerado.

"Não sei" é uma resposta aceitável, desde que venha com "mas eu pensaria assim..." ou "nunca usei, mas imagino que funcione parecido com X". Inventar resposta é muito pior do que admitir.

Perguntas comportamentais e o método STAR

As perguntas comportamentais começam com "me conte uma vez em que...". Elas partem da ideia de que o seu comportamento passado prevê o futuro. A pior resposta é a genérica ("eu sempre procuro me comunicar bem"). A melhor é uma história concreta.

O método STAR organiza essa história:

• S — Situação: o contexto, em uma ou duas frases.
• T — Tarefa: qual era a sua responsabilidade.
• A — Ação: o que você fez (use "eu", não "a gente"). É a parte mais longa.
• R — Resultado: o que aconteceu, de preferência com algo mensurável, e o que você aprendeu.

Exemplo de resposta STAR

Pergunta: "Me conte sobre uma vez em que você errou."

S: No meu último projeto, eu era responsável pela integração com um sistema de pagamentos. T: Precisava subir uma mudança que alterava o formato de envio dos dados. A: Testei só no ambiente local e fiz o deploy numa sexta à tarde. Alguns pagamentos começaram a falhar. Eu avisei o time imediatamente, reverti a mudança e investiguei. A causa era uma diferença de configuração entre os ambientes. Depois, escrevi um teste de integração para esse caso e propus que mudanças em pagamento passassem por homologação antes. R: O problema foi resolvido no mesmo dia, o time adotou a regra de homologação e não tivemos de novo esse tipo de falha. Aprendi a não confiar só no meu ambiente.

Repare: o erro é real, a responsabilidade é assumida e o foco está no que foi feito depois.

Perguntas comportamentais mais comuns

• Conte sobre um conflito com um colega e como resolveu.
• Conte sobre um prazo que você não ia conseguir cumprir.
• Conte sobre algo que você aprendeu rápido para resolver um problema.
• Conte sobre uma decisão técnica com a qual você discordou.
• Conte sobre o projeto de que você mais se orgulha.
• Conte sobre um feedback difícil que você recebeu.

Se você vem de outra área, use histórias da carreira anterior sem medo. Conflito, prazo e erro existem em qualquer profissão.

System design (para pleno e sênior)

Nessa etapa, pedem algo como "desenhe um encurtador de URLs" ou "como você faria o feed de uma rede social". Não existe resposta certa. Avaliam se você:

1. Faz perguntas para entender requisitos e escala.
2. Começa simples e evolui o desenho.
3. Fala de trade-offs (consistência x disponibilidade, cache, filas, banco relacional x não relacional).
4. Sabe onde o sistema quebra primeiro.

As perguntas que você deve fazer

No fim, quase sempre perguntam: "alguma dúvida?". Nunca diga "não". Boas perguntas:

• Como é um dia típico de alguém nessa função?
• Como funciona o processo de code review e deploy?
• Como é medido o desempenho e como funciona a promoção?
• Qual o maior desafio técnico do time hoje?
• Por que a vaga está aberta?

Essas respostas também te dizem se você quer trabalhar lá.

Depois da entrevista

• Mande um agradecimento curto ao recrutador.
• Anote o que perguntaram e onde você foi mal. Vira material de estudo.
• Se reprovar, peça feedback. Nem sempre vem, mas quando vem, vale ouro.
• Se receber proposta, não aceite na hora. Peça tudo por escrito e compare com calma, inclusive benefícios. A calculadora de salário líquido ajuda a ver o valor real de uma proposta CLT.

Entrevista é jogo de repetição. As primeiras vão ser ruins, e está tudo bem. Se você ainda está construindo a base para chegar até aqui, comece pelo guia de como ser programador em 2026.