Java developer screening questions: Java 17, 21 and 25, Spring Boot, the JVM and Oracle certifications

Java developer screening questions should establish which Java versions and frameworks the candidate has shipped to production (in 2026 that usually means Java 17, 21 or 25 with Spring Boot), what they personally built on the server side, how they handle concurrency, memory and performance on the JVM, and how they test and release. As of November 2026, Oracle lists Java SE 8, 11, 17, 21 and 25 as its long-term support releases, and its roadmap moves Java 17 from Premier to Extended Support after September 2026, so an upgrade story is one of the fastest ways to hear real depth. No license is required, and Oracle's certifications show study rather than production ownership.

The general method for screening any engineer, including the ownership ladder, is in software engineer phone screen questions, and the full loop after your screen is in the interview guide for software engineers. This page adds what is specific to Java: the version and framework the team runs, the JVM, the build, and the ways Java resumes overstate. To find candidates before you screen them, use the Boolean search strings for Java developers.

Which Java developer job is it?

Ask the hiring manager for the Java version, the framework and its version, the build tool, where the code runs (Kubernetes, a cloud service, an application server) and whether the role carries on-call. Then screen against that, not against every library on the job ad.

Which versions and certifications should you check?

• Java releases. Oracle's Java SE support roadmap lists Java SE 8, 11, 17, 21 and 25 as long-term support (LTS) releases and says Oracle intends to make an LTS release every two years, with Java 29 planned for September 2027. Java 25 reached general availability in September 2025. The roadmap lists Premier Support for Java 17 until September 2026, Java 21 until September 2028 and Java 25 until September 2030 (each "or later"), and waives the Extended Support fee for Java 17 from October 2026 to September 2029. Non-LTS releases (Java 26 in March 2026, Java 27 in September 2026) are superseded every six months, so few production teams standardize on them.
• Spring Boot. Spring's support timeline shows Spring Boot 4.0 released in November 2025 and 4.1 in June 2026; open-source support for 3.5 ended in June 2026 and for 2.7 in June 2023, with paid commercial support running longer. The system requirements page says Spring Boot 4.1.2 requires at least Java 17 and is compatible up to Java 27. The Spring Boot 3.0 migration guide says 3.0 required Java 17 and moved to Jakarta EE 10, which uses jakarta packages rather than javax.
• Concurrency features. JEP 444 made virtual threads final in JDK 21, and JEP 491 in JDK 24 lets virtual threads that block inside synchronized code release their carrier thread, which removes most of the "pinning" problems developers hit on Java 21.
• Oracle certifications. Oracle's certification page lists Java SE 25 Developer Professional (exam 1Z0-831), Java SE 21 Developer Professional (1Z0-830), Java SE 17 Developer (1Z0-829), Java SE 11 Developer (1Z0-819), Java SE 8 Programmer I and II (1Z0-808 and 1Z0-809), Java Foundations (1Z0-811) and Java EE 7 Application Developer (1Z0-900). Candidates keep their records in Oracle CertView; if a client requires a certification, ask the candidate to share the record from there.

Knockout questions

Java and JVM depth questions

1. "Tell me about the last Java version upgrade you did. What broke?"
   • Strong answer: a from-and-to version and real breakage: Java EE APIs such as JAXB missing after 11 (JEP 320 removed them from the JDK), libraries reaching into JDK internals failing on 17 (JEP 403 strongly encapsulated them), or the javax to jakarta rename during a Spring Boot 3 move, and how they tested it.
   • Red flags: "It just worked," or has never upgraded anything, for a modernization role.
2. "Have you used virtual threads? Where did they help, and where did they not?"
   • Strong answer: used them for I/O-bound request handling on 21 or later, does not pool them, knows CPU-bound work gains nothing, and mentions pinning with synchronized on 21 or the fix in later JDKs.
   • Red flags: "We switched everything to virtual threads and it got faster," with no measurement.
