A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Java has been in production for thirty years, which means “Java developer” describes people with almost incompatible experience.
Someone who has spent a decade on Java 8 with XML-configured Spring and an application server is genuinely skilled — and will move slowly in a Spring Boot 3 codebase using records, virtual threads, and reactive patterns. Someone who learned on modern Spring Boot will be lost in a legacy EJB system with a build nobody has touched since 2016.
Both are real jobs. They need different people.
The most common Java hiring mistake is matching on the language rather than the era. We ask which Java version, which Spring generation, and which build tool during discovery — because those three answers narrow the search more than anything on the job description.
Dependency injection, transaction boundaries, and what actually happens at startup. Annotation familiarity isn't the same as understanding.
Thread pools, synchronisation, and increasingly virtual threads. Java's concurrency model is powerful and easy to misuse.
Garbage collection, memory profiling, heap analysis. The skill that separates people who can debug production from people who restart it.
JPA and Hibernate, plus knowing when the ORM is generating something catastrophic. N+1 queries are a Java speciality.
Maven or Gradle, multi-module projects, and dependency conflict resolution.
JUnit, Mockito, and integration testing with Testcontainers. Enterprise Java without tests is unmaintainable by month three.
Java systems rarely fail fast. They degrade, and the degradation is expensive because these are usually the systems that move money or run operations.
The classic is an ORM problem that only appears at production volume. A JPA entity with an eager association, fetched in a list view. Ten records in test, one query. Two thousand records in production, two thousand and one queries. The endpoint that returned in 80ms now takes fourteen seconds, the connection pool exhausts, and requests queue behind it. Nothing is broken. Everything is slow, and the cause is a single annotation.
The other pattern is a heap that grows across a week — a static collection used as a cache with no eviction — until full garbage collection pauses climb into whole seconds. Users report intermittent timeouts. Restarts fix it, so it gets scheduled, and the leak is never found.
Both need someone who can read a heap dump and a query plan. That skill is the actual difference between a mid-level and a senior Java developer, and it’s why hiring on framework familiarity alone is a false economy on systems that have to keep running.
Mid-level (3–6 years). Builds services against an established architecture. Comfortable with Spring Boot and standard patterns. Needs direction on design.
Senior (6–10 years). Designs services and makes framework and persistence decisions. Can profile a JVM, diagnose a memory leak, and lead a migration.
Lead / Architect (10+ years). Owns system architecture across services, handles the legacy modernisation strategy, makes technology decisions with a five-year horizon.
Java seniority bands run longer than in newer stacks — the codebases are older and the consequences of poor decisions last longer.
Spring Boot microservices. The most frequent request. Service design, inter-service communication, resilience patterns.
Legacy modernisation. Monolith to services, or Java 8 to a current LTS. Needs someone who has done a migration rather than someone who has read about one.
Performance work. A system that’s slow under load. Usually JVM tuning, database access, or both.
Batch and integration. Spring Batch, message queues, scheduled processing. Unglamorous and consistently in demand.
Team augmentation. Adding capacity to an existing enterprise team with established conventions. Common across BFSI and fintech and enterprise applications.
Dependency and CVE remediation. A published advisory against a transitive dependency, and an upgrade path that breaks three other things. Steady, unglamorous work that spikes without warning, and it needs someone comfortable reading a dependency tree rather than bumping versions until the build goes green.
Week one. They build the project and run the tests, which on an older codebase is a genuine test in itself — a Maven build with an internal repository, an outdated JDK, or an integration suite needing a database. Expect questions about the Java version, the Spring generation, whether there’s a shared parent POM, and how configuration differs between environments.
Weeks two to four. They ship a service change with tests, ideally including an integration test using Testcontainers rather than mocks all the way down. Expect them to flag something: an N+1 in an existing endpoint, a dependency with a published CVE, a transaction boundary drawn in the wrong place so a failure leaves half-written data.
The warning sign is a developer who only writes new code. Enterprise Java work is mostly changing existing systems safely. Someone who avoids the older modules, or proposes rewriting rather than understanding them, will be a problem on exactly the code that matters most.
Expect them to read the build before the code. In a long-lived Java codebase the dependency tree explains more than any documentation — what is genuinely used, what was abandoned in place, and which library versions are quietly holding back an upgrade. A developer who starts there is orienting themselves properly.
Hiring on “Java” and discovering the version mismatch afterwards. A developer whose recent work is Java 17 or 21 — records, sealed types, virtual threads — will find a Java 8 codebase with XML configuration slow and unrewarding, and some will leave. Be explicit in the brief. We tell candidates the real version upfront, because the mismatch surfaces in week three either way.
Assuming Spring experience means Spring Boot experience. Boot’s auto-configuration and starter model is a different working style from wiring beans by hand. The gap runs the other way too: a Boot-native developer often can’t debug an application-context failure in a legacy XML setup.
Reaching for microservices to fix a deployment problem. Teams split a monolith because releases are slow, then discover the real constraint was a manual QA gate and now they have distributed transactions as well. Fix the pipeline first. A senior Java developer will say this; it’s a useful thing to listen for in interview.
Screening on language features rather than system behaviour. Streams, records, and pattern matching are pleasant and easy to ask about. They tell you very little about whether someone can reason about a thread pool that is saturating, a connection leak that only appears under load, or a transaction boundary drawn in the wrong place. Those are the problems that actually reach production in Java systems.
Rates depend on seniority, systems complexity, and engagement length. Tell us the role and we’ll give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.