Java Interview Questions 2026: What They Really Ask and How to Pass

Full disclosure: I have a favorite Java interview question. It's about as complicated as a paper clip. "What's the difference between == and equals()?"

Sounds easy, right? Anyone a few weeks into learning Java knows this one. The candidate answers cheerfully: "== compares references, equals() compares contents." Great. Then I show them this:

Integer small1 = 127;
Integer small2 = 127;
Integer big1 = 128;
Integer big2 = 128;

boolean sameSmall = small1 == small2; // true
boolean sameBig = big1 == big2;       // false

And the room goes very, very quiet.

It's not that the candidate is bad. It's that they memorized the answer instead of understanding how it works. Java caches Integer objects from −128 to 127, so 127 is one and the same object, while 128 gives you two different ones. Someone who gets it will explain this in ten seconds. Someone who memorized it will stare at the screen for a long, long time.

That's how a Java developer interview works in 2026. The questions are almost the same as five years ago. What changed is this: now they almost always ask "but why?" — and the second answer instantly shows whether you memorized it or actually understand it.

Walking into that interview after cramming a "top 100 Java interview questions" list is like stepping into the ring with Mike Tyson because you watched a couple of his fights on YouTube. Technically, you're in the ring. But the first follow-up question will land faster than you can say "this wasn't in the tutorial."

Let's break down what interviewers ask right now, where people stumble most, and how to prepare so that follow-up questions make you happy instead of scared.

What's Changed in Java Interviews in 2026

The short version: the core Java interview questions barely change, but in 2026 they come with modern Java (17, 21, and 25), Spring Boot 4, and a new format — live coding where you're sometimes allowed to use AI.

The three biggest changes:

• Java 25 is the current LTS. It came out in September 2025 and is the first long-term support release since Java 21. Interviewers increasingly ask not just "what's new in Java 8" but also about records, sealed classes, pattern matching, and virtual threads.
• Spring Boot 4. Released in November 2025 together with Spring Framework 7: the move to Jackson 3, JSpecify annotations for null safety, built-in API versioning. If the job posting mentions Spring, expect a question or two about the new major version.
• AI in the interview. Some companies already let candidates use AI in technical interviews, and since 2025 Canva has flat-out required it from backend, frontend, and machine learning candidates. But plenty of companies still ban it. The rule is simple: ask your recruiter in advance.

How a Java Developer Interview Works

It's usually not one conversation but several rounds:

1. Recruiter screen — motivation, experience, salary expectations. No code, but they're checking that you're a reasonable human.
2. Technical screen — 30–45 minutes of rapid-fire fundamentals, so engineers don't waste time on people who aren't there yet.
3. Technical interview — 60–90 minutes: Core Java, collections, multithreading, Spring, databases, and a whole lot of "why."
4. Live coding or take-home assignment — you solve a problem while the interviewer watches, or at home.
5. Final round — the team, the processes, how you handle conflict and deadlines. Nobody asks about HashMap here anymore. They ask what you'll do if production goes down at 6 p.m. on a Friday.

Juniors mostly get questions on fundamentals. The more senior the role, the less theory and the more talk about real experience: what you've built, what decisions you made, and where things went wrong.

Next up: Java interview questions by topic. This isn't an exhaustive list — just the most common ones, with short answers and the traps people fall into. For a detailed breakdown of hundreds of questions, check out our CodeGym series Exploring questions and answers from a job interview for a Java developer position — we'll come back to it later.

Core Java Interview Questions: The Basics You Can't Skip

What's the difference between primitives and reference types? A primitive variable holds the actual number or character, while a reference variable holds the address of an object that lives on the heap. Which brings us right back to the Integer trick question we started with.

Why is String immutable? It's as immutable as a team lead's opinion on tabs vs. spaces. Seriously, though — for security, hash code caching, and the string pool: many parts of a program can safely share the same string at the same time. If you need to glue strings together over and over in a loop, use StringBuilder, or you'll create a brand-new object on every iteration.

How are equals() and hashCode() related? One rule: objects that are equal according to equals() must return the same hashCode(). But different objects sharing the same hashCode() is perfectly fine — that's just a regular collision. Override equals() and forget hashCode(), and you've got a guaranteed way to create objects that HashMap "can't find" even though they're sitting right there.

Does Java pass objects by reference or by value? A crowd favorite that trips up even confident mid-level devs. If you want to shine, say this: "Java always passes by value — sometimes that value just happens to be a reference." Sounds like a fortune cookie, works every time. That's why a method can change the fields of an object you pass in, but can't swap out the object your outside variable points to.

