Java Developer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about a time you had to fix a production bug under pressure.

   What they're really asking: Can you stay methodical and communicate clearly when something is on fire.

   Answer outline (STAR)

   • SituationA checkout service threw intermittent null pointer exceptions during a sale.
   • TaskFind the cause and ship a safe fix fast.
   • ActionReproduced it locally from the logs, added a null check and a regression test, then deployed behind a feature flag.
   • ResultThe outage ended in forty minutes, and a null-safety check was added to the review checklist.

   Full sample answer (fictional example)

   During a big sale, our checkout service started throwing intermittent null pointer exceptions, and orders were failing for some customers. I pulled the stack traces from our logging tool and found a null shipping address field that only appeared for guest checkouts. I reproduced it locally in about fifteen minutes, added a null check with a sensible default, and wrote a regression test for the guest checkout path. I deployed the fix behind a feature flag so I could roll it back instantly. The outage lasted about forty minutes, and afterward I suggested adding null-safety checks to our pull request template.

2. 2.Tell me about a time you disagreed with a teammate's code review feedback.

   What they're really asking: Do you handle technical disagreement professionally instead of digging in.

   Answer outline (STAR)

   • SituationA reviewer wanted an interface added where I thought a concrete class was enough.
   • TaskReach a decision without stalling the pull request.
   • ActionAsked for the concrete risk they were guarding against, then tested it against two likely future changes.
   • ResultWe agreed the interface wasn't needed yet, and documented why in the pull request for future readers.

3. 3.Describe a time you had to learn a new framework or library quickly for a project.

   What they're really asking: Can you become productive in unfamiliar tooling without slowing the team down.

   Answer outline (STAR)

   • SituationA migration from Spring MVC to Spring WebFlux with a two-week deadline.
   • TaskShip the first reactive endpoint as a working example for the rest of the team.
   • ActionRead the reference docs, rebuilt one existing endpoint reactively, and paired with a teammate who knew it.
   • ResultThe endpoint shipped on time, and I wrote a short internal guide others used for the rest of the migration.

   Full sample answer (fictional example)

   My team was migrating part of our API from Spring MVC to Spring WebFlux, and I was asked to build the first reactive endpoint as a reference, with two weeks before the sprint review. I read through the official reactive programming guide and rebuilt one of our simpler existing endpoints reactively as practice, which surfaced most of the gotchas around blocking calls hiding inside reactive chains. I delivered the real endpoint on schedule and wrote a short internal guide that the rest of the team used for the remaining migration work.

4. 4.Tell me about a time you had to refactor legacy Java code.

   What they're really asking: Do you improve code safely instead of rewriting it out of frustration.

   Answer outline (STAR)

   • SituationA ten-year-old order-processing class with no tests and three responsibilities tangled together.
   • TaskMake it safer to change without breaking existing behavior.
   • ActionAdded characterization tests around current behavior first, then split the class into three smaller ones step by step.
   • ResultTest coverage went from near zero to solid, and the next three feature requests touched it without incident.

   Full sample answer (fictional example)

   I inherited a ten-year-old order-processing class that handled validation, pricing and persistence all in one place, with no tests covering it. Rather than rewrite it, which felt risky, I first wrote characterization tests that captured its existing behavior, including a few unexplained quirks. Once those tests passed consistently, I split the class into three smaller ones, one responsibility each, running the full test suite after every small step. The refactor took about a week longer than a quick rewrite would have, but test coverage went from almost nothing to solid, and the next three feature requests touched that code without a regression.

5. 5.Tell me about a time you pushed back on a deadline or scope.

   What they're really asking: Will you flag risk honestly instead of agreeing to something you can't deliver well.

   Answer outline (STAR)

   • SituationA manager wanted a payment integration finished in one week.
   • TaskProtect quality on code that touches money.
   • ActionBroke the work into a minimal first version plus follow-ups, and showed the risk of skipping error handling.
   • ResultWe shipped the minimal version on time, then added retries and reconciliation the following week as agreed.

6. 6.Tell me about a time you wrote code that turned out to be wrong in production.

   What they're really asking: Do you own mistakes and fix the process, not just the bug.

   Answer outline (STAR)

   • SituationA rounding error in an invoice calculation that shipped past review.
   • TaskCorrect affected invoices and stop it recurring.
   • ActionIdentified every affected record, issued corrected invoices, and added a unit test covering the rounding edge case.
   • ResultCustomers were notified proactively, and a similar bug was caught by the new test before the next release.

   Full sample answer (fictional example)

   I shipped an invoice calculation that rounded line items individually instead of rounding the total, which caused invoices to be off by a cent in about three percent of cases. I pulled a report of the roughly 240 affected invoices from the past month, confirmed the pattern, and issued corrected invoices with a short explanation to each customer. I then added a unit test that covered the rounding edge case, along with a few similar ones I found while I was in there. A near-identical bug in a related feature was caught by that same test before it ever reached production.

