Java Interview Questions for 2 Years Experience

Why interviewers ask experience-based questions at 2 years

Two years is the point where companies stop treating you as a trainee. The interviewer's real question is not "do you know Java?" — it is "did you actually work with Java for two years, or did you watch someone else work with it?"

That is why the questions at this level look deceptively basic. Anyone can define final. Very few candidates can explain why their team marked a DTO's fields final, or what broke when someone compared Integer objects with ==. The depth of your answer is the filter.

Expect three themes: core language internals (Strings, equals/hashCode, static/final), collections you used daily (ArrayList, HashMap), and Java 8 features (lambdas, streams, Optional) — because almost every codebase you touched in the last two years uses them.

How to answer in an interview

Use a three-layer structure for every answer:

1. 30-second direct answer — the definition plus the single most important distinction.
2. One concrete example — ideally from your project ("we used X because...").
3. One trade-off or pitfall — this is what separates you from a fresher.

Never recite. If you can tie an answer to a bug you fixed or a code review comment you received, you instantly sound like someone with real experience. Practice saying answers out loud — a 2-year interview is a speaking test as much as a knowledge test.

Q1. What is the difference between == and equals(), and what is the hashCode contract?

== compares references (do two variables point to the same object), while equals() compares logical content — if you override it. The contract says: if two objects are equal by equals(), they must return the same hashCode(). The reverse is not required.

For reference types, == is almost never what you want. String, Integer and most value-like classes override equals() to compare state. If you write your own class and use it as a HashMap key or store it in a HashSet without overriding both methods, lookups silently fail because the object lands in one bucket when stored and is searched in another.

record Employee(String id, String name) {} // records generate equals/hashCode

Employee a = new Employee("E101", "Ravi");
Employee b = new Employee("E101", "Ravi");
System.out.println(a == b);        // false - different objects
System.out.println(a.equals(b));   // true  - same content

Notice that a record gives you a correct equals()/hashCode() pair for free — mention this and you signal you know modern Java.

Interview note: The follow-up trap is "can two unequal objects have the same hashCode?" Yes — that is a hash collision and it is legal. Saying "no" fails the question.

Q2. Why is String immutable, and when do you use StringBuilder vs StringBuffer?

String is immutable so it can be safely shared, cached in the String pool, and used as a HashMap key without its hash changing. StringBuilder is the mutable alternative for building strings in a single thread; StringBuffer is its synchronized (thread-safe but slower) older sibling.

Immutability enables the String pool: two literals with the same value share one object, saving memory. It also makes String inherently thread-safe. The cost is that every concatenation creates a new object — which is why concatenating inside a loop is a classic performance mistake.

StringBuilder sb = new StringBuilder();
for (String part : parts) {
    sb.append(part).append(",");
}
String csv = sb.toString();

In practice you will almost never choose StringBuffer today; if you need thread-safe string assembly, you usually restructure the code instead. Read more on how the String pool works.

