How to get hired as a Java developer in 2026-27

The five jobs advertised as "Java Developer"

Java is the most heterogeneous title in backend hiring. The same two words are used for work that shares a language and almost nothing else, and candidates lose interviews by preparing for the wrong one. Read the posting for the stack and the verbs before you prepare: "build new services" and "stabilise and modernise" are not the same job, and neither is "sub-millisecond".

The first and largest category is enterprise or product backend work. Spring Boot services behind an API gateway, a relational database, Kafka or a managed queue, Kubernetes, and a long-lived domain in insurance, banking, payments, telco, healthcare administration, logistics or retail. The interview is Spring depth, SQL and JPA behaviour, concurrency, and a design round about idempotency and failure. Most Java jobs in the world are this one.

The second is legacy modernisation and platform upgrade. Moving Java 8 or 11 to a current LTS, javax to jakarta, WebLogic or WebSphere or JBoss to embedded Tomcat in a container, Struts or JSF to a REST API with a separate frontend, Ant to Maven, a monolith to a modular monolith or a small number of services. This is where consultancies and internal platform teams hire hardest in 2026-27, it pays well because it is unglamorous, and almost nobody prepares for it specifically, which makes it the easiest market to stand out in.

The third is low-latency and high-throughput JVM work: exchanges, market making, payments authorisation, adtech bidding, telemetry ingestion. The interview barely mentions Spring. It tests the Java memory model, allocation and escape analysis, garbage collector choice and pause behaviour, lock-free structures, false sharing, off-heap buffers, JMH benchmarking discipline, and whether you measure or guess. Candidates from CRUD backgrounds get eliminated in the first twenty minutes, and candidates from this world sometimes get eliminated from ordinary backend roles for over-engineering.

The fourth is data and streaming on the JVM: Kafka Streams, Flink, Spark, Beam, custom connectors, large batch pipelines in Spring Batch. Often advertised as Java, sometimes as Scala or Kotlin, and the interview is about partitioning, watermarks, state stores, delivery semantics and backfills rather than about HTTP.

The fifth is integration and vendor-platform work: Apache Camel, MuleSoft, IBM integration stacks, SAP adjacency, ESB migrations, SOAP to REST. It is real, well paid, heavily contract-based, and a different skill set again. Android is a sixth thing that is no longer really a Java job; it is Kotlin, and it has its own hiring process.

Two cross-cutting facts about all of them. Many teams advertising Java roles write a meaningful share of their code in Kotlin on the same JVM, and saying you are happy to work in Kotlin costs you nothing and removes a doubt. And the title ladder in enterprise Java is unusually compressed: a bank's "Java Developer" can be a six-year engineer or an eighteen-year one, so the level is set by the questions in the room rather than by the words in the advert.

• Enterprise or product backend: Spring Boot, JPA or jOOQ, Postgres or Oracle, Kafka, Kubernetes. Prepare Spring internals, SQL, concurrency, design.
• Legacy modernisation: JDK and Jakarta upgrades, application server exit, strangler migrations, test harnesses for untested code. Prepare a migration story and a verification technique.
• Low latency: memory model, garbage collection, allocation, lock-free concurrency, JMH, off-heap. Prepare measurement, not frameworks.
• Streaming and data: Kafka Streams, Flink, Spark, Spring Batch. Prepare partitioning, state, delivery semantics, reprocessing.
• Integration: Camel, MuleSoft, IBM stacks, SOAP to REST. Mostly contract, mostly through specialist agencies.
• Signals in the posting that tell you which one: a named JDK version, "greenfield" versus "stabilise", the words "WebLogic", "EJB" or "javax", a p99 target in milliseconds, "Kafka Streams", "on call".
• If the posting says Java 8 and nothing else, that is useful information, not a disqualifier. Ask in the screen what the upgrade plan is. The answer tells you whether the job is modernisation with budget or maintenance without.

What actually gates the job, and what the certifications are really worth

Nothing licences a Java developer. There is no board, no registration, no continuing education requirement, and no legal barrier to calling yourself one. That means the gates are informal, and the useful move is to identify which informal gate is stopping you rather than collecting credentials at random.

The degree gate is real at graduate entry and then fades. Large employers with structured graduate programmes, particularly banks, consultancies and defence contractors, filter on a degree because they are processing very high application volumes and need a cheap filter. After roughly three years of commercial experience it stops being asked, and a large share of working Java engineers in enterprise shops arrived through conversion courses, apprenticeships, internal moves from support or QA, or a bootcamp followed by a contract that nobody now remembers was a bootcamp.

The certification question deserves a narrow answer rather than an encouraging one. Oracle Certified Professional, Java SE Developer tests real language detail, and passing it will genuinely sharpen your knowledge of generics, streams and collections. Its market value is concentrated in one place: system integrators and offshore or nearshore delivery firms that count certified staff toward partner tiers and client bid requirements. In those firms, a certification can decide whether you get staffed. In product companies, banks hiring directly, and startups, nobody will ask and it will not compensate for a weak technical screen. Treat it as a staffing-firm asset, not a hiring asset. The same logic applies to AWS and Azure associate certifications, with the difference that cloud certifications also give structure to learning you probably need anyway.

