Java hiring goes wrong on the framework, not the language.
Almost every candidate can write Java. Far fewer have operated Spring Boot under load, and fewer still have worked inside an enterprise estate where the application server, the build and the deployment are all somebody else's decision from 2014.
- Current
- Java 17 / 21, Spring Boot 3
- Enterprise
- Jakarta EE, WebLogic, WebSphere
- Data
- Oracle, DB2, PostgreSQL, JPA
- Engagement
- Monthly rolling, 30 days notice
- Interview
- You meet them, you can decline
- Overlap
- 4–6 hours with US and EU
Twenty years of Java are all still in production somewhere.
“Eight years of Java” could mean Spring Boot microservices on Kubernetes, or an EJB application on WebLogic that was last redesigned when the candidate joined. Both are legitimate experience. They prepare somebody for entirely different work.
The version spread compounds it. Code written for Java 8 and code written for Java 21 look different enough that an engineer who has not moved forward will produce something your newer engineers find dated, without anybody being able to articulate why during a code review.
So we screen on the framework and the operational context, not on the language. What did they run it on, who deployed it, what happened when it fell over at four in the morning, and what did they change afterwards.
The one thing we are strict about: nobody goes forward who cannot explain what their build actually does. Java's build tooling is where a great deal of accidental complexity accumulates, and an engineer who treats Maven or Gradle as an opaque incantation will not be able to fix the problems that matter most on an inherited codebase.
What you are running, and who fits it.
| Your estate | The profile | Note |
|---|---|---|
| Spring Boot 3, Java 21, containers | Current-stack engineer | Largest available pool |
| Spring Boot 2, Java 11/17 | Current-stack engineer | Upgrade is usually worth scoping early |
| Jakarta EE / Java EE on an app server | Enterprise engineer | Different deployment model, different instincts |
| WebLogic or WebSphere | Enterprise engineer | Scarce; operational knowledge matters more than language skill |
| Oracle or DB2 heavy | Enterprise engineer | PL/SQL and tuning experience is the real requirement |
| Batch and scheduled processing | Either, with Spring Batch experience | Frequently the least documented part of the estate |
| Coming from ColdFusion | Migration profile | See ColdFusion to Java |
What we ask a Java engineer.
Six questions where senior candidates diverge sharply, none of which are about language syntax.
What does your build do?
Maven or Gradle, plugins, profiles, what is generated. An engineer who cannot answer will be helpless on an inherited project, which is most projects.
How did you diagnose a memory problem?
Heap dumps, GC logs, a profiler, and what they found. This is where operational experience shows and it cannot be revised for.
Where do transactions begin and end?
Spring's declarative transactions are easy to use and easy to get subtly wrong. Strong candidates have a specific story about a boundary that was in the wrong place.
How do you handle a slow downstream call?
Timeouts, retries with backoff, circuit breaking, and awareness that a retry storm can be worse than the original failure.
What is in your integration tests?
Testcontainers or an in-memory database, and an opinion about the trade-off. Teams that only unit-test JPA code discover their queries in production.
What would you change about this codebase in week one?
Asked against a real sample. We are looking for judgement about sequencing, not a list of everything that is imperfect.
What Java engineers get hired for here.
Building services
Spring Boot services against an existing enterprise estate, with the integration and security constraints that come with it. The most common brief and the most straightforward.
Spring Boot 3 Containers CI/CDHolding an enterprise estate together
Application-server deployments, batch processing and integrations that have run for a decade. Low drama, high consequence, and a shrinking pool of people who are comfortable in it.
Jakarta EE Oracle BatchMigrating onto the JVM
Moving a ColdFusion or legacy estate into Java incrementally, in the same process, sharing a connection pool and a transaction while it happens.
CFML to Java Strangler Shared JVMRates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Java engineers.
Three that decide the shape of the engagement.
Is Java still a sensible choice for new systems?
For enterprise back-end work, yes, and the reasons are unglamorous ones that matter more over ten years than the reasons that dominate technology discussion. The hiring pool is deep in every market, the operational tooling for diagnosing problems in production is the best of any mainstream runtime, and the library ecosystem for the boring things (messaging, transactions, security, batch) is mature and well understood. Where we would push back is on small products with small teams, where the ceremony costs more than it returns, and on anything where the team has no JVM background and no appetite to acquire one.
We are on an old application server. Can you help without a migration?
Yes, and that is frequently the right call for a few more years. An application running on WebLogic or WebSphere that meets the business need is not a problem in itself; the problems are licence cost, the shrinking pool of people who can operate it, and version support. Those are addressable individually and much more cheaply than a migration. We can maintain and extend what you have, document it properly so it is not held in one person's head, and give you an honest annual view on when the calculation changes. When it does change, moving to Spring Boot on containers is a well-worn path and the comprehension work will already be done.
Kotlin instead of Java?
Happily, and on new services it is often the better choice; more concise, better null handling, and fully interoperable so it can live alongside Java in the same codebase. The consideration is not technical, it is your team: if the people maintaining this in five years are Java engineers who have not used Kotlin, you have introduced a learning requirement in exchange for ergonomics. On Android, Kotlin is simply the default and the question does not arise — see Android developers.