7. 7.Describe a time you mentored a junior developer.

   What they're really asking: Checks whether you can grow others, not just write your own code.

   Answer outline (STAR)

   • SituationA new hire struggling to understand the team's layered architecture.
   • TaskGet them contributing confidently within their first month.
   • ActionPaired on their first three tickets, walked through the codebase's layers with diagrams, and reviewed their code with explanations, not just corrections.
   • ResultThey shipped their first feature solo in week three, and later mentored the next new hire the same way.

   Full sample answer (fictional example)

   A new hire was struggling to see how our layered architecture fit together, which slowed their first tickets. I offered to pair on their next three tickets rather than just reviewing the pull requests afterward, and sketched the layers on a whiteboard using the request flow of a real feature. When reviewing their code after that, I made a point of explaining why something needed to change, not just flagging that it did. By their third week they shipped a small feature on their own, and months later I saw them giving the same whiteboard walkthrough to the next new hire.

8. 8.Tell me about a time estimates for a project were badly wrong.

   What they're really asking: Can you learn from poor estimates instead of just absorbing the overrun quietly.

   Answer outline (STAR)

   • SituationA data migration estimated at three days that took three weeks.
   • TaskFinish it and explain the overrun honestly.
   • ActionFound that the data had far more edge cases than the sample suggested, and renegotiated scope with the stakeholder weekly.
   • ResultThe migration finished with no data loss, and I started estimating from a larger sample on future projects.

9. 9.Tell me about a time you had to work closely with a non-technical stakeholder.

   What they're really asking: Can you translate technical constraints into terms a non-engineer can use to decide.

   Answer outline (STAR)

   • SituationA product manager wanted a feature that conflicted with the database design.
   • TaskFind a version both the data model and the deadline could support.
   • ActionExplained the trade-off in terms of cost and risk rather than schema details, and proposed two alternatives.
   • ResultWe shipped a simplified version on time, with the fuller version planned for the following quarter.

10. 10.Describe a time you had to choose between two valid technical approaches.

    What they're really asking: Checks your decision-making process when there's no obviously correct answer.

    Answer outline (STAR)

    • SituationA choice between a relational and a document store for a new service's data.
    • TaskPick an approach the team could commit to without endless debate.
    • ActionListed the access patterns we actually needed, then weighed each option against those rather than general opinions.
    • ResultWe chose relational for consistency needs, and revisited the decision successfully a year later when needs changed.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.What's the difference between ArrayList and LinkedList, and when would you use each?

   What they're really asking: Tests whether you understand the cost of common data structure operations.

   Answer outline

   • ArrayList backs onto a resizable array, so random access is fast but inserting in the middle shifts elements.
   • LinkedList is a doubly linked list, so inserting or removing at either end is fast but indexed access is slow.

   Full sample answer (fictional example)

   ArrayList is backed by a resizable array, so getting an element by index is constant time, but inserting or removing in the middle means shifting every element after it. LinkedList is a doubly linked list, so inserting or removing at either end is fast, but getting the nth element means walking the list, which is slow for large lists. In practice I default to ArrayList, and I'd reach for LinkedList only with a genuine queue or deque use case and little random access.

2. 12.Explain the difference between == and .equals() for objects in Java.

   What they're really asking: A basic but surprisingly common source of bugs, especially with wrapper types.

   Answer outline

   • == compares references for objects, checking whether both variables point to the same memory location.
   • .equals() compares logical equality, and classes should override it along with hashCode() consistently.

3. 13.How does HashMap work internally, and what happens on a hash collision?

   What they're really asking: Checks whether you understand a data structure used constantly, not just its API.

   Answer outline

   • Keys are hashed to find a bucket index, and each bucket holds entries as a linked list or, since Java 8, a tree once it grows large.
   • Collisions mean two keys land in the same bucket, so the map compares them with equals() to find the right entry.

   Full sample answer (fictional example)

   A HashMap computes a hash code for each key and uses it to pick a bucket index in an internal array. Each bucket can hold several entries, stored as a linked list or, since Java 8, as a balanced tree once it grows large. When two keys land in the same bucket, that's a collision, and the map calls equals() on each entry there to find the right one. If a class has a poor hashCode() that returns the same value too often, lookups degrade from roughly constant time toward linear time, which I've seen cause real slowdowns.