Interview note: Expect "what does new String("abc") create?" Answer: up to two objects — one in the pool (if "abc" isn't already there) and one on the heap.

Q3. Explain the uses of the final keyword.

final on a variable means it can be assigned once; on a method it blocks overriding; on a class it blocks inheritance entirely.

A final reference variable cannot be repointed, but the object it refers to can still change — final List<String> names can still have elements added. This distinction trips up many candidates. final fields are also the backbone of immutable classes, and the compiler requires local variables used inside lambdas to be final or effectively final.

Real-world use: marking injected dependencies final in constructor injection, marking utility classes final with a private constructor, and making value objects immutable.

Interview note: "Is a final object immutable?" No — final protects the reference, not the object's state. Interviewers use this to catch memorized answers.

Q4. What does static mean, and when should you avoid it?

static members belong to the class, not to any instance — one copy shared by all objects. Use it for constants, pure utility methods and factory methods; avoid it for anything holding mutable state.

Static methods cannot access instance members directly and cannot be overridden (they are hidden instead). Static mutable state is dangerous because every thread and every part of the application shares it — a common source of test pollution and race conditions.

A clean use: public static final int MAX_RETRIES = 3; or LocalDate.now(). A smell: a static Map used as an application-wide cache without any eviction or synchronization.

Interview note: Follow-up: "when is a static block executed?" When the class is loaded — once per class loader, before any instance exists.

Q5. Interface vs abstract class after Java 8 — when do you choose which?

An abstract class can hold state (instance fields) and constructors; an interface cannot. Since Java 8, interfaces can have default and static methods, so the real deciding factor is state and the single-inheritance limit: a class extends one abstract class but implements many interfaces.

Choose an abstract class when subclasses share fields or a partial implementation with protected helpers — think template base classes. Choose an interface when you are defining a capability (Comparable, Runnable) that unrelated classes should implement.

public interface Notifier {
    void send(String message);
    default void sendUrgent(String message) {
        send("[URGENT] " + message);   // default method reuses the contract
    }
}

Default methods exist mainly so libraries can evolve interfaces without breaking implementers — that is the "why" interviewers want to hear.

Interview note: Trap: "can an interface have a constructor?" No — interfaces cannot hold instance state, so there is nothing to construct.

Q6. What is the difference between checked and unchecked exceptions?

Checked exceptions (extending Exception but not RuntimeException) must be declared or handled at compile time — they represent recoverable, expected failures like IOException. Unchecked exceptions (extending RuntimeException) represent programming errors like NullPointerException and need no declaration.

The practical guidance: use checked exceptions when the caller can realistically recover (retry a connection, ask for another file), and unchecked for bugs the caller should not be forced to catch. Most modern frameworks, including Spring, lean heavily on unchecked exceptions to avoid polluting every method signature with throws.

See the full breakdown in checked vs unchecked exceptions.

Interview note: Follow-up: "is Error checked or unchecked?" Neither in spirit — Error (like OutOfMemoryError) is unchecked and should never be caught in normal code.

Q7. How does try-with-resources work?

Try-with-resources automatically closes any resource implementing AutoCloseable when the block exits — normally or via exception — in reverse order of declaration. It replaced the error-prone finally-based cleanup.

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
} // reader.close() called automatically, even on exception

The subtle part interviewers probe: if both the try block and close() throw, the try block's exception wins and the close exception is attached as a suppressed exception — retrievable via getSuppressed(). In the old finally pattern, the cleanup exception would swallow the original one.

Interview note: Expect "can you use a resource declared before the try?" Yes, since Java 9, if the variable is final or effectively final.

Q8. What is autoboxing, and what bugs can it cause?

Autoboxing automatically converts primitives to wrapper objects (int → Integer) and back. Its two classic bugs: NullPointerException when unboxing a null wrapper, and wrong results when comparing wrappers with ==.

Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println(a == b); // true  - cached range (-128 to 127)
System.out.println(c == d); // false - different objects!

The Integer cache makes == work "sometimes", which is worse than never — the bug hides until values exceed 127. Always compare wrappers with equals(). Also watch for unboxing in arithmetic: Integer total = null; int x = total + 1; throws an NPE at runtime.

Interview note: Follow-up: "why did your loop get slow after changing int to Integer?" Boxing allocates objects; hot loops over wrappers create garbage and pressure the GC.

Q9. ArrayList vs LinkedList — which do you use and why?

ArrayList is backed by a resizable array: O(1) random access, fast iteration, amortized O(1) appends. LinkedList is a doubly-linked list: O(1) insert/remove at the ends but O(n) to reach a position. In practice, ArrayList wins almost every real workload.

The textbook claim that LinkedList is "better for insertions" is misleading: to insert in the middle you must first traverse to the position (O(n)), and its nodes scatter across memory, killing CPU cache performance. ArrayList's contiguous memory makes iteration several times faster in practice.

Say this in the interview: "I default to ArrayList; I would only reach for LinkedList as a Deque, and even then ArrayDeque is usually better." That one sentence shows engineering judgment.

Interview note: Trap: "what is the time complexity of get(i) on LinkedList?" O(n) — it walks from the nearer end. Candidates who say O(1) reveal they never checked.