The gates people underestimate are clearance and sponsorship. Defence, intelligence and some government-adjacent Java work requires a clearance that your employer must sponsor and that takes months, so those jobs are effectively closed until an employer takes you on in a cleared-adjacent role first. Financial services adds background checks, credit checks and, for some roles, regulator registration and fingerprinting. And visa sponsorship is one of the most common silent rejections in enterprise Java, because the market is globally distributed and employers who do not sponsor filter early and do not explain. Ask about sponsorship in the first call rather than at offer stage.

One piece of literacy that functions as a gate without appearing in any job description: knowing which JDK distribution you are running and why. Oracle's commercial terms for its own builds moved to an employee-count-based subscription, and the free-use terms for a given release expire a period after the following long-term-support release, so organisations on Oracle builds face a recurring and expensive decision. Most have moved to a free OpenJDK build: Eclipse Temurin, Amazon Corretto, Azul Zulu, the Microsoft build, or Red Hat's. A candidate who knows the difference, and who has been part of a migration off Oracle builds, is talking about something a platform lead cares about personally. A candidate who says "we just use Java" has revealed how far from the platform they sit.

• No licence, no registration, no mandatory training. The gate is demonstrated ability plus someone who will vouch for you.
• Degree: a filter at graduate entry, mostly irrelevant after about three years, occasionally relevant for visa routes.
• Oracle Certified Professional, Java SE Developer: useful for getting staffed by an integrator or consultancy, near-worthless as a substitute for passing a technical screen. Say that to yourself before spending the money.
• Clearance and background checks: employer-sponsored, months long, and they shape which parts of the market are open to you today.
• Visa sponsorship: ask in the first conversation. It is one of the most common unexplained rejections in this market.
• Know your JDK: distribution, major version, and the reason your employer chose it. This is a two-sentence answer that signals platform awareness.
• The one credential that is genuinely rising in value is not a certification at all: a public record of upgrade and migration work, in a repository or in a written account you can send.

The hiring process, stage by stage, and who is on the other side

Java hiring runs through more intermediaries than most software hiring, and that shapes how you should behave at each stage. A large share of enterprise Java roles are filled by agencies and staffing firms rather than by in-house recruiters, especially in the UK, Germany, the Netherlands, India and the US financial sector. The first human who reads your resume is frequently a recruiter matching literal strings, which is the practical reason to write "Spring Boot 3", "Java 21" and "Kafka" as words rather than implying them.

Stage one is the screen, and in enterprise Java it is often shorter and more transactional than candidates expect: stack, notice period, salary or day rate, location and on-site expectation, visa status. Have a sixty-second version of your stack and a number you will say out loud. If the recruiter is an agency, ask which client and whether they have an exclusive brief, because the same role is sometimes submitted by three agencies and duplicate submissions get candidates dropped. Ask also whether the role is a backfill, a new headcount or a migration programme, because that answer tells you what the next interview will be about.

Stage two is the technical screen, run by a senior engineer or tech lead, 45 to 75 minutes. In most enterprise Java loops this is a conversation, not a puzzle, and it is where most rejections happen. Expect rapid-fire depth questions on Spring, JPA and the JVM, usually following your own resume: you said you used Kafka, so what happens when a consumer rebalances mid-batch; you said Spring Boot, so where does auto-configuration actually come from; you said performance tuning, so what tool did you use and what did the output look like. Large banks and large product companies often put an automated test before this instead: HackerRank, CodeSignal or Codility, 60 to 90 minutes, two or three problems at the easier end of the algorithm spectrum. Do not skip algorithm practice if you are targeting that segment, and do not spend months on it if you are targeting the modernisation segment.

Stage three is practical, and Java loops use three distinct formats. A take-home Spring Boot service, typically a small REST API with persistence and tests, expected in a few hours and reviewed for structure, tests, error handling and whether the README tells the reviewer how to run it. A live pairing or refactoring exercise on existing code, which is common for modernisation roles and consultancies: you are given something ugly and untested and asked to add tests and improve it without changing behaviour. Or a debugging round: a broken or slow application, and you are watched forming hypotheses. All three reward narration. Saying "my first hypothesis is an N+1, because this repository method returns entities with lazy collections, so I will turn on SQL logging and count the statements" scores even if the hypothesis turns out to be wrong.

Stage four is design. For ordinary backend roles it is a service design question with the hard parts in the failure cases: idempotent payment submission, order processing across a queue, a nightly reconciliation that must not double-count, a schema change on a table that is written to continuously. For modernisation roles it is a migration design question: how you move this system without a downtime window. For low-latency roles it is a latency budget question. The round is not testing whether you can draw boxes; it is testing whether you ask about volumes, consistency requirements, failure tolerance and rollback before you draw anything.

Stage five is the manager and sometimes a stakeholder. This is where enterprise Java diverges sharply from startup hiring: you will be asked how you work with people who are not engineers, because the systems in question usually have an operations team, a compliance function and a business owner who can veto a release. Have an example of a decision you changed after a non-engineer explained a constraint, and an example of saying no to a deadline with a reason rather than with a complaint.