4. 14.What's the difference between checked and unchecked exceptions, and when should each be used?

   What they're really asking: Tests your judgment on error handling design, not just the syntax.

   Answer outline

   • Checked exceptions must be declared or caught, and suit recoverable conditions the caller can reasonably act on.
   • Unchecked exceptions extend RuntimeException and suit programming errors or conditions the caller can't realistically recover from.

   Full sample answer (fictional example)

   Checked exceptions must be either caught or declared in a method's throws clause, and they're meant for conditions a caller can reasonably recover from, like a file not being found. Unchecked exceptions extend RuntimeException and don't require that handling, and they usually represent programming errors or conditions where recovery isn't realistic, like a null reference or invalid argument. I've seen teams that overuse checked exceptions end up with callers swallowing them just to make the code compile, which is worse than having none.

5. 15.Explain the Java memory model briefly: stack versus heap, and what the garbage collector does.

   What they're really asking: Checks whether you can reason about memory without treating the JVM as a black box.

   Answer outline

   • The stack holds method call frames and local variables, and is cleaned up automatically as methods return.
   • The heap holds objects, and the garbage collector reclaims memory for objects no longer reachable from any live reference.

6. 16.How would you handle concurrent access to a shared counter in Java?

   What they're really asking: Checks whether you reach for the simplest correct tool instead of hand-rolled locking.

   Answer outline

   • AtomicInteger or AtomicLong gives lock-free, thread-safe increments for a simple counter.
   • A synchronized block or method works too, but adds contention under high concurrency.

7. 17.What does the @Transactional annotation do in Spring, and what's a common mistake with it?

   What they're really asking: Checks hands-on Spring experience, not just the theory of annotations.

   Answer outline

   • It wraps a method in a database transaction, committing on success and rolling back on an unchecked exception.
   • By default it only rolls back on unchecked exceptions, so a checked exception can commit a partial change silently.

8. 18.What's the difference between an abstract class and an interface in Java?

   What they're really asking: Checks whether you understand when each is the right tool for shared behavior.

   Answer outline

   • An abstract class can hold state and partial implementation, and a class can extend only one.
   • An interface defines a contract, and since Java 8 can include default methods, with a class able to implement many.

9. 19.Explain the difference between synchronized, volatile and java.util.concurrent.locks.Lock.

   What they're really asking: Checks depth on concurrency tools beyond the basics most candidates recite.

   Answer outline

   • synchronized provides mutual exclusion and visibility together, at the cost of blocking.
   • volatile ensures visibility of a variable's latest value across threads but not atomicity of compound operations.

10. 20.What's the difference between a thread pool's core size and maximum size in Java's ExecutorService?

    What they're really asking: Tests practical experience tuning thread pools, not just creating them with defaults.

    Answer outline

    • Core size is the number of threads kept alive even when idle, ready for incoming work.
    • Maximum size is the ceiling the pool can grow to when the work queue fills up.

11. 21.How would you design a REST endpoint that needs to handle a large file upload efficiently?

    What they're really asking: Checks whether you think about streaming and memory, not just the happy path.

    Answer outline

    • Stream the request body instead of loading the whole file into memory.
    • Validate size and content type early, and reject oversized requests before processing begins.

12. 22.What's the N+1 query problem, and how do you fix it in a Spring Data JPA application?

    What they're really asking: A very common real-world performance bug in ORM-backed applications.

    Answer outline

    • It happens when fetching a list triggers one query per related entity instead of one combined query.
    • Fix it with a JOIN FETCH in the query or by configuring an appropriate fetch strategy.

Take-home or live exercise: tips

Java interviews often include a live coding round on a shared editor or whiteboard, or a take-home exercise building a small service.

• Clarify input constraints and edge cases out loud before writing any code.
• Write a brute-force solution first if you're stuck, then improve it rather than staying silent.
• Write at least a few unit tests even under time pressure; interviewers notice their absence.

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.A unit test passes locally but fails intermittently in the CI pipeline. What do you do?

   What they're really asking: Checks whether you investigate flaky tests instead of just rerunning them.

   Answer outline

   • Look for shared mutable state, timing assumptions or reliance on test execution order.
   • Run the suspect test in isolation and in parallel locally to reproduce the flakiness deliberately.

   Full sample answer (fictional example)

   My first instinct is to look for shared mutable state between tests, or an assumption about test execution order, since those are the most common causes of flakiness I've run into. I'd run the test in isolation many times, then alongside the suite in parallel, to reproduce the failure deliberately rather than guessing. I then look for timing assumptions, like a test that expects an async operation to finish within a fixed sleep. I fix the actual cause rather than adding a longer sleep or a retry wrapper, and leave a comment on what made the test flaky.

2. 24.You notice a security vulnerability in a library your team depends on. What do you do?

   What they're really asking: Checks whether you treat dependency risk as part of the job, not someone else's problem.

   Answer outline

   • Check the severity and whether the vulnerable code path is actually reachable in your application.
   • Raise it with the team and check for a patched version or a reasonable workaround.