Q10. How do you make a class immutable?

Declare the class final, make all fields private final, provide no setters, initialize everything in the constructor, and defensively copy any mutable fields both on the way in and the way out.

public final class Booking {
    private final String id;
    private final List<String> seats;

    public Booking(String id, List<String> seats) {
        this.id = id;
        this.seats = List.copyOf(seats);   // defensive copy in
    }
    public List<String> getSeats() {
        return seats;                       // List.copyOf is already unmodifiable
    }
}

The step most candidates forget is the defensive copy — without it, the caller keeps a reference to the mutable list and can change your "immutable" object from outside. Immutable objects are automatically thread-safe and make excellent map keys.

Interview note: Follow-up: "why is immutability useful in multithreading?" No writes means no race conditions — immutable objects can be shared freely without locks.

Q11. What are lambda expressions and functional interfaces?

A lambda is an inline implementation of a functional interface — an interface with exactly one abstract method. Instead of an anonymous class, you write just the behavior: (a, b) -> a + b.

The built-in functional interfaces cover most needs: Predicate<T> (test), Function<T,R> (transform), Consumer<T> (accept), Supplier<T> (produce). @FunctionalInterface is optional but makes the intent compile-checked.

List<String> names = List.of("Anita", "Ravi", "Kiran");
names.stream()
     .filter(n -> n.length() > 4)     // Predicate<String>
     .map(String::toUpperCase)        // method reference = Function
     .forEach(System.out::println);

Point out the method references — using String::toUpperCase instead of n -> n.toUpperCase() signals fluency.

Interview note: Trap: "can a functional interface have default methods?" Yes — only the abstract method count must be exactly one.

Q12. Walk me through a stream pipeline: filter, map, collect.

A stream pipeline has a source (collection), zero or more intermediate operations (filter, map, sorted — lazy, return a stream) and one terminal operation (collect, forEach, count — triggers execution).

Nothing runs until the terminal operation is called; intermediate operations just build a recipe. Each element flows through the whole pipeline one at a time, not stage by stage over the whole collection.

List<Double> discounted = orders.stream()
    .filter(o -> o.getAmount() > 1000)
    .map(o -> o.getAmount() * 0.9)
    .collect(Collectors.toList());

At 2 years you should also comfortably use Collectors.toMap, counting and simple groupingBy — mention that you have used them for report-style transformations at work.

Interview note: Follow-up: "does a stream modify the source list?" No — streams are non-mutating; filter produces a new sequence and the original collection is untouched.

Q13. What is Optional, and what is the wrong way to use it?

Optional<T> is a container that either holds a value or is empty, forcing callers to consciously handle the "no result" case instead of hitting a surprise NullPointerException. It is designed for method return types — not for fields or parameters.

The right way is functional: optional.map(...), orElse(...), orElseThrow(...). The wrong way — and interviewers watch for it — is if (opt.isPresent()) { opt.get(); }, which is just a null check in a costume, or calling .get() bare, which throws if empty.

String city = findUser(id)
    .map(User::getAddress)
    .map(Address::getCity)
    .orElse("Hyderabad");

This chain replaces three nested null checks. Also note orElse(expensiveCall()) always evaluates its argument — use orElseGet(() -> expensiveCall()) for lazy evaluation.

Interview note: Trap: "why shouldn't entity fields be Optional?" It is not serializable, adds wrapper overhead, and JPA providers do not support it as a field type.

How to prepare

Spend your prep time in this ratio: 50% core Java (Q1–Q10 territory), 30% Java 8 features, 20% your own project. Re-read your project's code the night before — you will be asked to draw its flow and justify at least one design choice.

Write every code example in this article yourself in an IDE, then break it: remove the hashCode() override and watch HashSet misbehave; compare Integer values above 127 with ==. Bugs you have personally seen are answers you cannot forget.

Then rehearse out loud. A structured mock interview run against the collections and OOP question sets will expose the gap between what you know and what you can articulate — and at 2 years, articulation is what gets you the offer. If you want the full syllabus behind these questions, the Java Full Stack course covers each topic with the same interview-first framing.