Timelines: two to six weeks for a permanent role, with large banks and government at the slow end and sometimes much slower. Contract hiring is a different sport: one or two conversations, a decision in days, and a start date that can be next Monday. If you want speed, the contract market is where it exists, with the tradeoff that in the UK the off-payroll working rules determine whether an engagement is inside or outside scope and that materially changes your take-home. Get the determination in writing and check the current rules, because this is an area that has changed more than once and advice from a few years ago may be wrong.

• Who screens, in order: a recruiter or agency matching literal keywords, then a senior engineer, then a panel, then a manager.
• Ask the agency which client and whether the brief is exclusive. Duplicate submissions from two agencies get candidates eliminated for reasons they never hear.
• The technical screen follows your resume. Every technology you list is a question you have invited. Remove anything you cannot defend for five minutes.
• Practical formats: take-home service, live refactor of ugly code, or debug a broken app. Modernisation roles favour the second and third.
• In any practical round, narrate hypotheses and say what you would measure. Silence reads as not knowing even when you do.
• Design rounds are won in the first three minutes by asking about volume, consistency, failure tolerance and rollback before drawing anything.
• Bring your own questions about the codebase: JDK version, Spring Boot version, test suite runtime, deployment frequency, how many manual steps a release takes, how incidents are handled. These also tell you whether to accept.

What the technical rounds really test: the language, concurrency and the JVM

Enterprise Java interviews test depth in a narrow set of areas, and the questions have been stable for years with one large recent addition. Know the stable set cold, and know the new one better than the people interviewing you.

Collections and equality still open most screens, because they reveal whether you understand the runtime rather than the syntax. How HashMap works, what happens when hashCode collides, why a mutable key breaks a map, the equals and hashCode contract and what violating it actually costs, why you should never put a JPA entity with a database-generated identifier in a HashSet before it is persisted, ArrayList versus LinkedList and why the answer is almost always ArrayList, ConcurrentHashMap versus a synchronized map, and the sequenced collection interfaces added in Java 21. Streams come up constantly: lazy evaluation, when a parallel stream helps and the much more common case where it hurts, the collectors you actually use, and why a stream chain that mutates external state is a bug.

Modern language features are now assumed rather than bonus. Records and when they replace a class, sealed interfaces plus pattern matching for switch as a way to model a closed set of cases and get exhaustiveness from the compiler, text blocks, var and where it damages readability, Optional and the rule that it belongs in return types and not in fields or parameters, and java.time instead of Date and Calendar. If your vocabulary is Java 8 in 2026, interviewers notice immediately, and the fix is cheap: rewrite something you already own using records and pattern matching so you can speak from use rather than from reading.

Concurrency is where mid-level and senior separate, and virtual threads changed the conversation. Know the classical material: the memory model and happens-before, volatile and what it does and does not guarantee, synchronized versus ReentrantLock, the executor framework and why you size pools deliberately, CompletableFuture composition and its awkward error handling, the atomic classes and when LongAdder beats AtomicLong under contention, and immutability as the cheapest concurrency strategy. Then know what Java 21 changed: virtual threads make thread-per-request viable at concurrency levels that used to require a reactive stack, pooling virtual threads is an anti-pattern because creating them is cheap, ThreadLocal becomes expensive at that scale which is why scoped values exist, and pinning inside synchronized blocks was a real early limitation that a later JDK release fixed. The question that separates candidates: "virtual threads let a thousand requests block at once, so what is your new bottleneck?" The answer is the resource behind the blocking, usually the database connection pool, and the right follow-up is that a pool of ten connections still serves only ten concurrent queries no matter how many threads are waiting on it.

The reactive question now needs a defensible answer. If you are asked whether to use WebFlux and Reactor in 2026, the honest answer is that for ordinary request-response services over a relational database, virtual threads give most of the throughput benefit without the debugging cost of a reactive stack, and that reactive still earns its place where you need backpressure, long-lived streaming connections, server-sent events or websockets at scale, or heavy outbound fan-out with flow control. Saying that, in those terms, is a strong signal. Saying "reactive is faster" is not.

JVM knowledge is the part most candidates skip and the part that most reliably gets a senior title. You should be able to say which garbage collector your application uses and why, what G1 does differently from ZGC, what a humongous allocation is, and why the right first move for a latency problem is almost never a GC flag. You should know what a container does to the JVM: that heap is one component of the process footprint alongside metaspace, thread stacks, code cache and direct byte buffers, that a container kill shows up as exit code 137 rather than as an OutOfMemoryError, and that sizing heap as a percentage of available memory is more robust than a hard-coded maximum. And you should be able to name your tools and what you saw in them: Java Flight Recorder and JDK Mission Control, async-profiler flame graphs, garbage collection logs, a heap dump opened in Eclipse Memory Analyzer, jcmd, and JMH for anything you are tempted to microbenchmark with a loop and a timer.

If you have never done any of that, it is a weekend's work to stop bluffing about it, and the stories it produces are what the round is actually fishing for. Put a small service of your own under load with k6 or Gatling, then break it on purpose and watch each failure. Introduce an N+1 by loading a lazy association in a loop, turn on SQL logging and count the statements. Shrink the connection pool to two and watch requests queue inside getConnection. Set a container memory limit low enough that the kernel kills the process, and confirm you get exit code 137 with no Java stack trace. Record a Java Flight Recorder session during load and open it in JDK Mission Control, take a flame graph with async-profiler, turn on GC logging and read one. Write one sentence per item about what it looked like on screen. Those sentences are the difference between a candidate who has profiled something and a candidate who has read about profiling.

