Java Generics Interview Questions and Answers

Why generics questions reveal your depth

Generics look like a syntax topic and are actually a mental-model topic. Almost every generics question — why you cannot create new T[], why List<String> is not a List<Object>, when to write ? extends — traces back to one idea: type erasure. Interviewers ask about generics because the candidates who understand erasure can explain the restrictions instead of memorizing them, and that reasoning transfers directly to writing safe APIs.

This page covers the generics questions asked most, built up from erasure. Because generics underpin lambdas and functional types, pair it with the lambda expressions questions and functional interfaces set.

Q1. Why were generics added, and what do they give you?

Generics provide compile-time type safety and eliminate casts. Before generics, a List held Object, so you cast on every read and could accidentally store the wrong type, failing at runtime. With List<String>, the compiler enforces the element type and inserts no-cast reads — errors move from runtime to compile time.

The one-sentence value is "move type errors from runtime to compile time." A good follow-up answer notes that generics also make APIs self-documenting: Map<UserId, Order> states intent that Map alone hides. This framing shows you value generics for correctness, not decoration.

Q2. What is type erasure?

The compiler uses generic type information to check your code, then erases it — replacing each type parameter with its bound (or Object if unbounded) and inserting casts where needed. So List<String> and List<Integer> compile down to the same raw List; no type-argument information survives to runtime.

List<String> strings = new ArrayList<>();
List<Integer> ints = new ArrayList<>();
System.out.println(strings.getClass() == ints.getClass()); // true — both just ArrayList

Erasure is the single fact that explains the rest of the topic. Its consequence chain: no instanceof List<String>, no new T[], no two overloads differing only by type argument, and no runtime access to the type parameter. Being able to derive those restrictions from erasure is exactly what interviewers reward.

Q3. What are bounded type parameters?

A bound restricts a type parameter to a type or its subtypes using extends: <T extends Number> means T can be Number or any subclass, which lets you call Number's methods on T. You can specify multiple bounds with &, and the first bound may be a class while the rest are interfaces.

// Bound lets us call doubleValue(); without it, T would only offer Object's methods
static <T extends Number & Comparable<T>> T max(T a, T b) {
    return a.compareTo(b) >= 0 ? a : b;
}

The reason bounds matter: an unbounded T is erased to Object, so you can only call Object methods on it. Bounding to Number erases T to Number, unlocking its API. Connecting bounds to what erasure does is the deeper answer.

Q4. Explain wildcards and the PECS rule.

A wildcard ? represents an unknown type. ? extends T is an upper-bounded wildcard — a producer you read T from but cannot write to. ? super T is a lower-bounded wildcard — a consumer you write T into but read back only as Object. PECS: Producer Extends, Consumer Super.

// Copies from a producer (extends) into a consumer (super)
static <T> void copy(List<? extends T> src, List<? super T> dst) {
    for (T item : src) dst.add(item);
}

Why the asymmetry exists: from a List<? extends Number> you know every element is a Number, so reading is safe, but you cannot add because the exact type is unknown. Into a List<? super Integer> you can safely add Integers, but a read only guarantees Object. Deriving PECS from what is provably safe — rather than reciting the acronym — is the senior answer.

Q5. Why can't you create a generic array?

Arrays are covariant and enforce their element type at runtime (ArrayStoreException), while generics are erased and enforced only at compile time. If new List<String>[] were allowed, erasure would hide the type argument from the array's runtime check, letting a List<Integer> be stored where List<String> was expected — defeating type safety.

// List<String>[] arr = new List<String>[10]; // compile error: generic array creation
List<String>[] arr = (List<String>[]) new List[10]; // legal but unchecked, discouraged

The clean summary: arrays know their type at runtime; generics forget theirs. Mixing a runtime-checked, covariant construct with a compile-time-only one is unsafe, so the language forbids generic array creation. This is a favorite because it forces you to hold both erasure and array covariance in mind at once.

Q6. What is the difference between List