3. 25.A code review on your pull request comes back with ten comments, several of them stylistic. How do you respond?

   What they're really asking: Checks whether you can separate substance from preference without getting defensive.

   Answer outline

   • Address the correctness and design comments first, since those matter most.
   • Push back politely on pure style preferences if the codebase has no established convention either way.

   Full sample answer (fictional example)

   I sort through them mentally before responding to any of them: correctness issues first, then design concerns, then pure style preferences last. For style comments, if the codebase has an established convention one way or the other, I just follow it without much discussion. If there's genuinely no convention and it's a matter of taste, I'll say so politely and either defer to the reviewer or explain my reasoning briefly, without turning it into a long thread. I also thank the reviewer for a thorough pass, since ten comments usually mean they read the code carefully.

4. 26.You're asked to add a feature to a service with no tests and tight coupling. What's your approach?

   What they're really asking: Checks whether you can move a codebase forward safely rather than avoiding it or rewriting it outright.

   Answer outline

   • Add characterization tests around the current behavior before changing anything.
   • Make the smallest change that delivers the feature, isolating new logic where you can test it cleanly.

5. 27.A teammate wants to introduce a new framework for a problem your current stack already solves. How do you respond?

   What they're really asking: Checks whether you evaluate new tools on merit instead of excitement or habit.

   Answer outline

   • Ask what specific problem the current stack can't solve well enough.
   • Weigh the learning curve and maintenance cost against the benefit for the whole team, not just this feature.

6. 28.You inherit a service where the previous developer left no documentation and has left the company. What's your first week like?

   What they're really asking: Checks how you build understanding of unfamiliar systems methodically.

   Answer outline

   • Read the code's entry points first, then trace the main request flows end to end.
   • Check logs and monitoring dashboards to see what actually happens in production, not just what the code suggests.

7. 29.A deploy to production fails halfway through and leaves the service in an inconsistent state. What do you do?

   What they're really asking: Checks composure and process under a real incident, not just technical knowledge.

   Answer outline

   • Roll back to the last known good version first, before investigating the cause.
   • Confirm the rollback actually restored consistent behavior, not just the previous code version.

8. 30.Your team is split on whether to fix a bug now or ship the planned feature first. How do you help resolve it?

   What they're really asking: Checks whether you can frame trade-offs for a team decision instead of just picking a side.

   Answer outline

   • Clarify the bug's actual impact: how many users, how severe, how often.
   • Lay out the cost of delaying each option in terms stakeholders can weigh.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Reciting definitions without being able to apply them to a real scenario.

   Practice explaining concepts using an example from your own project work.

2. Jumping straight to code without clarifying requirements or edge cases.

   Ask two or three clarifying questions before writing anything.

3. Blaming the JVM or the framework instead of debugging the actual cause.

   Describe the specific steps you took to isolate a real bug you fixed.

4. Treating every design question as needing microservices or heavy abstraction.

   Default to the simplest design that meets the stated requirements, and justify complexity when you add it.

How to prepare for a Java developer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Collections and generics drill

   Review ArrayList, HashMap, TreeMap and generics, and write short code snippets from memory for each.

2. 2

   Day 2: Concurrency refresh

   Walk through synchronized, volatile, Atomic classes and ExecutorService, and explain each one out loud.

3. 3

   Day 3: Spring deep dive

   Rebuild a small REST endpoint with Spring Boot, including validation, error handling and a repository layer.

4. 4

   Day 4: Practice coding live

   Solve two or three timed coding problems in Java on a platform that mimics an interview whiteboard.

5. 5

   Day 5: System design warm-up

   Sketch the design for a URL shortener or rate limiter on paper, focusing on data model and trade-offs.

6. 6

   Day 6: Project deep-dive prep

   Prepare a five-minute walkthrough of one project: the architecture, a hard decision, and what you'd change now.

7. 7

   Day 7: JVM internals review

   Read through garbage collection basics and the memory model, then rest before the interview.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. What does the Java version and framework stack look like, and are there plans to upgrade either?
2. How is testing structured here: unit, integration, and how much runs in CI before merge?
3. What does the code review process look like, and how long does a typical pull request take to merge?
4. How is technical debt prioritized against new feature work?
5. What's the on-call setup, and how often does someone get paged outside working hours?

Preparation tips

• Review core collections, generics and the memory model the night before; these come up in almost every Java interview.
• Practice explaining a concurrency topic like synchronized versus Atomic classes out loud, not just reciting definitions.
• Have one project ready to discuss in depth: the design decisions, trade-offs and what you'd change now.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.