• Recurring questions: "How does HashMap work and what breaks with a mutable key?"; "Where is the memory leak in this cache?"; "This endpoint is fine at 50 users and collapses at 500. Walk me through finding out why."; "When is a parallel stream the wrong tool?"; "We turned on virtual threads and throughput did not improve. What would you check?"
• Language checklist: records, sealed types with exhaustive switch patterns, text blocks, Optional discipline, java.time, generics and variance, try-with-resources, exception design, and why you do not swallow InterruptedException.
• Concurrency checklist: happens-before, volatile, synchronized versus locks, executors and pool sizing, CompletableFuture, atomics and LongAdder, virtual threads, scoped values, structured concurrency as the direction of travel.
• JVM checklist: G1 versus ZGC, allocation rate and escape analysis, metaspace, direct buffers, class loading, container memory and CPU limits, class-data sharing and the newer ahead-of-time startup caches, and why GraalVM native image is a serverless and scale-to-zero tool with a real build-time and reflection cost.
• Tooling checklist: JFR and JMC, async-profiler, GC logs, Eclipse MAT, jcmd, jstack, JMH, and a load generator such as k6 or Gatling. Having opened these yourself is the differentiator.
• Have one concurrency bug you actually fixed, with the symptom, the diagnosis and the fix. A real race condition story is worth more than any amount of textbook recall.
• Cheapest credibility available: break your own service deliberately (N+1, pool exhaustion, container OOM kill, GC thrash) and keep a sentence about what each looked like in the tool.

Spring and Spring Boot depth: the questions that separate experience from exposure

Almost every enterprise Java role is a Spring role, and almost every candidate claims Spring. The screen therefore exists to find out whether you have used it or merely worked next to it. The questions that do this are consistent, and a vague answer to any of them is expensive.

Dependency injection and configuration first. Constructor injection versus field injection and the real reasons to prefer constructors (immutability, visible required dependencies, testability without a container, and failing fast on a cycle). Bean scopes and what goes wrong when a singleton holds request state. Where Spring Boot auto-configuration comes from, which in current versions is the AutoConfiguration.imports file under META-INF/spring rather than the older spring.factories, with conditional annotations deciding what applies. How your own bean overrides it through conditional-on-missing-bean. The precedence order of externalised configuration, because a misordered property is a weekly production question. Profiles, and why heavy profile use in production configuration becomes unmaintainable.

Then transactions, which is the single highest-yield topic in Spring interviews, because the failure modes are subtle and common. @Transactional is implemented with a proxy, so a call from one method of a bean to another method of the same bean does not pass through the proxy and the annotation does nothing: this is the classic self-invocation bug and interviewers ask it constantly. Rollback happens by default on unchecked exceptions and not on checked ones unless you say so. Propagation matters: REQUIRES_NEW suspends the current transaction and takes a second connection, which is how people deadlock themselves under a small pool. Transaction boundaries decide where your Hibernate session ends, which is why a lazy collection accessed in a controller throws, and why spring.jpa.open-in-view defaulting to on is a convenience that hides this and costs you held connections. Know that one, and know that you would turn it off deliberately.

Persistence is where real applications are slow. N+1 selects and the three fixes (a fetch join, an entity graph, or a projection that never loads the entity), why eager fetching by default is worse than N+1, pagination that works (keyset or seek pagination rather than a large offset, and never a collection join fetch with pagination, which Hibernate will warn it is applying in memory), batch inserts with flush and clear plus the batch size property that actually enables them, the first-level cache and why it causes surprises in long transactions, optimistic locking with a version column versus pessimistic locking with select for update, and when to leave JPA entirely for jOOQ, a JDBC client or plain SQL. Schema migration belongs here too: Flyway or Liquibase, versioned and in the repository, never applied by hand, and expand-and-contract for any change that must deploy without downtime.

Spring Security is the area where candidates most often have cargo-cult knowledge. You should be able to describe the filter chain as a chain, know that configuration is now a SecurityFilterChain bean built with the lambda DSL rather than the removed WebSecurityConfigurerAdapter, know how a resource server validates a JWT including issuer, audience, signature and key rotation, understand why CSRF protection is about cookie-borne credentials and what that means for a stateless token API, and know how method-level authorisation differs from URL-level. Getting this wrong in an interview at a bank ends the interview.

Testing is the fastest signal of professional experience in this ecosystem. The slice annotations and why booting the whole context for every test destroys your build time, Testcontainers as the default for anything involving a database or a broker plus the service-connection support that removes most of the configuration, WireMock for outbound HTTP, MockMvc or the test client for the web layer, the move from @MockBean to @MockitoBean in recent Spring Boot versions, and an honest position on mocking: tests that assert interactions with mocks instead of behaviour are a liability during exactly the refactoring you are being hired to do. If you can add ArchUnit for structural rules and mutation testing with PIT to show your tests actually detect change, you are ahead of most of the field.