What does this method return?

static String pick() {
    try {
        return "try";
    } finally {
        return "finally";
    }
}

The answer is "finally". A finally block always runs, and its return overrides the return from try. finally is like the last comment on a code review: it always gets the final word. Interviewers don't show this code because anyone should write it — they want to see whether you understand execution order. And the correct answer to "should you ever write this?" is no. Never.

Exceptions: What Breaks and Who's on the Hook

Exception questions seem boring right up until production goes down because of a swallowed catch.

• Checked vs. unchecked: what's the difference? With checked exceptions, the compiler forces you to either handle them or declare them in throws — for example, IOException when you're working with a file. Unchecked ones, the subclasses of RuntimeException, are usually bugs in the code itself, like NullPointerException or IllegalArgumentException, and the compiler doesn't make you handle them. A strong interview answer adds: checked is for situations the program can reasonably recover from, unchecked is for bugs you should fix, not catch.
• What does try-with-resources do? Anything declared in the parentheses after try that implements AutoCloseable gets closed automatically, even if an exception is thrown inside:

try (var reader = Files.newBufferedReader(Path.of("orders.csv"))) {
    return reader.readLine();
}

No more finally blocks with a manual close() and nested try inside finally — the way things worked before Java 7.

• Can you catch OutOfMemoryError? Technically, yes: it's a subclass of Throwable. But OutOfMemoryError is an Error, not an Exception — a signal of a problem the program usually can't handle gracefully. Catching it to "keep going" is like rearranging the deck chairs on the Titanic. The only sensible move is to log it and shut down cleanly.

OOP: Examples, Not Definitions

The number one mistake here is answering with textbook definitions. "Encapsulation is data hiding." Thanks — but where did that ever come in handy in your code?

• Abstract class or interface? An interface describes what an object can do, and a class can implement many interfaces. An abstract class is a shared foundation with state and partial implementation, and you can only extend one. Since Java 8, interfaces have default methods, so the line got blurrier — and interviewers love to ask about that.
• Overloading vs. overriding. Overloading means methods with the same name and different parameters, resolved at compile time. Overriding means a subclass provides a new implementation of a parent method, resolved at runtime.
• How do you make a class immutable? Fields are private final, no setters, the class is final or has a private constructor, and any mutable objects inside get copied on the way in and on the way out. Or just use a record — more on that below.

Java Collections: Expect a HashMap Question

If you get only one question on collections, it'll be about HashMap. If you get two, the second one will also be about HashMap.

How does HashMap work under the hood? Inside, there's an array of "buckets." The key's hashCode() picks the bucket, and inside a bucket the entries are stored as a list. If one bucket ends up with more than eight entries (and the array already has at least 64 buckets), the list turns into a red-black tree so lookups don't degrade. When the array is 75% full — that's the default load factor — it doubles in size and all the entries get redistributed.

Now for the trap:

Map<List<Integer>, String> map = new HashMap<>();
List<Integer> key = new ArrayList<>(List.of(1));
map.put(key, "value");

key.add(2);
String found = map.get(key); // null

We changed the key after putting it in the map. Its hashCode() changed, so HashMap looks for it in a different bucket and comes up empty. The entry is still in the map — you just can't get it back with that key anymore. Hence the golden rule: HashMap keys should be immutable.

Other common questions:

• ArrayList or LinkedList? In real code, almost always ArrayList: index access is instant, and the data sits compactly in memory. LinkedList only wins in rare scenarios with frequent insertions in the middle via an iterator. Everyone knows it from textbooks, but hardly anyone has seen it in production — kind of like Bigfoot.
• ConcurrentHashMap or Collections.synchronizedMap()? Both are thread-safe, but synchronizedMap locks the entire map, while ConcurrentHashMap lets many threads work with it in parallel.
• Where does ConcurrentModificationException come from? From modifying a collection while looping over it with for-each. To remove elements during iteration, use an iterator or removeIf().

Stream API: One Line of Code, Three Lines of Questions

Interviewers love streams, and so does real-world code. They also make it very easy to write something beautiful and wrong.

• Why does my stream "do nothing"? Operations like filter, map, and sorted are intermediate: they return a new stream and don't kick anything off on their own. Streams are lazy: work starts only at a terminal operation — collect, count, forEach. Until then, not a single element is touched. Hence the trap: write a stream with map and forget the terminal operation, and the code inside map never runs. A stream without a terminal operation is like a Monday to-do list: beautifully written, and nothing happens.
• map() or flatMap()? map is one element in, one element out. flatMap turns each element into a whole stream and then merges them all into a single flow. The classic example is "flattening" a list of lists:

