Como Avaliar um Desenvolvedor Java: Guia para RH e TI

Este artigo faz parte do nosso Guia Completo de Avaliação Técnica de TI.

Java continua sendo a espinha dorsal de sistemas bancários, ERPs, marketplaces de grande porte e boa parte do backend corporativo brasileiro — o que significa que “sabe Java” cobre um espectro enorme, de quem só sabe implementar uma interface até quem entende profundamente como a JVM gerencia memória e concorrência sob carga. Isso torna a entrevista traiçoeira para quem não é técnico: candidatos citam Spring Boot, microsserviços e design patterns com a mesma fluência, mas a diferença real aparece só quando você sabe o que perguntar. Este guia existe para isso.

Habilidades Técnicas por Nível de Senioridade

Júnior
Domina a sintaxe da linguagem e os fundamentos de orientação a objetos (herança, polimorfismo, interfaces, encapsulamento). Já trabalhou com Spring Boot em nível básico — criar um endpoint REST, injetar uma dependência, persistir dados com Spring Data JPA — mas normalmente segue tutoriais e padrões prontos sem entender totalmente o “porquê” por trás deles. Conhece Collections (List, Map, Set) só na superfície, sabe escrever testes unitários simples com JUnit, mas ainda tropeça em conceitos como null safety, tratamento de exceções em cascata ou o que realmente acontece quando uma exception não é tratada numa thread separada.

Pleno
Já projetou e manteve APIs REST em produção, entende o ciclo de vida de um bean no Spring (singleton vs. prototype, injeção por construtor vs. campo) e sabe por que isso importa. Trabalha com JPA/Hibernate além do básico — entende lazy vs. eager loading, o problema de N+1 queries e como evitá-lo. Tem familiaridade real com concorrência: sabe o que é uma race condition, já usou (ou pelo menos entende) ExecutorService, CompletableFuture ou os básicos de streams paralelas. Escreve testes de integração, não só unitários, e geralmente já foi responsável por debugar um problema de performance real em produção — não só em teoria.

Sênior
Pensa em arquitetura antes de pensar em código: sabe quando um monólito bem estruturado é melhor que microsserviços prematuros, e defende essa opinião com trade-offs concretos, não modismo. Entende profundamente a JVM — garbage collection (e quando cada tipo de GC importa), memory leaks comuns em aplicações Java de longa duração, tuning de heap. Lidera decisões sobre resiliência (circuit breakers, retries, timeouts em chamadas entre serviços), observabilidade (logs estruturados, métricas, tracing distribuído) e geralmente tem opinião formada e defensável sobre reactive programming (WebFlux) versus modelo tradicional blocking — inclusive sobre quando reactive é a escolha errada, não a mais moderna.

Faixas Salariais de Desenvolvedores Java

Com base nos processos de recrutamento conduzidos pela HUNT IT no mercado brasileiro, as faixas salariais para desenvolvedores Java variam principalmente pela senioridade:

• Júnior: R$ 3.000 a R$ 6.000 por mês
• Pleno: R$ 6.000 a R$ 12.000 por mês
• Sênior: a partir de R$ 12.000 por mês

Esses valores variam por região, stack específico (ex: experiência com sistemas de alta escala ou setores como bancário/fintech tende a puxar a faixa pra cima) e modelo de contratação (CLT vs. PJ).

Avaliação de Código Prático: O Teste do Vazamento de Conexão

Um teste eficaz para Java não precisa ser um algoritmo abstrato de lista encadeada — o que você quer descobrir é se o candidato entende o que acontece quando o código dele roda sob carga real, por horas, em produção. O “Teste do Vazamento de Conexão” resolve isso.

Apresente um trecho de código (real ou fictício) de um serviço Spring Boot que abre uma conexão com um recurso externo — pode ser um banco via JDBC puro, um client HTTP, ou um stream de arquivo — dentro de um método de um service, sem usar try-with-resources e sem fechar a conexão no bloco finally. O código “funciona” nos testes locais e até em produção por um tempo, mas com carga crescente a aplicação começa a lançar erros de connection pool esgotado ou, em casos piores, o processo morre por OutOfMemoryError.

Peça para o candidato:

1. Identificar o problema olhando só para o código (sem rodar nada);
2. Explicar por que isso não aparece imediatamente nos testes — o que muda sob carga sustentada;
3. Corrigir o código usando try-with-resources ou o padrão apropriado ao contexto (ex: fechamento correto de um connection pool gerenciado pelo Spring);
4. Sugerir como isso poderia ter sido pego antes de chegar em produção (ferramentas de análise estática, testes de carga, revisão de code review).

Um júnior geralmente identifica que “algo está errado” mas tem dificuldade em explicar o mecanismo exato. Um pleno resolve rápido e sabe explicar o “porquê” do vazamento. Um sênior, além de corrigir, já puxa a conversa para prevenção sistêmica — linting, ferramentas como SonarQube, ou padrões de arquitetura que tornam esse tipo de erro menos provável de acontecer de novo.

4 Perguntas Técnicas Cruciais para a Entrevista

