Java Developer interview
Java Developer interview practice
A Java-developer interview mixes fundamentals with reasoning: can you explain OOP without reciting a textbook, pick the right collection for a problem, and talk through how you'd debug something that only breaks in production. Interviewers push with follow-ups because a memorised definition falls apart the moment they ask 'why'.
This rehearsal is a spoken interview built around a real Java-backend posting. It moves from core language and OOP, into how you'd approach a coding problem, a debugging situation, and the trade-offs behind a design choice — reasoned aloud, the way a real screen runs.
The report tells you whether your fundamentals were solid, whether you thought a problem through instead of pattern-matching, and how clearly you communicated your reasoning.
Java Developer interview at a glance
- Rounds
- Two to four — a screen, a core-Java round, a framework round, sometimes a design round
- Length
- 40–60 minutes each; the core-Java round is usually the earliest hard filter
- The recurring trio
- Collections, concurrency, and how Spring wires an object together
- Version matters
- Say which Java you have actually used — 8, 11, 17 and 21 are different interviews
- Asked more than candidates expect
- Exception handling and transactions, not algorithms
- Prep that pays
- Being able to say why HashMap is not thread-safe, out loud, without a diagram
What actually happens in a Java Developer interview
Screen~20 min
Which Java version, which framework generation, build tool, and whether your experience is greenfield or maintenance on an older codebase. Maintenance experience is not a weakness here and pretending otherwise is easy to catch.
Core Java~45 min
Collections and their trade-offs, equals and hashCode together, immutability, and where the JVM puts things. This round is answered rather than coded, and the questions are deliberately ones you either understand or have memorised — follow-ups exist to tell those apart.
Concurrency~30 min
Threads, the executor framework, what synchronized actually guards, and why a HashMap breaks under concurrent writes. Interviewers ask this because concurrency bugs are the ones their team has actually shipped, and the answers reveal whether you have debugged one.
Framework round~45 min
Dependency injection, bean scopes, what an annotation is doing underneath, how a request travels through the layers, and how transactions are declared and where they silently do nothing. Being able to explain what the framework does for you is the whole round.
Design or code review~45 min
Either a small service design or an existing class handed to you for critique. The review format is common in Java hiring because so much of the work is maintenance, and it is a fair test of whether you can read code you did not write.
What this interview assesses
Core Java & OOP
Can you explain OOP, collections and exception handling in your own words and apply them — not recite definitions — and reason about when to use what?
Problem Solving
Do you break a coding problem down, state your approach and its complexity, and talk through trade-offs rather than jumping to the first solution?
Debugging & Design Sense
Given a bug or a design choice, do you reason systematically — reproduce, isolate, hypothesise — and justify a decision with its trade-offs?
Sample Java Developer interview questions
A feel for the kind of questions you’ll face. The real interview reacts to your answers with live follow-ups — these are examples, not the exact set.
1.When would you use an ArrayList versus a HashMap versus a HashSet?
What lands: Tie each to what it's good at — order and index access, key lookups, uniqueness — with the cost. Show you choose by the problem, not by habit.
2.A service works fine in testing but throws NullPointerExceptions in production. How do you approach it?
What lands: Be systematic: reproduce, read the stack trace, isolate the input that triggers it. Don't guess — narrow it down.
3.Explain the difference between checked and unchecked exceptions, and when you'd use each.
What lands: Go past the definition to the design judgement — recoverable vs programming errors — and admit where teams disagree.
4.Walk me through how you'd solve: find the first non-repeating character in a string.
What lands: Think out loud, state the data structure and the time/space cost, and handle edge cases. The reasoning matters more than the perfect line.
5.How do you make sure your code is correct before it ships?
What lands: Name real practices — unit tests, edge cases, code review, reasoning about failure — not just 'I test it'.
The job description it’s built around
The free taster rehearses against this realistic Java Developer posting. In a full rehearsal you can paste the exact job you’re targeting instead.
Read the sample job description
Java Developer (0–3 yrs) · Product Engineering · Pune / Hybrid About the role We build backend services in Java and Spring. We're hiring developers who write clean, correct code and can reason about why it behaves the way it does. What you'll do - Build and maintain backend services and REST APIs in Java (Spring Boot) - Write clean, testable code and meaningful unit tests - Debug issues across the stack, including ones that only appear under load - Work with SQL databases and reason about query performance - Participate in code reviews and design discussions - Own features from ticket to production What we're looking for - CS/IT graduate or equivalent; 0–3 years, strong freshers welcome - Solid core Java: OOP, collections, exceptions, generics, concurrency basics - Data-structures and problem-solving fundamentals - Familiarity with Spring, SQL and Git - The habit of explaining your reasoning clearly Nice to have - Spring Boot / microservices exposure - Testing (JUnit), CI, or cloud basics
Java Developer interview — the specifics worth knowing
- Which Java version you have actually shipped changes the interview. Lambdas and streams are assumed from 8 onward, records and sealed types from 17, and virtual threads shift the concurrency conversation entirely.
- How we know: Language features are the vocabulary an interviewer draws questions from. Check the posting for a version and name yours honestly — claiming a version you have only read about fails on the first follow-up.
- equals and hashCode are asked as a pair, and the expected answer is why breaking the contract between them makes an object disappear from a HashSet.
- How we know: It is the canonical Java correctness bug and appears in the language documentation for both methods. If you can state the consequence rather than the rule, you have answered it well.
- Concurrency questions are usually about visibility and shared mutable state, not about writing a thread pool from scratch.
- How we know: The bugs teams actually hit are races on shared fields, not missing infrastructure. Interviewers ask what they have had to fix.
- In a Spring round, the highest-value thing you can explain is what an annotation does underneath — that dependency injection is a container constructing and wiring objects for you, not compiler magic.
- How we know: Framework interviews separate configuration recall from understanding. Anyone can name @Transactional; describing the proxy that makes it work is the answer that distinguishes you.
- Transactions come up in almost every Spring loop, and the trap is a case where the annotation is present and does nothing — a self-invocation inside the same class, or a checked exception that does not trigger a rollback by default.
- How we know: These are documented behaviours of proxy-based transaction management and are common production surprises. Reproduce one once and the question stops being memory.
- Maintenance experience on an older codebase is an asset in a Java interview rather than something to talk around, because much of the work being hired for is exactly that.
- How we know: Java's presence in enterprise systems means a large share of open roles are on long-lived codebases. A candidate who can describe safely changing code they did not write is describing the job.
- Exception handling is asked more often than algorithms in Java loops — checked versus unchecked, and what you actually do in a catch block that is not logging and rethrowing.
- How we know: Checked exceptions are a Java-specific design decision, so the question is language-specific in a way that a generic algorithm question is not. Interviewers use it to test judgement rather than recall.
- A code-review round is common and is scored on what you notice first. Naming a correctness or thread-safety problem before a style preference is the signal being looked for.
- How we know: Reviewing is a daily task on a maintained codebase, so it is a direct work sample. Order your comments deliberately: correctness, then safety, then readability.
- String handling still appears, and the question is almost never about syntax — it is about why concatenating in a loop is a problem and what the compiler already does for you.
- How we know: String immutability is a language guarantee with a measurable cost, which is why the question survives. Say what the JVM allocates rather than reciting that strings are immutable.
- Build tool and dependency management come up in maintenance-heavy roles: how you would resolve a version conflict, and what you would do about a transitive dependency you cannot upgrade.
- How we know: Long-lived Java projects accumulate dependency trees, so this is real daily work rather than trivia. Any conflict you have personally resolved is a sufficient answer.
Common mistakes — and what to do instead
Reciting that HashMap is not thread-safe without being able to say what goes wrong.
Describe the failure — two threads resizing the same map, entries lost or a lookup that never returns. The consequence is the answer; the label is the question.
Listing Spring annotations you have used.
Take one and explain the mechanism beneath it. A single annotation explained properly outweighs a list of twelve names.
Claiming a Java version because it is on the job description.
Name what you have shipped, then say which newer features you have read about. Interviewers ask follow-ups precisely because this claim is so often inflated.
Opening a code review with formatting and naming.
Lead with anything that could be wrong at runtime — a shared field, an unclosed resource, a swallowed exception. Style comments after that read as thoroughness; style comments first read as the ceiling of what you saw.
Preparation checklist
- Write down the Java version and framework generation you have actually shipped
- Be able to explain equals and hashCode by their consequence, not their rule
- Prepare one concurrency bug you have seen or reproduced yourself
- Pick one annotation and learn what it does underneath
- Reproduce a transaction that silently does not roll back, once
- Prepare a maintenance story: changing code you did not write, safely
- Rehearse reviewing a class aloud, correctness first
- Have an answer for what you do in a catch block besides logging
Java Developer interview — FAQs
Is this for Java freshers and early-career backend developers?
Yes. It's built for entry-level Java and backend roles, including strong freshers preparing for product-company interviews. It rewards clear fundamentals and reasoning.
Do I write code during the interview?
You reason about problems out loud rather than typing in an editor — the spoken screen most companies run before a coding round. It rehearses how you explain your approach, complexity and trade-offs.
Does it cover Spring and frameworks?
The core rehearsal focuses on Java fundamentals and reasoning, which travel across frameworks. For a Spring-heavy or specific-stack role, paste that job description into a full rehearsal to steer the questions.
How long is it?
The free taster is about five minutes. A full rehearsal runs 15 or 30 minutes and reviews every answer.
What is actually asked in a Java developer interview?
Three things recur in almost every loop: collections and their trade-offs, concurrency, and how your framework wires objects together. Algorithms appear less often than candidates expect, and exception handling and transactions appear more. The version you have actually shipped changes the questions — lambdas and streams are assumed from Java 8, records from 17, and virtual threads move the concurrency discussion somewhere else entirely. Most rounds are answered aloud rather than coded, and follow-up questions exist to separate a memorised label from an explanation.
Related interviews
How to rehearse this exact thing
Explaining a mechanism out loud instead of naming it
The rehearsal asks follow-ups the way a core-Java round does, so a memorised label runs out within two questions. The report shows where the explanation stopped.
The concurrency question
Asked as a spoken scenario rather than a definition, which is how it is asked in the room. The report tells you whether you described the failure or only the property.
Talking about maintenance work without apologising for it
Rehearsing the story out loud is where the defensive framing shows up. The report flags hedging language around the codebase you worked on.
Ready to rehearse for real?
Start a free five-minute Java Developer interview now. You’ll get a spoken interview with live follow-ups and a feedback report that quotes your own answers back.