List<List<String>> teams = List.of(
        List.of("Anna", "Ben"),
        List.of("Vicky"));

List<String> people = teams.stream()
        .flatMap(List::stream)
        .toList(); // [Anna, Ben, Vicky]

• Can you use a stream twice? No. After a terminal operation the stream is closed, and calling it again throws IllegalStateException. Need it again? Create a new one.
• Optional: how do people mess it up? Optional is upfront with you: the value might not be there. The easiest way to ruin it is to call get() blindly — that's the same old NullPointerException wearing glasses and a fake mustache. The second way is making Optional a class field or a method parameter: it was designed as a return type. The right tools are orElse, orElseThrow, map, and ifPresent.
• What is a functional interface? An interface with exactly one abstract method, like Runnable, Comparator, or Function. Those are the interfaces you can implement with a lambda. The @FunctionalInterface annotation isn't required, but it asks the compiler to verify there really is just one method.

Java Multithreading Interview Questions: Where Mid-Level Candidates Crash

This is where most mid-level candidates get filtered out. Because you can't memorize multithreading from a cheat sheet — you have to understand it. And be a little afraid of it: that's a healthy instinct.

• What does volatile guarantee? Visibility of changes across threads: a write to a volatile variable by one thread is immediately visible to others. But volatile doesn't give you atomicity: count++ is a read, an add, and a write, and two threads can still lose someone's update.
• What is happens-before? A rule that guarantees the results of one action are visible to another. For example, everything a thread did before releasing a monitor will be seen by the thread that acquires that monitor next.
• How does a deadlock happen? Two threads grab the same locks in a different order and wait for each other forever. Like two extremely polite people in a narrow hallway: "No, after you" — all the way until the end of the workday. The fix is a consistent lock-acquisition order, and you can track it down with a thread dump.
• Runnable or Callable? Callable can return a result and throw checked exceptions. They're usually run through an ExecutorService, not by hand via new Thread().

Multithreading is a big topic in its own right — for more, see the multithreading section in our Top 50 job interview questions and answers for Java Core, Part 2.

Modern Java: What Interviewers Ask in 2026

This is the part that didn't exist in interviews five years ago, which is exactly why it sets apart the candidate who keeps up with the language.

What is a record? A compact class for immutable data:

record Point(int x, int y) {}

One line, and you already have a constructor, the getters x() and y(), equals(), hashCode(), and toString(). All fields are final. Somewhere, Lombok is quietly packing its bags. Perfect for DTOs and for those HashMap keys — unless, of course, your record holds a mutable ArrayList: final protects the reference, not the contents of the list.

Why do we need sealed classes? They explicitly list who's allowed to extend them. Combined with pattern matching in switch, the compiler knows every possible variant and will warn you if one of them isn't handled.

What are virtual threads? Lightweight threads managed by the JVM, not the operating system. Ten thousand of them is no big deal; you can go to hundreds of thousands:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 10_000; i++) {
        executor.submit(() -> callSlowService());
    }
}

A good interview question sounds like this: when won't virtual threads help? Answer: when the task is CPU-bound rather than spent waiting. Virtual threads shine where code does a lot of waiting — network, database, external services. But they won't make a compute-heavy task any faster, just like a new office chair won't make you code faster.

Bonus for mid-level candidates: a virtual thread used to get "pinned" to its platform thread if it blocked inside synchronized, and the whole benefit went out the window. Java 24 fixed that, but it's worth knowing about the trap — Java 21 projects aren't going anywhere.

What's new in Java 25? You don't need to list every change, but a couple are worth knowing. For example, you can now write a program without declaring a class and with a simplified main method — that was made for people just starting to learn the language. And constructors can now run code before calling super(), for example to validate arguments.

JVM and Memory

• What areas make up JVM memory? The heap, where objects live; each thread's stack, with local variables and method calls; and the metaspace, where class metadata is stored.
• How does the garbage collector work? It removes objects that are no longer referenced from the "live" parts of the program. Think of it as the office cleaning crew: it only throws out what nobody claims. A mug with a "DO NOT TOUCH" sticky note stays put, even if it's been sitting there for three years. Most objects live very briefly, so the heap is split into generations: young objects get collected often and fast, old ones less often.
• Can Java have memory leaks? Yes. The garbage collector won't remove an object that something still references. The classic example is a static collection that only ever gets added to and never cleaned out. That same mug with the sticky note, just a gigabyte in size. Or that HashMap with a mutated key: the entries stay, but you can't get them back.