1. “Qual a diferença entre `==` e `.equals()` em Java, e por que isso importa especialmente com Strings e objetos wrapper como Integer?”
Uma resposta fraca fica só na definição de manual. Uma resposta forte explica o String pool, cache de Integer entre -128 e 127, e — idealmente — já foi mordido por esse bug em produção alguma vez. Revela profundidade real de entendimento de como a JVM gerencia objetos, não decoreba.

2. “Explique o que acontece, passo a passo, quando você chama um método anotado com `@Transactional` no Spring que chama outro método `@Transactional` na mesma classe.”
Essa pergunta separa quem só usa a anotação de quem entende proxies e AOP. A resposta certa envolve explicar que o Spring usa proxies dinâmicos, e que uma chamada interna (self-invocation) não passa pelo proxy — então a segunda anotação `@Transactional` é silenciosamente ignorada. Candidatos plenos/sêniores que já debugaram esse comportamento estranho em produção respondem com convicção; quem nunca passou por isso costuma travar ou generalizar.

3. “Como você decidiria entre usar uma Thread pool customizada, o ExecutorService padrão, ou CompletableFuture para paralelizar uma tarefa?”
Não existe resposta única “certa” — o que você quer ver é raciocínio sobre trade-offs: tamanho do pool em relação a I/O-bound vs. CPU-bound, risco de esgotar recursos, propagação de exceções em tarefas assíncronas. Uma resposta fraca escolhe uma ferramenta porque “é a mais nova”; uma forte pergunta de volta sobre o contexto antes de responder.

4. “Sua aplicação Spring Boot está consumindo memória de forma crescente ao longo de dias até estourar o heap. Como você investiga?”
Aqui você quer ouvir um processo, não um diagnóstico chutado: heap dump, análise com uma ferramenta como Eclipse MAT ou VisualVM, procurar por referências que não deveriam estar vivas (caches sem limite, listeners não removidos, ThreadLocal mal gerenciado). Candidatos que já resolveram memory leak de verdade descrevem o processo com naturalidade; quem nunca passou por isso tende a “chutar” uma causa sem mencionar como comprovaria a hipótese.

Competências Comportamentais e Fit Cultural

Além do domínio técnico, avalie como o candidato se comporta diante de ambiguidade e de discordância técnica — em times Java, especialmente em empresas com sistemas legados, é comum encontrar decisões de arquitetura antigas que não fazem mais sentido. Um bom sinal é o candidato que consegue explicar como conviveria com uma decisão legada sem tentar reescrever tudo no primeiro sprint, priorizando entrega e estabilidade sobre “codar do jeito certo” a qualquer custo.

Também vale observar como ele reage a code review: pergunte sobre um feedback difícil que já recebeu (ou deu) e como lidou com isso. Times Java tendem a ser grandes e de longa duração — capacidade de comunicação assíncrona clara (em PRs, documentação, discussões técnicas por escrito) pesa tanto quanto a capacidade de codar.

Como a Hunt IT Garante a Assertividade da Contratação

Avaliar um desenvolvedor Java exige tempo e profundidade técnica que a maioria dos times de RH — e muitos líderes técnicos sobrecarregados — simplesmente não tem disponível para cada candidato que entra no funil. A HUNT IT aplica essa mesma lógica de avaliação por senioridade, teste prático direcionado e perguntas validadas em todos os processos que conduz, entregando candidatos Java já filtrados tecnicamente antes mesmo da primeira entrevista com o seu time.

FAQ — Como Avaliar Desenvolvedor Java

Quais perguntas técnicas fazer para avaliar um desenvolvedor Java?
Priorize perguntas que revelem entendimento de mecanismo, não decoreba de sintaxe — como o comportamento de `@Transactional` em chamadas internas, gerenciamento de memória na JVM, e trade-offs de concorrência. Peça exemplos de problemas reais que o candidato já resolveu em produção, não só definições de manual.

Quanto ganha um desenvolvedor Java no Brasil?
Em geral, júnior fica entre R$ 3.000 e R$ 6.000, pleno entre R$ 6.000 e R$ 12.000, e sênior a partir de R$ 12.000 por mês — variando conforme região, stack e modelo de contratação.

Spring Boot é obrigatório para avaliar um desenvolvedor Java?
Na prática, sim, para a maioria das vagas de backend corporativo no Brasil — é o framework dominante no ecossistema Java atual. Mas vale diferenciar quem só sabe usar as anotações do Spring de quem entende o que elas fazem por baixo (proxies, ciclo de vida de beans, injeção de dependência), porque essa é a diferença real entre um desenvolvedor júnior e um pleno/sênior.

Teste prático longo ou entrevista técnica ao vivo?
Para Java, um teste prático curto e cirúrgico (como o Teste do Vazamento de Conexão descrito acima) combinado com uma conversa técnica ao vivo costuma revelar mais do que um desafio de 4-8 horas em casa. Testes longos favorecem quem tem tempo livre, não necessariamente quem é mais competente — e ainda geram atrito e desistência de bons candidatos que já estão empregados.