How to screen a Java developer in 20 minutes

To screen a Java developer in 20 minutes, test the few skills the role actually needs, ask questions that force specifics, and follow up on every answer until you hear either real detail or a vague summary. Match the questions to the level: juniors should explain core Java clearly, mid-level developers should show how they build and debug services, and seniors should talk through trade-offs they have made under real constraints. You don't need to write Java yourself to hear the difference.

This guide gives you a 20-minute structure, example questions we wrote for it, what strong and weak answers sound like, and the red flags worth writing down. It reflects the Java ecosystem as of September 2026.

What should you confirm before the screen?

Ten minutes with the hiring manager saves you from testing the wrong things. Get answers to these:

• Which Java version does the team run? Many teams sit on a long-term support release. JDK 21 reached general availability on 19 September 2023 and JDK 25 on 16 September 2025. A candidate who only knows Java 8 idioms may still be fine, but you should know if the team expects newer features.
• Which framework? Spring Boot is common, but some teams use Jakarta EE, Quarkus, Micronaut or plain Java.
• What kind of system: web APIs, batch jobs, data pipelines, Android, trading systems? Each needs different depth.
• Which database and messaging tools matter (for example PostgreSQL, Oracle, Kafka)?
• Which two or three skills would make the hiring manager reject someone outright?
• What level is the role, really? Titles vary a lot between companies.

Write the must-have skills down. They become your question plan.

What should you test at each level?

A senior candidate should still answer the junior questions well. If they can't explain equals and hashCode, the rest of the conversation matters less.

How should you structure the 20 minutes?

Keep the core-skills block tight. It is better to go deep on three questions than to skim eight.

What questions should you ask a Java developer?

These are examples written for this guide. Swap in the team's framework and domain.

Junior

1. "You put objects of a class you wrote into a HashSet, and later the set says it doesn't contain one you know you added. What would you check first?"
2. "When would you pick an ArrayList over a LinkedList, or the other way around, in code you've written?"
3. "Your method reads a file and the file might not exist. Walk me through how you'd handle that and what the caller sees."
4. "Tell me about the last unit test you wrote. What was it checking, and what would have made it fail?"

Mid-level

1. "A REST endpoint in your service got slow last week. Nothing was deployed. How do you find out why?"
2. "You have a method that saves an order and then updates stock, and the stock update throws an exception. What happens to the order, and how did you control that in your last project?"
3. "How do you decide what goes in a unit test versus an integration test in a Spring Boot service?"
4. "You see the same SQL query run a hundred times on one page load. What's likely going on, and how would you fix it?"

Senior

1. "Your service runs fine at normal load but falls over at twice the traffic. Memory climbs and then it restarts. How do you investigate, and what would you change?"
2. "Two instances of your service both process the same message from a queue. How do you stop that from creating duplicate side effects?"
3. "Java 21 added virtual threads. Where would you use them in a service like yours, and where would you be careful?"
4. "Tell me about a design decision you made that you'd change now. What did it cost, and who else was affected?"

Follow-ups that work at any level

• "What exactly did you do, as opposed to the team?"
• "What was the number? How slow, how many requests, how much memory?"
• "What did you try first that didn't work?"
• "How did you know it was fixed?"

What do strong and weak answers sound like?

Take the mid-level question about a slow endpoint.

A weak answer: "I'd check the logs and look at performance, maybe add caching." Nothing is wrong in it, and nothing shows they've done it.

A strong answer names an order of steps and tools: check the metrics dashboard for latency by endpoint, see whether the database, a downstream service or the JVM itself is the slow part, look at the slow query log or a trace, check garbage collection and thread pool saturation, then reproduce with a load test before changing anything. They mention what they found last time it happened to them.

The same pattern holds across questions:

For the senior virtual threads question, a strong answer says something like: they help with many blocking I/O calls, they don't make CPU-heavy work faster, and you watch out for code that holds locks or pins threads, plus libraries that assume a small pool. A weak answer describes virtual threads as "lightweight threads that improve performance" and stops.

What red flags should you write down?

• Answers read like documentation: correct definitions, no example from their own work.
• Detail collapses under one follow-up question.
• Long pauses before every answer, followed by a polished paragraph, especially if the candidate's eyes keep moving to one spot.
• The project on the resume and the project described out loud don't match on stack, dates or team size.
• They can't name the Java version or framework version they used last.
• They blame every outage on someone else and describe no fix of their own.
• For remote roles, the voice or face changes between rounds, or they refuse any camera or ID step without a reason.

A red flag is a reason to probe in your own call, not a verdict on its own. Nervous candidates pause, and some strong engineers are terse. Write down what you saw and ask about it. If identity is the worry, how to spot a proxy interview goes into the warning signs, and AI cheating in interviews covers hidden assistants and what a recruiter can actually see.

How do you run a Java screen with Simplehire?

You create the role with the must-have skills you agreed with the hiring manager (for example Java 21, Spring Boot, PostgreSQL, REST APIs) and send the candidate an interview link. The candidate talks with our AI interviewer in the browser, and you get a screening report to read before you submit anyone.

For Java roles we'd pick one of two tiers:

The Basic tier ($2, about 15 minutes) works for a quick fit check on junior roles, and every account gets 25 free Basic screens a month with no credit card required.

The report starts with a Screen verdict: Advance, Maybe or Reject. Under it you get Skills demonstrated X/Y against the skills you set, a Screen summary, Strengths, Areas to probe and Key insights. Areas to probe is the part to bring into your own call. The verdict is a recommendation; you decide who moves forward.

Every screen runs in enforced full-screen mode, with copy and paste restricted or flagged and tab switches recorded with timestamps. For remote senior roles where a proxy would hurt, you can require an ID check with a live face match or a paired second device that shows the candidate's desk. Every alert is reviewed by a person. The proctoring page covers each option.

See the pricing page for the full table, or create a free account and run your next Java req through it. If you're comparing screening formats first, our AI voice interview vs one-way video comparison sets them side by side.