Spring Boot and Database Interview Questions

If the job posting lists Spring — and it almost always does (sometimes it feels like even barista postings do) — prepare for this block separately.

• IoC and DI: what are they, and why is constructor injection better? Spring creates the objects itself and hands them their dependencies. Constructor injection is better because the dependencies are visible right away, fields can be final, and the class is easy to test without Spring.
• Why doesn't @Transactional work? The classic: a method annotated with @Transactional gets called from another method in the same class. Transactions are managed by a proxy, and a call from inside the class goes right around it — like an employee who slips in through the back door and never swipes their badge. This is one of the most common mid-level questions.
• What is the N+1 problem? You load a list of 100 orders with one query, then fetch the customer for each order with a separate query. That's 101 queries instead of one or two. Meanwhile, the database is quietly crying. The fix is JOIN FETCH or an EntityGraph.
• What transaction isolation levels are there? From READ UNCOMMITTED to SERIALIZABLE. It's not enough to list them — you need to explain which anomalies each one protects against: dirty reads, non-repeatable reads, phantom reads.
• INNER JOIN or LEFT JOIN? Picture two tables: customers and orders. INNER JOIN keeps only the customers who have at least one order — everyone else just vanishes from the result. LEFT JOIN keeps all customers, and the "empty" ones get NULL in the order columns. A classic comprehension question: how do you find customers who have no orders at all? Answer: LEFT JOIN plus a condition that a column from the orders table IS NULL.
• Why do we need indexes, and why can't you just index everything? An index speeds up lookups like a book's table of contents: the database doesn't have to read the entire table. But every index slows down inserts and updates, because it has to be maintained too, and it takes up space. So indexes are created for real queries, not just in case. Indexing everything is like highlighting an entire textbook: if everything's highlighted, nothing is.

If databases are your weak spot, the CodeGym SQL course lets you practice queries hands-on until JOINs stop feeling scary.

Java Coding Interview: Live Coding and AI

Live coding is the scariest part. Solving a problem while someone watches is stressful: even a plain for loop suddenly starts looking suspicious. But here's the secret: the interviewer almost always cares more about how you think than about whether your answer came out right.

What interviewers value in live coding:

• Think out loud. A silent candidate is a black box. A candidate who reasons out loud shows their thought process, even if they get stuck.
• Clarify the requirements. "Can the input contain null?", "How big is the array?" — that's not cluelessness, that's professionalism.
• Start with a simple solution. First make it work, then make it optimal. A working brute-force solution beats a brilliant idea you didn't have time to finish.

Walkthrough: What a Live Coding Problem Looks Like

Let's take a typical live coding problem: find the first character in a string that appears exactly once. For the string "swiss", the answer is "w".

Step 1. Clarify the requirements. Before writing any code, ask a couple of questions. What should you return if there's no such character? Are uppercase and lowercase letters different? Can the string be empty? The interviewer will answer — and see that you think about edge cases.

Step 2. Simple solution. For each character, scan the whole string and count how many times it appears. It works, but it's O(n²): on a string of a million characters, it'll take a very long time. Say that out loud — the interviewer wants to see you understand the cost of your solution.

Step 3. Optimize. Two passes are enough: first count all the characters, then find the first one with a count of one. To keep the characters in order, LinkedHashMap does the job. And since the character might not exist, we return Optional, just like we agreed in the streams section:

static Optional<Character> firstUnique(String text) {
    Map<Character, Integer> counts = new LinkedHashMap<>();
    for (char c : text.toCharArray()) {
        counts.merge(c, 1, Integer::sum);
    }
    for (Map.Entry<Character, Integer> entry : counts.entrySet()) {
        if (entry.getValue() == 1) {
            return Optional.of(entry.getKey());
        }
    }
    return Optional.empty();
}

Now it's O(n): each character is processed a constant number of times.

Step 4. Test yourself. Run a couple of examples in your head: "swiss" returns "w", "aabb" returns an empty Optional, an empty string also returns an empty Optional. If the interviewer asks why LinkedHashMap and not HashMap, you already have the answer: a regular HashMap doesn't remember insertion order, so the "first" character could turn out to be anything.