Finally, the operational surface: Actuator and which endpoints you expose and which you absolutely do not, Micrometer metrics, the fact that tracing moved to Micrometer Tracing and OpenTelemetry rather than the old Sleuth, structured JSON logging with correlation identifiers, Resilience4j for timeouts, retries with jitter, bulkheads and circuit breakers, and the single most common production omission in Spring applications: an HTTP client with no timeout configured, which turns a slow dependency into an outage.

• The self-invocation question: "This method is annotated @Transactional and is called from another method in the same class. Is there a transaction?" The answer is no, and you need the reason.
• The N+1 question, usually with code. Know all three fixes and when a projection beats a fetch join.
• The configuration question: where auto-configuration is discovered, and how you override one piece of it without disabling the rest.
• The security question: what builds the filter chain now, how a JWT is validated, and why you would or would not disable CSRF.
• The testing question: how long does your test suite take, what does it start, and what do you use Testcontainers for.
• Version literacy: Spring Boot 3 requires Java 17 or later and moved javax to jakarta; Spring Boot 2 is out of open-source support; the current generation is Spring Framework 7 with Spring Boot 4. Check the published support matrix before quoting dates at anyone, including in an interview.
• Name the omissions you fix on arrival at any codebase: missing timeouts on outbound calls, open-in-view left on, and a connection pool sized by hope. Saying this unprompted reads as experience.

Legacy modernisation: the most valuable Java specialism in 2026-27

If you want the shortest path from competent Java developer to in-demand Java developer, specialise in moving old Java forward. The demand is structural rather than fashionable. Large amounts of revenue-generating code sit on Java 8 and Java 11, on application servers that cost money in licences and in operational friction, and the javax to jakarta namespace change made the Spring Boot 2 to 3 step a genuinely breaking migration that many organisations started late and have not finished. Meanwhile the people who wrote those systems are retiring. Employers are not short of people who can write a new Spring Boot service; they are short of people who will walk into several hundred thousand lines of unfamiliar code with no tests and make it safe to change.

Know the mechanical obstacles, because naming them unprompted is what proves you have done this. Strong encapsulation of JDK internals broke libraries that reached inside, and the usual symptom is a reflective access failure in an old dependency rather than in your own code. Several APIs were removed from the JDK entirely and must be added back as dependencies. The Security Manager has been permanently disabled and its API is on the way out, which matters for old container and plugin architectures. Dynamic agent loading now warns. Default garbage collectors and defaults around them changed, so timing and memory behaviour shift even when nothing else does. Bytecode manipulation libraries, mocking frameworks and old ORMs are the first things to fail on a new JDK, and the usual fix is a dependency upgrade rather than a code change. And the javax to jakarta rename touches annotations, servlet APIs, validation, persistence and JMS at once, which is why it cannot be done piecemeal inside one deployable.

Know the tooling, and know which parts of it are deterministic and which are not. OpenRewrite applies rule-based recipes to a parsed representation of your code, so a migration recipe for an older Java release or for the jakarta rename produces a reviewable, repeatable change rather than a guess: this is the backbone of serious upgrade work, and Moderne is the commercial platform around it. jdeps and jdeprscan tell you what you depend on and what of it is deprecated or encapsulated. The Maven versions and enforcer plugins, plus Dependabot or Renovate, keep the dependency graph moving instead of accumulating a single terrifying jump every five years. Error Prone and NullAway catch a class of defects at compile time. The major cloud vendors now ship assisted upgrade tooling that drives much of a Java 8 to 21 transformation and opens pull requests for the rest, and the honest framing in an interview is that it handles the mechanical bulk while you handle the judgement and the verification.

Know the migration patterns, and name them properly. The strangler fig: put a facade in front of the old system and route capability by capability to new implementations, so the old system shrinks rather than being replaced in one event. Branch by abstraction for in-process changes: introduce an interface, build the new implementation behind it, switch with a flag, delete the old path. An anti-corruption layer so the new model is not deformed by the old schema. Expand and contract for database changes, so schema and code can deploy independently in either order. Change data capture with a tool such as Debezium when two systems must read the same truth during a transition, which is strictly better than dual writes that will drift. Feature flags for the cutover, so the rollback is a flag rather than a redeploy. And the discipline that makes all of it credible: a characterisation test suite written against the old behaviour before you change anything, because you are being paid to preserve behaviour you do not yet understand.

Verification is the part that distinguishes a modernisation specialist from an enthusiastic refactorer, and it is the thing to talk about in the interview. Capture real production requests and replay them against the old and new implementations, then compare the responses field by field and investigate every difference. Measure the behaviour you cannot assert: latency distributions, query counts, memory profile. Use mutation testing to find out whether the suite you inherited actually detects change, because high line coverage with weak assertions is worse than no suite at all, since it creates false confidence. And rehearse the cutover, including the rollback, on something that is not production.

There is a commercial argument you should be able to make, because modernisation budgets are approved by people who do not care about language versions. Supported runtimes get security patches and unsupported ones do not, which is an audit finding waiting to happen. Application server licences and Oracle JDK subscriptions are line items that a migration removes. Build and deploy times are engineering capacity: halving a 40-minute build changes how often the team ships. Newer JDKs give real efficiency on the same hardware, which on a container platform converts directly into a smaller bill. And hiring is easier for a modern stack, which the manager you are talking to feels personally. A candidate who frames a migration in those terms sounds like someone who can get the work funded rather than someone who wants to tidy up.

