Java Developer Interview Questions: What to Ask at Each Stage
Last updated: August 13, 2026
Most Java developer interview processes test the wrong things. Algorithmic puzzles that have no relation to the actual codebase. Trivia questions about deprecated APIs. Whiteboard exercises that bear no resemblance to what the person will do on their first sprint.
The questions below are organized by interview stage and weighted toward what actually predicts performance in a Spring Boot microservices environment. For nearshore hiring specifically, there’s an additional section on evaluating async communication and real-time English, since those are often what make or break an embedded remote hire.
Core Java and JVM Questions
These questions are for the first technical screen, typically 30 minutes. The goal is to establish whether the candidate’s Java fundamentals are solid enough to work in a modern codebase without constant hand-holding.
Spring Boot Technical Questions
These belong in the second screen or combined with a live coding element. Spring Boot is where the majority of professional Java development happens in 2026, and it has its own patterns that don’t emerge naturally from pure Java knowledge.
Live Coding Assessment Guide
The live coding session is where you see how candidates actually think, not just what they can recall. Keep it realistic. Give them a problem that resembles something from your actual codebase.
What to ask in a 90-minute live coding session
A good live coding problem for a Spring Boot developer involves building a small service with at least three of these elements:
- A REST endpoint that accepts a request and validates it
- A service layer that applies business logic
- A repository layer with a simple database interaction
- Exception handling that returns a consistent error response
- At least one unit test for the service layer
The complexity should take a strong mid-senior developer about 60 minutes, leaving 30 minutes for discussion. Candidates who finish in 30 minutes are going fast but may have skipped error handling or tests. Candidates who don’t finish in 90 are struggling with something worth investigating.
What to watch during live coding
| Signal | What It Means |
|---|---|
| Uses constructor injection automatically | Spring internals are part of their natural coding, not memorized for interviews |
| Writes the test before the implementation (or immediately after) | Tests are part of their workflow, not an afterthought |
| Asks a clarifying question about error cases before coding | Production mindset. They’re thinking about the unhappy path. |
| Explicitly handles null or missing values | Has been burned by NullPointerException in production |
| Talks through decisions as they code | Will communicate clearly in async PR reviews and Slack threads |
| Reaches for documentation mid-session | Normal and healthy. Good developers know what to look up. |
| Uses field injection and skips tests | Red flag regardless of how fast the feature works |
Skip Building Your Own Process
Kore BPO pre-screens nearshore Java developers through 5 technical stages before you interview. Profiles in 2 to 5 days.
System Design Questions
System design questions should match the complexity of what the person will actually own. A developer who will maintain one service in a large microservices platform needs a different system design question than someone who will architect a new platform.
Communication and Nearshore Fit Questions
These questions are specifically for evaluating nearshore Java developers who will work embedded in a US team. They are not generic culture-fit questions. They evaluate the specific communication and self-management abilities that determine whether a remote hire succeeds in a distributed sprint environment.
Async writing test: Before the final round, send the candidate a technical question by email or Slack and ask them to respond within 24 hours. The written response tells you more about their day-to-day communication quality than two additional hours of video interviews. Evaluate for clarity, technical precision, and the absence of ambiguity in their answer.
Good Answers vs. Red Flags
Interview evaluation drifts without reference points. Use these as benchmarks when scoring candidates after each stage.
Spring Boot injection question
Strong answer: “I prefer constructor injection because it makes dependencies explicit, supports immutability, and makes the class easier to test without a Spring container. Field injection with @Autowired works but you can’t instantiate the class without reflection in tests.”
Red flag: “I use @Autowired on the field because it’s cleaner and Spring handles it.” No mention of testability, no awareness of the trade-off.
Concurrency question
Strong answer: “synchronized gives you mutual exclusion on a monitor, volatile ensures visibility across threads without mutual exclusion, and AtomicInteger gives you lock-free atomic operations through CAS. For a simple counter in a high-concurrency context, AtomicInteger is usually the right choice.”
Red flag: Conflating volatile with synchronized, or saying they avoid concurrency by “not using threads.” Most Spring Boot services handle concurrent requests by default.
System design question
Strong answer: Starts by asking clarifying questions: volume, SLA, idempotency requirements. Then proposes an async design with a message queue, separate consumers per channel, and retry/dead-letter handling. Mentions observability and failure modes proactively.
Red flag: Immediately starts drawing boxes labeled “Notification Service” with synchronous calls to Email API, SMS API, and Push API with no discussion of failures, scaling, or retries. Jumps to implementation before understanding requirements.
Communication question
Strong answer: “I opened a Jira ticket with the exact error, what I’d already tried, and an estimated delay. I posted an update in Slack tagging the tech lead so it was visible. Meanwhile I picked up a different ticket to keep moving.”
Red flag: “I kept working on it for two days before I mentioned it in standup.” Two days of silent blocking is a significant communication failure in a distributed team.
Frequently Asked Questions
How many interview rounds should a Java developer process have?
Three to four structured stages is typical: a 30-minute phone screen for core Java, a 90-minute live coding session, a 30-minute system design conversation, and a 20-minute communication and team fit round. More than four rounds loses strong candidates to faster-moving offers. Fewer than three rounds risks missing fundamental gaps that surface in the first sprint.
Should I use take-home assignments or live coding for Java interviews?
Live coding is significantly more predictive for nearshore roles specifically, because you evaluate both technical ability and communication style simultaneously. A take-home assignment tells you what someone can produce in isolation with unlimited time and documentation. A live coding session tells you how they think, communicate under mild pressure, and handle gaps in their knowledge in real time, which is what embedded remote work looks like daily.
What Spring Boot version should I ask about in the interview?
Ask about the version you’re running or planning to run. If you’re on Spring Boot 3.x, the interview should reflect 3.x specifics: Jakarta EE namespace changes, the ProblemDetail RFC 7807 support, and Java 17 as the minimum baseline. If you’re still on 2.x, ask about 2.x but probe whether the candidate knows about the migration path. Mismatching the interview to the actual stack wastes everyone’s time.
How do I evaluate English communication in a Java developer interview?
Evaluate it across the whole interview, not as a separate category. Watch whether the candidate volunteers context without being asked, whether they ask clarifying questions clearly, whether their explanations have structure, and whether you have to ask them to repeat themselves. Also send the 24-hour written async test. Written communication quality is a separate but equally important signal for nearshore roles, and most interview processes skip it entirely.
How does Kore BPO screen nearshore Java developers before presenting them?
Kore BPO runs a five-stage process: a Java fundamentals assessment covering JVM and concurrency, a Spring Boot live coding test in the candidate’s own environment, a system design interview scoped to the client’s architecture, an async written communication evaluation, and direct reference verification with prior US employers or clients. Candidates who reach your interview have already passed all five stages. More detail on the process is at korebpo.com/nearshore-java-developers.
Disclosure: Kore BPO is a nearshore staffing agency. This guide reflects our direct experience screening Java developers from Costa Rica for US engineering teams.
Get Pre-Screened Java Developers
Kore BPO runs 5 technical screening stages before you see a resume. Costa Rica candidates in 2 to 5 business days.
View Available Java Developers