Now a bonus that'll pleasantly surprise your interviewer: you can get away with a regular HashMap if your second pass goes over the string itself instead of the map. The string then sets the order, and the map just stores the counts. Two working options and a clear choice between them — that's exactly what interviewers want to see in live coding.

That's the whole secret of live coding. Not a brilliant solution on the first try, but a clear path: clarify the requirements, solve it simply, estimate complexity, improve it, test it.

So can you use AI? It depends on the company, and sometimes on the interview round. If it's allowed, the interviewer usually isn't looking at what the AI generated but at how you use it: what you ask for, how you check the result, whether you catch mistakes. At Canva, for example, they say it outright: what matters isn't what AI wrote for the candidate, but the ability to read the generated code, understand it, and improve it — and explain every technical decision. If you can't explain what the code does, AI didn't help you; it threw you under the bus. It's like walking into an exam with a cheat sheet written in a language you don't speak.

Honestly, this is the strongest argument for solid fundamentals I know. An AI will write you a HashMap with a mutable key in a second. Only you can notice that it shouldn't.

Cheat Sheet: What Java Interview Questions Really Test

Every interview question has a hidden layer. Here's what's behind the most common ones:

How to Prepare for a Java Interview in Three Weeks

Week 1 — fundamentals. Core Java, OOP, exceptions, collections, and the Stream API. Don't just read answers — write code. Put a mutable key into a HashMap and see what happens. Break equals() and hashCode() and find where it blows up.

Week 2 — multithreading and modern Java. Write a program with a deadlock and find it with a thread dump. Rewrite a couple of classes as records. Spin up ten thousand virtual threads and watch how it works.

Week 3 — Spring, databases, and practice. Build a small Spring Boot app with a database, catch an N+1 problem in your own code, and fix it. And definitely do a couple of mock interviews — with a friend, a mentor, or at least out loud in front of a mirror.

And the main rule: don't memorize answers. Every question in this article can be checked with code in five minutes. What you've verified with your own hands sticks forever; what you've memorized lasts until the first "but why?"

And then the room will go quiet again. Only this time, it's because the interviewer has nothing left to add.

Where to Practice

In the CodeGym Java course, almost every topic from this article — from collections and exceptions to multithreading — is drilled through tasks with instant verification. A mistake in equals() and hashCode() shows up right away, not in the interview.

And if you'd rather go all the way to your first offer with a mentor, code reviews, and portfolio projects, there's Java University: it also has a career center that helps with your resume and interview prep.

Want even more questions with detailed answers? Open our CodeGym series Exploring questions and answers from a job interview for a Java developer position and the Top 150 most frequently asked job interview questions for Java devs. That's plenty for a lot of evenings.

FAQ

What Java interview questions are asked in 2026? The foundation stays the same: Core Java, OOP, exceptions, collections, the Stream API, multithreading, the JVM, Spring, and databases. In 2026, they're joined by questions on modern Java — records, sealed classes, pattern matching, virtual threads, and the changes in Java 25 — plus Spring Boot 4.

What do they ask in a junior Java developer interview? Mostly fundamentals: the difference between == and equals(), how equals() and hashCode() are related, why String is immutable, how HashMap works, ArrayList vs. LinkedList, checked vs. unchecked exceptions, try-with-resources, and map() vs. flatMap() in the Stream API. It's not enough to know the answer — you need to explain why it works that way.

What Java interview questions do mid-level developers get? Multithreading (volatile, happens-before, deadlock, ExecutorService), how the JVM and garbage collector work, Spring (DI, @Transactional and its traps), Hibernate (the N+1 problem, lazy loading), and transaction isolation levels. Plus lots of questions about real-world experience.

Can you use AI in a Java interview? It depends on the company and even on the interview round. Some companies allow or require AI in technical interviews; many still ban it. Check with your recruiter in advance. If AI is allowed, they'll test whether you can explain and verify the generated code.

Which Java version matters for interviews right now? The current LTS version is Java 25, released in September 2025. That said, many companies still run Java 17 and 21, so it pays to know what each of those versions introduced.

What problems come up in a Java coding interview? Usually small algorithmic problems on strings, arrays, and collections: find the first non-repeating character, find duplicates in an array, check for a palindrome, group data with a HashMap. The interviewer looks not only at the result but at how you clarify the requirements, estimate complexity, and check edge cases.

How can I prepare for a Java interview fast? Three weeks is enough to give your fundamentals a solid refresh: week one — Core Java and collections, week two — multithreading and modern Java, week three — Spring, databases, and mock interviews. The key is to check every answer with code instead of memorizing it.