If you do not currently have a legacy job, you can still manufacture the evidence, and almost nobody applying has. Pick a real open-source Java application still on Java 8 or 11, upgrade it on a branch, and do it in the professional order: OpenRewrite recipes for the mechanical work including javax to jakarta, jdeps and jdeprscan to find encapsulated and deprecated usage, dependency bumps for the bytecode and mocking libraries that fail first, characterisation tests over the behaviour you must preserve, and a model only for the bespoke remainder. Then publish the branch and a short written account: what the recipes handled, what broke at runtime rather than at compile time, and how you proved behaviour held. It is exactly the work you are claiming you can do, and it is a far better artefact than a tutorial project.

• Name the obstacles: strong encapsulation of internals, APIs removed from the JDK, the Security Manager's disablement, default collector changes, bytecode libraries failing first, and the javax to jakarta rename that cannot be done piecemeal.
• Deterministic tooling first: OpenRewrite recipes, jdeps, jdeprscan, dependency update automation, Error Prone. Vendor AI upgrade assistants on top, for the long tail.
• Patterns with their real names: strangler fig, branch by abstraction, anti-corruption layer, expand and contract, change data capture over dual writes, feature-flagged cutover.
• Verification: characterisation tests before changing anything, production traffic replay with field-level comparison, mutation testing to audit an inherited suite, rehearsed rollback.
• The business case: security support, licence removal, build time as capacity, efficiency as infrastructure cost, hiring. Learn to say it in two sentences.
• Anti-pattern to reject out loud in an interview: the big-bang rewrite with a freeze on the old system. Every experienced interviewer has watched one fail, and rejecting it is a cheap way to sound senior.
• Manufacture evidence: upgrade a real open-source Java project across LTS versions and publish the account of what broke and how you proved behaviour held.

Design and production rounds: showing you have operated a Java system, not just written one

The design round in enterprise Java hiring is less about scale than the equivalent round at a consumer internet company and much more about correctness under failure, because the systems move money, medical records, policies and orders. The interviewer wants to see you treat partial failure as the normal case.

Start by refusing to design anything until you know four things: volumes and peaks, what consistency the business genuinely requires as opposed to what it says it requires, what happens when the thing fails, and how a change gets rolled back. Then design for the failure cases explicitly. Idempotency with a client-supplied key so a retried request does not duplicate an effect. At-least-once delivery as the assumption and consumer-side deduplication as the answer, since exactly-once across a broker and a database is not a property you can buy. The transactional outbox so a database write and a message publication cannot diverge, rather than publishing inside a transaction and hoping. Sagas with compensating actions instead of distributed transactions. Optimistic locking with a version column for concurrent edits. Timeouts, bounded retries with jitter, and a circuit breaker, because an unbounded retry policy turns a dependency blip into a self-inflicted denial of service. Backpressure, and a dead-letter queue with an actual plan for what someone does with the messages in it.

Architecture opinions have moved, and your answer should reflect 2026 rather than 2019. Microservices as the reflex answer now reads badly in most enterprise rooms, because the audience has paid for distributed transactions, cross-service debugging and a dozen deployment pipelines for an application with a few hundred users. The current defensible default is a well-modularised single deployable with clear internal boundaries, extracted into separate services only where there is a specific reason: independent scaling, genuinely different availability requirements, team ownership at a scale that makes a shared deployment painful, or a compliance boundary. Be able to say that, and be able to say what you would split and why. Equally, be able to argue the other side for a large organisation, because the right answer is a function of organisation size rather than of taste.

The operational half of the round is where mid-level candidates get capped. Expect to be asked to walk through a production incident, and expect follow-up questions that test whether you were in the room or heard about it afterwards. Have two incidents prepared in detail, told in the same order every time: the symptom as the business saw it, how you confirmed it rather than assumed it, the measurement that identified the cause, the immediate mitigation, the real fix, and the change that stopped the class of problem recurring. Numbers matter here more than anywhere else in the interview.

The failure modes you should be able to diagnose on demand, because they account for most real Java incidents, are a short list. Connection pool exhaustion, where every request waits on a small pool and the stack traces all sit in the same getConnection call: usually caused by a long transaction, an unclosed resource, or open-in-view holding connections across view rendering. The N+1 query that only hurts at production data volumes. A memory leak through a static collection, an unbounded cache without eviction, or a ThreadLocal in a pooled thread. A container killed by the kernel because the sum of heap, metaspace, thread stacks and direct buffers exceeded the limit, which looks like a crash with no Java stack trace at all. Garbage collection thrash from an allocation rate nobody measured. A retry storm amplifying a downstream slowdown. A lock serialising what looked like parallel work, visible as flat CPU and rising latency. And a thread pool tuned by guesswork. For each, know the first thing you would look at and the tool you would look at it with.

Finally, be ready for the deployment and data questions, because they are what makes enterprise releases hard: how you change a database schema with no downtime, how you deploy a breaking API change when you do not control all the clients, how you backfill a new column across a very large table without saturating the database, how you run a canary when the database cannot be rolled back, and how you handle a message format change with consumers you cannot redeploy at the same moment. A schema registry with compatibility rules, versioned endpoints, batched and throttled backfills, and additive-then-cleanup migrations are the expected answers.

