Entrevistas de Java têm fama de cobrar curiosidades, e parte dessa fama é merecida. As boas já superaram isso. O que uma banca competente testa hoje é se você entende o que o runtime está fazendo por baixo do seu código: para onde foi a memória, por que aconteceu a pausa, o que o framework gerou no seu lugar e o que quebra quando duas threads chegam na mesma linha ao mesmo tempo. Aqui estão as perguntas que não param de aparecer, o que cada uma investiga e como uma resposta forte é construída.
Esses são os padrões da vaga em geral; se você quer a lista curta de uma entrevista específica, cole o anúncio real da vaga no Question Predictor gratuito e receba as vinte perguntas com maior chance de cair naquele processo.
O que as entrevistas de desenvolvedor Java realmente avaliam?
Cinco áreas, com bastante consistência: comportamento da JVM e de memória, garbage collection, o framework de collections em detalhe de verdade, concorrência e o framework em que o time vive, que é quase sempre Spring. Por baixo de tudo tem uma pergunta que ninguém diz em voz alta: quando este serviço der problema em produção às 2 da manhã, você vai conseguir descobrir por quê?
A profundidade escala forte com a senioridade. Um júnior precisa de mecânica correta; um pleno precisa de trade-offs e diagnóstico; de um sênior se espera raciocínio sobre dimensionamento de heap, escolha de coletor e configuração de thread pool, com histórias de produção anexadas. Uma coisa mudou de verdade: boilerplate é de graça agora, então as bancas gastam menos tempo pedindo que você escreva um builder e mais tempo perguntando por que uma transação não fez rollback.
Como é o processo de entrevista de Java?
Um processo típico tem de quatro a seis etapas: triagem com recrutador, uma triagem técnica misturando código com fundamentos, uma rodada de código mais longa, uma rodada de design e uma conversa com o gerente de contratação. Grandes empresas e consultorias se apoiam em fundamentos e Spring; empresas de produto pesam mais design e concorrência. Desafios para casa são comuns em empresas de médio porte e normalmente envolvem um pequeno serviço Spring.
- Triagem com o recrutador (20 a 30 minutos). Versão, framework, escala, faixa salarial. Saiba qual versão de Java a sua base de código usa, porque dizer "a mais recente" e depois não saber o que é um record acaba mal.
- Triagem técnica (45 a 60 minutos). Código num editor compartilhado, mais fundamentos em ritmo rápido: collections, exceções, imutabilidade, streams.
- Rodada de código (60 minutos). Um problema prático em vez de um quebra-cabeça: parsear e agregar um arquivo, implementar um cache pequeno, escrever um contador thread-safe.
- Rodada de design (60 minutos). Design de serviço ou um exercício orientado a objetos, com capacidade e modos de falha adicionados nos processos de nível sênior.
- Rodada de framework e profundidade. Comportamento do Spring, transações, testes e às vezes um exercício de revisão em que você critica uma classe deliberadamente falha.
- Gerente de contratação ou comportamental. Incidentes, divergências, mentoria e se o nível que você diz ter sobrevive ao detalhe.
Se você conhece a empresa, os bancos de perguntas por empresa dão uma leitura mais rápida do estilo da casa do que vasculhar fóruns, já que as grandes consultorias em especial seguem um roteiro consistente.
Que perguntas sobre JVM e memória você deve esperar?
Espere explicar o caminho do código-fonte até o código rodando e as regiões de memória onde seus objetos vivem. A banca está checando se a JVM é uma caixa-preta para você. Cubra a compilação para bytecode, o carregamento de classes, a interpretação seguida de compilação just-in-time dos caminhos quentes, e a divisão entre heap, pilhas de thread e metaspace, sem virar um recital.
Me explique o que acontece entre escrever uma classe e ela rodar. O que investiga: se você entende o runtime em que faz deploy. Vá em ordem: o javac produz bytecode, o class loader carrega e liga (vale citar a delegação para o pai), o interpretador começa a executar e o compilador JIT otimiza métodos quando eles ficam quentes, com inlining e desotimização como comportamentos reais.
Explique as áreas de memória da JVM. O que investiga: se você sabe localizar um problema de memória. O heap guarda objetos e é onde acontece a coleta; cada thread ganha uma pilha para frames e variáveis locais; o metaspace guarda metadados de classe fora do heap. Memória nativa usada por buffers fica fora de todos eles, e é por isso que um contêiner pode ser morto enquanto o heap parece saudável.
Como você diagnosticaria um OutOfMemoryError em produção? O que investiga: experiência operacional real. Pergunte primeiro qual OutOfMemoryError, já que falhas de heap space, metaspace e criação de thread têm causas diferentes. Depois capture um heap dump no erro, inspecione a dominator tree para ver o que segura o conjunto retido e olhe os logs de GC procurando crescimento constante versus um pico.
Que perguntas sobre garbage collection aparecem?
Perguntas de GC testam se você consegue raciocinar sobre tempo de pausa contra throughput. Comece pela hipótese geracional (a maioria dos objetos morre jovem), explique que coletas jovens são baratas e coletas completas não são, e trate a escolha de coletor como decisão de requisito, não como preferência pessoal. Nunca afirme que uma flag de tuning resolve um problema que você não mediu.
Como o garbage collection funciona de verdade? O que investiga: mecânica, não vocabulário. Descreva alcançabilidade a partir das GC roots em vez de contagem de referências, a divisão entre geração jovem e velha, coletas menores promovendo sobreviventes e pausas stop-the-world como a coisa que realmente dói.
Como você escolhe entre os coletores disponíveis? O que investiga: se você casa a ferramenta com uma meta de latência. O G1 é o padrão sensato para a maioria das cargas de servidor e mira numa meta de pausa. ZGC e Shenandoah trocam throughput por pausas muito baixas em heaps grandes, o que importa quando 300ms estoura o seu orçamento.
Seu serviço mostra pausas de 400ms no percentil 99. Como você ataca isso? O que investiga: disciplina de medição. Ligue o log de GC e confirme que as pausas são mesmo de GC antes de mexer em qualquer coisa, já que contenção de lock e chamadas lentas a serviços externos produzem caudas parecidas. Se for GC, olhe primeiro a taxa de alocação, porque a maioria dos problemas de pausa é problema de alocação.
Que perguntas sobre collections em Java são feitas?
Collections é o filtro mais confiável do processo, porque todo mundo diz que conhece e poucos conseguem explicar os internals. Esteja pronto para descrever como o HashMap é implementado, por que o contrato entre equals e hashCode não é opcional, quando uma LinkedList é genuinamente a escolha certa (raramente) e como as collections concorrentes diferem de um wrapper sincronizado.
Como o HashMap funciona por dentro? O que investiga: profundidade. Cubra o hash da chave, o espalhamento dos bits, a indexação num array de buckets, o encadeamento de colisões numa lista que vira uma árvore balanceada quando o bucket cresce demais, e o redimensionamento no fator de carga com rehash para um array maior.
Qual é o contrato entre equals e hashCode, e o que quebra se você violá-lo? O que investiga: se você já depurou isso. Objetos iguais precisam devolver hash codes iguais; objetos diferentes podem colidir. Quebre isso e um objeto colocado num HashSet fica impossível de achar, porque a busca vai para o bucket errado.
ArrayList ou LinkedList: quando você realmente usaria LinkedList? O que investiga: se você repete complexidade de livro didático ou pensa no hardware. O Big O favorece a LinkedList na inserção, mas o ArrayList ganha na prática em quase toda carga, porque memória contígua é amigável ao cache e perseguir ponteiros não é. A LinkedList é defensável principalmente como deque, e o ArrayDeque costuma ganhar dela até aí.
ConcurrentHashMap ou um mapa sincronizado: qual a diferença? O que investiga: entendimento de contenção. Um wrapper sincronizado serializa toda operação num único lock; o ConcurrentHashMap permite leituras concorrentes e escritas com locks segmentados, dando throughput muito melhor sob carga.
Que perguntas sobre concorrência os entrevistadores de Java fazem?
Concorrência separa pleno de sênior mais rápido que qualquer outro tema. Espere visibilidade versus atomicidade, configuração de thread pool, deadlock e, cada vez mais, virtual threads. As melhores respostas fogem da abstração: descreva a falha concreta, uma leitura obsoleta, uma atualização perdida ou um pool esgotado por tarefas bloqueadas, em vez de recitar definições de palavras-chave.
O que o volatile garante, e o que ele não garante? O que investiga: o modelo de memória. O volatile garante visibilidade e ordenação: uma escrita é vista pelas outras threads e o reordenamento em torno dela é restrito. Ele não garante atomicidade, então incrementar um contador volatile continua sendo um bug de atualização perdida, porque ler, somar e escrever são três operações.
Como você dimensiona um thread pool, e o que há de errado com os métodos de fábrica de conveniência? O que investiga: se você já viu um pool falhar. Um pool fixo criado pela fábrica de conveniência usa uma fila ilimitada, então sob sobrecarga ele acumula tarefas até o heap morrer em vez de empurrar de volta. Monte explicitamente, com fila limitada e política de rejeição, dimensionado pelo tipo de carga.
O que causa um deadlock e como você o previne? O que investiga: precisão mais praticidade. Deadlock precisa de exclusão mútua, segurar e esperar, ausência de preempção e espera circular, e você o quebra removendo uma dessas condições, normalmente com uma ordem global de locks.
Para que servem as virtual threads, e quando elas não ajudam? O que investiga: se você está atualizado. Elas tornam IO bloqueante barato, então você escreve código bloqueante direto em alta concorrência em vez de contorcê-lo em cadeias assíncronas. Elas não aceleram trabalho limitado por CPU, e colocá-las num pool destrói o propósito.
Que perguntas sobre Spring e Spring Boot aparecem?
Perguntas de Spring testam se você entende o que o framework gera para você. Espere fundamentos de injeção de dependência, como a auto-configuração decide o que instanciar, comportamento de transações e tratamento de erros numa camada REST. A pergunta sobre transação é o filtro sênior clássico, porque as formas de uma anotação silenciosamente não fazer nada são exatamente as formas como bugs reais chegam à produção.
Explique injeção de dependência e por que a injeção por construtor é preferida. O que investiga: se você entende inversão de controle ou só anota as coisas. A injeção por construtor deixa as dependências explícitas e obrigatórias, permite campos final e torna a classe testável sem contêiner. A injeção por campo esconde dependências, deixa referências circulares passarem despercebidas e precisa de reflexão para testar.
Como o @Transactional funciona de verdade, e quando ele silenciosamente não se aplica? O que investiga: proxies. O Spring embrulha o bean num proxy que abre e faz commit de uma transação em volta da chamada, o que significa que a auto-invocação (um método chamando outro método anotado na mesma classe) contorna o proxy inteiro e roda sem transação nenhuma.
O que a auto-configuração está fazendo? O que investiga: se a mágica é entendida ou temida. O Spring Boot avalia configuração condicional contra o que está no classpath e o que você já definiu, então adicionar uma dependência instancia padrões sensatos e declarar o seu próprio bean desliga o padrão. O relatório de condições mostra exatamente o que casou, e é o jeito mais rápido de explicar um bean surpreendente.
Como você trata erros numa API REST em Spring? O que investiga: consistência. Centralize com um controller advice que mapeia tipos de exceção para códigos de status e um corpo de erro estável, mantenha stack traces fora das respostas e separe direito erros de cliente de erros de servidor.
Que perguntas de linguagem e design ainda são feitas?
Espere um punhado de perguntas de linguagem usadas como calibragem: exceções, imutabilidade e as adições recentes. Mantenha as respostas curtas e práticas. A banca está checando se as suas opiniões vêm do uso ou foram decoradas, então amarre cada uma a uma decisão que você realmente tomou numa base de código.
Exceções checadas ou não checadas: qual é a sua posição? O que investiga: bom gosto em design de API. Exceções checadas forçam quem chama a tratar uma condição recuperável, mas poluem assinaturas e acabam engolidas na prática, e é por isso que a maioria das bases de código modernas prefere exceções não checadas com uma fronteira clara que as traduz.
Que problema records e sealed types resolvem? O que investiga: se você acompanha a linguagem. Records dão carregadores de dados imutáveis e concisos, com equals, hashCode e toString gerados, eliminando uma classe inteira de bugs escritos à mão. Sealed types restringem as implementações permitidas, o que torna o pattern matching em switch exaustivo e verificado em tempo de compilação.
Que erros afundam candidatos de Java?
Quase todos são falhas de profundidade. As bancas de Java sondam dois ou três níveis abaixo da definição, então quem decorou vocabulário mas nunca leu um heap dump ou um thread dump é desmascarado na pergunta de aprofundamento, não na primeira resposta. Estes são os padrões recorrentes.
- Recitar definições sem mecânica. "O volatile deixa thread safe" não cola. Diga o que ele garante e o que não garante.
- Ignorar o runtime. Um candidato que não sabe descrever para onde vai a memória ou o que causa uma pausa não consegue depurar produção, por mais limpo que seja o código dele.
- Tratar o Spring como mágica. Não saber que transações funcionam via proxies é a lacuna mais comum em nível sênior.
- Complexidade de livro em vez de comportamento real. A resposta sobre LinkedList tirada direto do livro didático sinaliza alguém que nunca mediu nada.
- Ficar em silêncio enquanto coda. As bancas estão comprando o seu raciocínio. Narre a abordagem, os casos de borda e o trade-off enquanto digita.
- Conhecimento desatualizado. Se o time está numa LTS atual e você nunca ouviu falar de records ou virtual threads, soa como alguém que parou de aprender.
Como se preparar para uma entrevista de Java?
Escolha as três áreas que a banca vai sondar com certeza (internals de collections, concorrência e o framework que a descrição da vaga cita) e leve-as ao ponto de conseguir explicar sem consultar nada. Leia os logs de GC e um thread dump do seu próprio serviço pelo menos uma vez, para essas respostas virem de experiência e não de leitura. Depois ensaie duas histórias de produção, uma sobre memória ou latência e uma sobre uma divergência.
Antes do processo em si, cole o anúncio real da vaga no Question Predictor gratuito e passe pelas vinte perguntas que ele aponta para aquela vaga específica, porque um time de trading de baixa latência e uma casa corporativa de Spring compartilham a linguagem e quase mais nada.
Para as rodadas ao vivo, o GhostPilot é um copiloto de entrevista em tempo real: um painel lateral de extensão do Chrome e um app de desktop opcional para Windows que transcrevem a chamada, pegam a pergunta assim que ela cai e têm uma resposta estruturada pronta uns dois segundos depois. Ele ajuda mais nas perguntas com armadilha dentro, como a de transação. É um empurrão, não um roteiro, e o detalhe de produção ainda tem que vir de você. O plano gratuito te dá 10 minutos de entrevista ao vivo por semana, sem cartão.
FAQ de entrevista de Java
Quanto tempo devo me preparar para uma entrevista de desenvolvedor Java? Duas a três semanas para uma vaga de nível pleno se você escreve Java todo dia: uma semana em fundamentos e collections, uma semana em concorrência e comportamento do framework, alguns dias nas histórias.
Que versão de Java eu preciso saber para entrevistas em 2026? Saiba a LTS que a empresa alvo roda e o que as versões recentes acrescentaram, em especial records, sealed types, pattern matching em switch e virtual threads. Muitas empresas grandes ainda estão numa LTS mais antiga, então seja honesto sobre o que você de fato usou.
Quanto de Spring eu preciso? Se a vaga menciona Spring, trate como tema de primeira classe, não como nota de rodapé. Injeção de dependência, auto-configuração, transações e testes aparecem em quase todo processo com Spring, e a pergunta sobre transação é onde os candidatos mais perdem a rodada.
Devo admitir quando não sei alguma coisa? Sim. "Eu nunca ajustei esse coletor em produção, mas é assim que eu abordaria e o que eu mediria primeiro" ganha de uma resposta errada dita com confiança. As bancas de Java sondam dois ou três níveis nas perguntas de aprofundamento, então blefe desaba rápido.