3. "Tell me about a memory or garbage collection problem you diagnosed in production."
   • Strong answer: a heap dump or GC logs, JDK Flight Recorder or a profiler, a cause such as an unbounded cache or a ThreadLocal leak, and a fix they confirmed, including container memory limits.
   • Red flags: the only tool is raising -Xmx.
4. "An endpoint got slow. Walk me through how you found out why."
   • Strong answer: measured first (traces, metrics, a profiler), then found a cause such as N+1 queries from JPA or Hibernate, an undersized connection pool or a slow downstream call, and gives a before and after.
   • Red flags: guesses, or "we added more pods."
5. "In your Spring Boot service, how does a request reach your code, and where does the transaction start and end?"
   • Strong answer: the security filter chain, controller, validation, service, repository, where @Transactional sits and a bug they hit because of it, and how errors become responses.
   • Red flags: recites annotations without saying what they did in their own service.
6. "How did your team find out whether it was exposed to Log4Shell in December 2021?"
   • Strong answer: searched dependency trees or a software bill of materials, patched or mitigated, and knows how the team tracks vulnerable libraries now. CISA's Log4j guidance describes the flaw (CVE-2021-44228) if you want the background.
   • Red flags: "We weren't affected," without anyone having checked. (A candidate who started their career after 2021 can answer the same question about any library upgrade forced by a vulnerability.)

Testing, build and release questions

For pipeline and on-call depth, borrow from the DevOps engineer screening questions; for a coding exercise after the screen, keep it short and scored the same way for everyone, as in how to evaluate a take-home assignment.

How does Java experience get overstated?

• The version range. "Java 8 to 21" when only Java 8 ran in production. Ask which version each product used and when.
• Spring Boot by template. Generated a project and added endpoints, never owned configuration, security or upgrades. Ask what they changed in the configuration.
• "Microservices architecture." One monolith with a second service beside it. Ask how many services, and who owned each.
• Concurrency as a keyword. Used an executor once. Ask about a race condition or deadlock they fixed.
• Kafka experience. Consumed from a topic someone else designed. Ask about partitions, consumer groups or a replay they ran.
• Android counted as server-side Java. Different job; ask what ran on a server.
• Team performance as personal. "Cut latency 60 percent." Ask for the baseline, the change and who else worked on it.

A 15-minute phone-screen flow

1. Minutes 0 to 2: the product, the Java and framework versions, where it runs and the team's working pattern.
2. Minutes 2 to 5: knockouts 1 to 4.
3. Minutes 5 to 10: the upgrade question and one of the concurrency, memory or slow-endpoint questions. Write down versions, numbers and causes in their words.
4. Minutes 10 to 13: one testing and one release question.
5. Minutes 13 to 15: pay expectations (see salary expectation questions), notice period and next steps.

Scoring

What to put in the submittal

Java developer: [name]
Java versions in production: [e.g. 17 (2023-2025), 21 (2025-now)], on [products]
Framework: [Spring Boot version / Jakarta EE / other], what they owned in it
Build and runtime: [Maven or Gradle], [Kubernetes / cloud service / app server]
Upgrade story: [from-to version, what broke, how tested]
Performance or memory story: [problem, tool, cause, before and after]
Testing: [unit / integration / end-to-end], tools
On-call and incidents: [yes or no, last incident in a sentence]
Certifications (if the client requires): [name, exam number, shared from CertView]
Candidate's own gap: [e.g. "no virtual threads in production; Kafka as consumer only"]

Lawful phrasing

Java screens drift toward age through graduation years, "digital native" language or how long ago someone first wrote Java. Ask about versions, systems and recent work instead; the age discrimination guide explains the risk. Ask the work authorization and sponsorship questions the same way of every candidate, and never ask about citizenship or where someone is from. For fully remote roles, the FBI's January 2025 public service announcement on North Korean IT workers advises identity verification during interviewing and onboarding; apply the same steps to everyone, as described in how to verify candidate identity on a phone screen. The full list of questions to avoid is in illegal interview questions. This page is not legal advice.