• Open every design round with volumes, consistency requirements, failure tolerance and rollback. Asking is scored.
• Reliability vocabulary: idempotency keys, at-least-once plus deduplication, transactional outbox, saga with compensation, optimistic locking, timeouts, bounded retry with jitter, circuit breaker, dead-letter queue with an owner.
• Say the 2026 thing about architecture: a modular single deployable by default, services where there is a specific reason, and be able to name the reasons.
• Prepare two incidents in the same six-part shape: business symptom, confirmation, measurement, mitigation, fix, prevention. With numbers.
• Know the standard incident catalogue cold: pool exhaustion, N+1, leaked static cache, container OOM kill with no Java stack trace, GC thrash, retry storm, lock contention, misconfigured pool.
• Deployment and data: expand and contract schema changes, versioned APIs, throttled backfills, schema registry compatibility, canary with an unrollbackable database.
• If you have never been on call, say so and say what you have done instead. Claiming operational experience you do not have collapses under the second follow-up question.

The resume, the fortnight before you apply, and where the Java jobs are

The central resume problem for Java developers is that experience is abundant and differentiation is scarce. A resume that leads with "12 years of Java/J2EE development" has said something true and useless, and the spelling "J2EE" additionally announces that your vocabulary stopped updating two decades ago, since the platform was renamed Java EE and then Jakarta EE. Lead with what you changed and by how much.

Every bullet should carry a unit. Requests per second, p99 latency in milliseconds before and after, rows processed, build minutes, number of services or modules, team size you led, licence or infrastructure spend removed, defect rate, release frequency. "Optimised application performance" is invisible. "Cut checkout p99 from 1.9s to 240ms by replacing an N+1 repository call with a projection and adding a keyset-paginated query, verified with a replayed production load" is a conversation. If you genuinely cannot get numbers from a previous employer, use counts and shapes you can defend rather than inventing a percentage, because an invented number dies at the first follow-up question.

Name versions. "Java 21, Spring Boot 3.3, Postgres 16, Kafka, Kubernetes" tells a reader exactly where you sit and gets matched by literal keyword search. "Java, Spring, SQL, cloud" tells them nothing and matches less. If your current job is on Java 8, write Java 8 and then write the upgrade work you did or proposed, because honesty plus direction beats vagueness.

What gets ignored or actively hurts: a skills section with proficiency bars; a thirty-item technology list that includes everything you touched once; "Agile", "Scrum" and "SDLC" as skills; an objective or summary that describes a passion for technology; responsibilities copied from a job description; two columns and a sidebar, which applicant tracking systems parse badly; and a photograph if you are applying in the US or UK. Keep the layout boring and the content specific. Enterprise employers run Workday, Taleo, SuccessFactors and iCIMS more often than Greenhouse or Lever, and those systems are less forgiving of creative formatting.

For contractors, structure the document around engagements: client, sector, dates, stack, and the outcome delivered, with early engagements compressed to a line each. For permanent candidates with long tenure at one employer, split the entry by role or by project so that progression is visible, because fifteen years as one bullet list reads as fifteen years of the same year.

Before you send anything, build the artefact, because it changes every conversation that follows. One small Spring Boot service on a current LTS that you would be happy for a senior engineer to read, finished rather than ambitious. Specifically: Postgres through Testcontainers in the tests, a Flyway migration rather than schema generation, one endpoint with keyset pagination, one outbound call with an explicit timeout and a Resilience4j circuit breaker, Actuator with health and metrics exposed and the dangerous endpoints closed, structured JSON logs with a correlation identifier, and a README whose first line is the single command that runs it. Four endpoints that run beat a half-built platform.

Then do the talking homework, out loud, once each: the sixty-second version of your stack; the self-invocation answer and why; the three N+1 fixes; where auto-configuration is discovered and how you override one piece of it; what builds the security filter chain; your position on WebFlux versus virtual threads; and two incidents in the six-part shape (business symptom, confirmation, measurement, mitigation, fix, prevention). Alongside that, gather the facts about your current employer that senior screens assume you know: which JDK build and version, which Spring Boot version, who decided, how long the test suite takes, how many manual steps a release involves, which garbage collector is in use. That is a ten-minute errand, and not knowing it is read as sitting a long way from production.

Where the jobs are: banks, insurers, payment processors and exchanges; telcos; healthcare administration and payers; government and government contractors; ERP, supply chain and logistics; large retailers and their fulfilment systems; and business-to-business SaaS companies with backends old enough to have a migration backlog. Add the system integrators and consultancies, which hire continuously and in volume, and which are the fastest route into modernisation work even if the day rate at the top of the chain is not yours. Geographically, India holds the largest concentration of Java engineers in the world, mostly in IT services; Poland, Romania, Portugal and Spain are the nearshore centres for Western Europe; Mexico, Brazil, Colombia and Argentina for the US. Remote work survives in Java more than in some disciplines, but large banks have pulled hardest back toward the office, so read the on-site expectation as a real constraint rather than a negotiable one.

