To hire Java developers well, start by admitting that "Java developer" covers two very different people. One maintains a Java 8 monolith on an application server and knows every corner of it. The other builds new services on Java 21 or 25 with virtual threads, records and Spring Boot. Both are valuable, and a job description that doesn't say which one you need will attract the wrong half of the applicants.
Job ads for Java roles often list frameworks (Spring, Hibernate, Kafka) as nouns. Frameworks are easy to list on a CV and hard to verify, so this guide gives you a test for each one, and it sits in our series Hire developers by tech stack: rates, vetting and interview guides.
Which Java version should a hire know in 2026?
Java 25 is a long-term support release (the JDK 25 project page says it "will be a long-term support (LTS) release from most vendors"), as is Java 21. Java 27 shipped on 15 September 2026. Oracle's announcement on Inside Java says updates for JDK 27 run until March 2027, when Oracle JDK 28 supersedes it, so it isn't one of the long-term releases. Java 27 experience shouldn't be a requirement.
For a job description, that means two things. Ask for fluency in Java 21 or later, because that's where virtual threads became final (JEP 444 describes them as lightweight threads that reduce the effort of writing high-throughput concurrent applications). And treat anything below Java 17 as a separate profile, covered below.
Make comfort with records, sealed types, pattern matching in switch and streams a hard requirement, along with a working opinion on when virtual threads help. Production experience on the newest release is a nice extra. A candidate who has run Java 21 in production and can explain why they haven't moved to 27 is showing better judgment than one who chases every release. If the upgrade question is yours to answer too, what to check before moving from JDK 25 covers it.
What separates a senior Java developer from a Spring user
Spring Boot makes it easy to ship a working service without understanding what's underneath. Plenty of developers with five years of Java on their CV have five years of annotations. The general markers of seniority in backend work (owning production, thinking about failure) are in what separates senior backend developers from mid-level ones. Here's what's specific to Java.
Concurrency
A senior candidate can explain the difference between platform threads and virtual threads without reciting a blog post. Virtual threads make blocking I/O cheap, so a thread-per-request model scales again. They don't make CPU-bound work faster, and they shouldn't be pooled. If you need to cap concurrency against a downstream service, you use a semaphore, not a fixed-size executor.
Pinning is the follow-up worth asking about. On Java 21, blocking inside a synchronized block holds onto the carrier thread, and Java 24 (JEP 491) removed that pinning for synchronized, though native calls and foreign functions still pin. A candidate who knows why that matters, and which version they were on when they hit it, has actually run this in production.
JVM and GC judgment
You don't need a GC tuning wizard for most roles. You need someone who reaches for measurement first: GC logs, heap dumps, a profiler. G1 has been the default collector on server-class machines since Java 9, and the honest answer to "what flags would you set?" is usually "none until I've seen the logs." Distrust anyone who recites a list of flags from an old Stack Overflow answer.
Persistence
JPA and Hibernate are where Java services quietly go slow. The classic problem is the N+1 query: load a list of parents, touch a lazy association on each, and you've issued one query per row. A senior developer spots it in a code review, knows how to fix it (join fetch, entity graphs, batch fetching), and has an opinion on lazy loading and transaction boundaries. They also know that a @Transactional method called from another method in the same class doesn't go through the Spring proxy.
Spring Boot beyond annotations
Ask how auto-configuration decides what to wire up, how profiles and @ConfigurationProperties should be used, and what Actuator gives them in production. Someone who's only copied starters can't answer these. Someone who's debugged a failed startup at 2 a.m. can.
Testing
Look for JUnit 5 used well, Mockito used sparingly, and integration tests against a real database (Testcontainers is one common way). A codebase where every collaborator is mocked tests the mocks. Ask what they don't mock and why.
Java stack coverage: what to put in a job description
Core for a modern backend role: Java 21 or later, Spring Boot, Hibernate/JPA and SQL, Maven or Gradle, and a message broker experience such as Kafka. Spring Cloud is a real requirement only if you run the pieces it wraps. Say so in the job description instead of listing it for decoration.
Nice to have: Kotlin interop (many Spring shops mix the two), Docker and Kubernetes exposure, and observability tooling. Don't require all of it. A list of fifteen technologies filters out exactly the candidates who'd rather go deep than wide.
Legacy is its own hire. J2EE, Struts, JSP and Java 8 codebases need someone patient, good at reading unfamiliar code and comfortable making small, safe changes. That's a different skill from greenfield design, and a developer who's excellent at one is often unhappy doing the other. Write two job descriptions if you have both problems. Don't ask one person to be both.
How to vet a Java developer
The sequence below is our own editorial guidance, not a sourced standard. It's built so each stage filters for something the previous one can't.
1. Screen for version and framework depth
Start with a 20-minute conversation, not a quiz. Ask which Java version their last project ran on, what they'd change about it, and what they did with the newer language features. Then pick one framework claim on their CV (say, "Spring Security") and ask them to describe a problem they solved with it.
A good candidate names specifics: a version number, a library, a bug. A weak one describes the framework's marketing page. "We used Spring for microservices" tells you nothing.
2. Review code, not trivia
Send a 60-line service class with three planted problems: an N+1 query hiding behind a lazy association, a shared mutable field in a singleton bean, and a @Transactional self-invocation. Ask for written comments as if reviewing a pull request.
Strong candidates find at least two and explain the runtime effect, not just the rule. Weak candidates comment on naming and formatting. Either is useful information, but only the first is what you're paying for.
3. Run a live problem on concurrency or persistence
Pick one. For concurrency: a service that calls a slow downstream API for 500 items, first sequentially, and ask them to make it fast without overloading the API. Listen for virtual threads or an executor, and for a concurrency limit. For persistence: give them a schema and ask them to write the query and the JPA mapping for a paginated order list with line items. Listen for how they handle the N+1 and pagination together. How to run this stage without turning it into theatre is covered in running the live coding stage.
4. Talk through a production incident
Ask for the worst incident they've personally debugged. The good answers have a timeline, a wrong first guess, and a specific change that came out of it. The bad ones are vague ("the database was slow") or blame someone else. If they can't name one, that's an answer too.
Interview questions that expose depth
These are our suggestions, and the strong-answer notes are what we'd listen for, not the only acceptable answers.
- What does a virtual thread cost you, and when would you not use one? A strong answer covers CPU-bound work, pinning, thread locals, and not pooling them.
- Here's an endpoint that's slow when the list has 200 rows. How do you find out why? Strong answers start with logging the SQL, spot N+1, and talk about fetch strategy before reaching for caching.
- What does
@Transactionalactually do? A strong answer mentions the proxy, propagation defaults, rollback on unchecked exceptions by default, and the self-invocation trap. - Your service's latency spikes every few minutes. What do you check? Listen for GC logs and heap usage before flag changes, then thread dumps.
- When would you choose a record over a class? A strong answer covers immutability and data carriers, and knows records aren't JPA entities.
- How do you test a service that talks to Postgres and Kafka? Look for a real database in tests and a clear view of what's worth mocking.
- Tell me about a Spring Boot upgrade you did. Good answers include what broke and how they found out.
What drives Java developer cost
Quotes for the same job title diverge for reasons that have nothing to do with Java itself. Seniority is the biggest: someone who can own a service's performance and failure modes costs more than someone who can build endpoints. Legacy stacks can price differently from greenfield work. Location matters, and so does the engagement model (freelance, agency, staff augmentation, direct hire). The last driver is how the margin is applied: some vendors quote one blended number, others show what the engineer earns and what the vendor adds. We aren't quoting figures here because we don't have a dated, primary rate source for Java, and a made-up range is worse than none. Ask any vendor to separate the engineer's pay from their own margin before you compare quotes.
Freelance, in-house, or staff augmentation for Java
Freelancers suit a bounded task with a clear finish line: a Spring Boot upgrade, a persistence audit. In-house suits a system that will outlive any single project and needs people who accumulate its history. Staff augmentation sits in between: you get an engineer embedded in your team for months, without the recruiting cycle or the permanent headcount.
For Java, the latter two often fit better, because the expensive Java problems are usually about long-lived systems: a legacy service nobody fully understands, or a core platform that needs continuity. A freelancer who leaves after six weeks takes that context with them.
How HighCircl vets
HighCircl runs four engineer-led vetting stages: background and experience verification, a communication and product-thinking assessment, a take-home technical project that mirrors real work, and a live technical session on architectural reasoning. About 1 in 10 applicants pass, and clients get a shortlist of 3-5 candidates in 72 hours. The margin is 20%, capped, applied on top of what the engineer earns, with no minimum hours. HighCircl's covered stacks are React, Node.js, Python, iOS, Android, Flutter, Go and DevOps, across seven European countries: Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain.
FAQ
What Java version should I hire for?
Java 21 or later. Both Java 21 and Java 25 are long-term support releases, and Java 21 is where virtual threads became final, so a candidate fluent in 21 has seen the modern language. Java 27 isn't one of the long-term releases, so don't require it. If your codebase is still on Java 8, hire for that separately and be honest about it in the job description.
How do I test a Java developer's Spring knowledge?
Skip definitions. Give them a short service class with an N+1 query, a @Transactional self-invocation and shared mutable state in a singleton, and ask for a written code review. Then ask how auto-configuration works and what they've debugged in production. Someone who's used Spring seriously can explain the proxy behind @Transactional. Someone who's copied starters usually can't.
How long does hiring a Java developer take?
It depends on the route, and we haven't found a trustworthy public figure for Java specifically, so we won't quote one. The biggest delay is usually internal: a job description that doesn't say whether you need a modern Java builder or a legacy maintainer, which sends every subsequent stage back to the start. HighCircl's shortlist of 3-5 vetted candidates in 72 hours applies to its covered stacks (React, Node.js, Python, iOS, Android, Flutter, Go, DevOps), which don't include Java.
Should I use a freelancer or staff augmentation for Java?
A freelancer fits a bounded task. Staff augmentation fits long-lived systems where continuity matters, since an embedded engineer accumulates context over months. If the work has no end date, in-house or augmentation are likely to lose less context than a series of short freelance contracts.
What is the difference between a Java developer and a backend developer?
A backend developer is defined by the work: APIs, data, reliability, ownership of production. A Java developer is defined by the tool. Most senior Java developers are backend developers, but a strong backend developer from another ecosystem can learn Java quickly. What's harder to teach is the JVM judgment, and that's what the vetting steps above are designed to find.