Run the search on three channels at once. Direct applications to employers whose stack you can name, which is where your version-specific resume pays off. Agencies and staffing firms, which hold a large share of enterprise Java briefs and respond to being treated as a professional relationship: tell two or three good recruiters precisely what you want and keep them updated instead of spraying applications. And referrals, which in this market come from former colleagues more than from conferences, because enterprise Java teams are long-lived and people move in groups. The one path that reliably disappoints is high-volume applications to generic postings: the postings are generic because the role is being filled through a channel you are not in.

• Delete "J2EE" and "N years of Java" from the top of the resume. Replace with one migration or performance outcome with units.
• Name versions explicitly: JDK major version, Spring Boot major version, database, broker, platform.
• Every bullet gets a number or a count you can defend under questioning. Never invent a percentage.
• Cut: skills bars, technology laundry lists, Agile as a skill, objective statements, multi-column layouts, photos in US and UK applications.
• Format for Workday and Taleo as well as Greenhouse: single column, standard headings, plain bullet characters, a real PDF with extractable text.
• Contractors: engagement per entry with client, sector, stack and outcome. Long-tenure candidates: split by role or project so progression shows.
• Build one finishable service: Testcontainers, Flyway, keyset pagination, a timeout and circuit breaker, Actuator, structured logs, a one-command README.
• Rehearse out loud: the sixty-second stack summary, the four Spring answers, the WebFlux position, and two incident stories with numbers.
• Find out this week: your employer's JDK build, Spring Boot version, test suite runtime, release step count and garbage collector.
• Settle the salary or day rate you will say without flinching, and keep a written submission log so no agency double-submits you to the same client.
• Target sectors with old code and regulatory pressure, because that is where Java money is: finance, insurance, healthcare administration, telco, government, logistics, ERP.
• Work three channels: direct applications where you can name the stack, two or three recruiters treated as relationships, and former colleagues. Volume applications to generic adverts are the worst use of your time.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Java Developer
• Java Engineer
• Senior Java Developer
• Java Software Engineer
• Backend Developer
• Backend Engineer
• Java Backend Engineer
• Full Stack Java Developer
• Java Consultant
• Java Architect
• Java
• Java 8
• Java 17
• Java 21
• Java 25
• JDK
• OpenJDK
• Eclipse Temurin
• Amazon Corretto
• JVM
• Jakarta EE
• Java EE
• Kotlin
• Scala
• Spring
• Spring Boot
• Spring Boot 3
• Spring Framework
• Spring MVC
• Spring WebFlux
• Spring Data JPA
• Spring Security
• Spring Cloud
• Spring Batch
• Spring AI
• Spring Boot Actuator
• Micrometer
• Resilience4j
• Project Reactor
• WebClient
• Hibernate
• JPA
• jOOQ
• MyBatis
• JDBC
• HikariCP
• Flyway
• Liquibase
• SQL
• PostgreSQL
• Oracle Database
• Microsoft SQL Server
• DB2
• Redis
• Elasticsearch
• pgvector
• Database migration
• REST API
• RESTful services
• OpenAPI
• gRPC
• GraphQL
• SOAP
• JAXB
• Jackson
• Avro
• Schema Registry
• Apache Kafka
• Kafka Streams
• RabbitMQ
• IBM MQ
• JMS
• Apache Camel
• Apache Flink
• Event-driven architecture
• Transactional outbox
• Saga pattern
• Idempotency
• Change data capture
• Debezium
• Microservices
• Modular monolith
• Domain-driven design
• Hexagonal architecture
• API gateway
• Maven
• Gradle
• Jenkins
• GitHub Actions
• GitLab CI
• Artifactory
• SonarQube
• Docker
• Kubernetes
• Helm
• OpenShift
• ArgoCD
• Terraform
• AWS
• Azure
• AWS Lambda
• GraalVM
• Native image
• Quarkus
• Micronaut
• Vert.x
• Tomcat
• WebLogic
• WebSphere
• JBoss EAP
• JUnit 5
• Mockito
• AssertJ
• Testcontainers
• WireMock
• ArchUnit
• PIT mutation testing
• JMH
• Pact contract testing
• Gatling
• k6
• Test-driven development
• Characterisation tests
• Virtual threads
• Project Loom
• Structured concurrency
• Scoped values
• Concurrency
• java.util.concurrent
• CompletableFuture
• Java memory model
• Garbage collection
• G1GC
• ZGC
• JFR
• Java Flight Recorder
• JDK Mission Control
• async-profiler
• Eclipse MAT
• Heap dump analysis
• Performance tuning
• Profiling
• Low latency
• Observability
• OpenTelemetry
• Distributed tracing
• Structured logging
• On-call
• Incident response
• Root cause analysis
• Legacy modernisation
• Application modernisation
• Java upgrade
• javax to jakarta migration
• OpenRewrite
• Strangler fig pattern
• Branch by abstraction
• Expand and contract migration
• Refactoring
• Technical debt reduction
• Monolith decomposition
• OAuth 2.0
• OpenID Connect
• JWT
• OWASP Top 10
• SBOM
• Dependency scanning
• Git
• Feature flags
• LangChain4j
• Model Context Protocol
• Retrieval-augmented generation
• Vector database
• Prompt injection
• AI-assisted development

Mistakes that cost people this job

Questions people ask