Programming Deep Dive — Interview-Grade Topics

The "defend your knowledge under probing" companion to 12_Programming_Basics.

Every topic has: What it is → Why interviewers ask → Code with explanation → Follow-up they'll ask → Wrong answer that gets you rejected.

---

PART 1: JAVA DEEP DIVE

1.1 — equals() and hashCode() contract

What

When you override equals() in a class, you MUST also override hashCode(). They have a binding contract.

Why interviewers ask

This is the #1 Java bug in production code. Misusing it breaks HashMap, HashSet, and anything that relies on hashing.

The contract (memorize these 3 rules)

1. If a.equals(b) is true → a.hashCode() == b.hashCode() MUST be true
2. If a.equals(b) is false → hashCodes MAY still be equal (collision)
3. hashCode() must return same value across multiple calls (unless object state changes)

Code

public class User {
    private String email;
    private String name;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User)) return false;
        User u = (User) o;
        return Objects.equals(email, u.email);   // identity = email only
    }

    @Override
    public int hashCode() {
        return Objects.hash(email);   // MUST use same field as equals
    }
}

What breaks if you don't override both

Set<User> users = new HashSet<>();
users.add(new User("a@x.com"));
users.contains(new User("a@x.com"));  // FALSE — different hashCode!

Follow-up they'll ask

• "What if email is null?" → Objects.hash() handles nulls safely
• "Why use instanceof and not getClass()?" → instanceof allows subclasses to be equal; getClass() is stricter. Choice depends on inheritance design.
• "What's the third equals rule (after reflexive, symmetric)?" → Transitive: if a=b and b=c, then a=c

Wrong answer that gets you rejected

"I override equals to check fields and that's enough." Why wrong: Without hashCode() override, hash-based collections silently break.

---

1.2 — HashMap internals (Java 8+)

What

Hash table implementation. Key → bucket via hash function. Collisions handled with linked list, upgraded to red-black tree if too many collisions.

Why interviewers ask

Tests if you understand performance characteristics and why hashCode matters.

How it works step by step

1. put(key, value) calls hash(key) — uses key's hashCode()
2. Index = hash & (n - 1) where n = bucket array size (always power of 2)
3. If bucket empty → store
4. If bucket has entry → check equals() to see if it's update or collision
5. If collision → append to linked list at that bucket
6. If list grows to 8+ nodes → convert to red-black tree (O(log n) lookup)
7. If load factor > 0.75 → resize array (doubles size, rehashes)

Code reading map internals

HashMap<String, Integer> map = new HashMap<>();
// Default capacity: 16 buckets
// Default load factor: 0.75
// Resize triggers at: 16 * 0.75 = 12 entries

map.put("hello", 1);
// 1. hash = hash("hello".hashCode())
// 2. index = hash & 15  (for 16 buckets)
// 3. bucket[index] = new Node("hello", 1)

Follow-up they'll ask

• "What's the time complexity of get()?" → O(1) average, O(log n) worst (with treeification), O(n) worst-worst (terrible hashCode)
• "What's load factor?" → Ratio of entries to capacity. Default 0.75 balances memory vs collision rate.
• "What happens during resize?" → New array (2x size), every entry rehashed. Expensive — pre-size if you know count.
• "Why bucket size = power of 2?" → Allows hash & (n-1) instead of slow modulo. Bit math is faster.
• "HashMap vs Hashtable vs ConcurrentHashMap?" → Hashtable is old, synchronized everything (slow). ConcurrentHashMap uses segment locking for thread-safe high performance.

Wrong answer that gets you rejected

"HashMap is O(1) always." Why wrong: Only on average. With bad hashCode, all entries collide → O(n).

---

1.3 — ArrayList vs LinkedList (real performance)

What

Both implement List but with very different underlying structures.

Why interviewers ask

Common trick question. The "obvious" answer (LinkedList is faster for inserts) is often wrong in practice.

Comparison

Operation	ArrayList	LinkedList
get(index)	O(1)	O(n) — must traverse
add(element) (to end)	O(1) amortized	O(1)
add(0, element) (to start)	O(n) — shifts all	O(1)
add(middle, element)	O(n) — shift	O(n) — traverse to find spot
remove(0)	O(n)	O(1)
Memory per element	low (array slot)	high (node + prev + next pointers)
Cache locality	excellent	terrible

The truth (most candidates miss this)

ArrayList wins in practice almost always. Reasons: 1. CPU cache loves contiguous memory (ArrayList) — even O(n) operations on ArrayList beat O(1) on LinkedList because of cache misses 2. LinkedList traversal pollutes the cache 3. Modern CPUs are wildly faster at sequential memory access

Code — when LinkedList actually wins

// LinkedList is fast as a Deque (queue from both ends)
Deque<String> queue = new LinkedList<>();
queue.addFirst("a");
queue.addLast("b");
queue.removeFirst();
// But ArrayDeque is usually even better!

Follow-up they'll ask

• "When would you actually use LinkedList?" → Honestly, rarely. As a Deque, prefer ArrayDeque.
• "Why is ArrayList.add() O(1) amortized?" → Most adds are O(1). When full, it doubles capacity (O(n) rare event). Averaged over many calls: O(1).
• "How does ArrayList grow?" → Default: 50% growth (was 100% in older Java). When full, new array allocated, contents copied.

Wrong answer that gets you rejected

"LinkedList is better for frequent insertions." Why wrong: Theory says yes, real-world CPU cache says no — except at the very ends.

---

1.4 — Why String is immutable

What

You cannot modify a String. All "modifications" create new Strings.

Why immutable?

1. String pool — JVM caches string literals to save memory. Mutability would break sharing.
2. Security — strings used in file paths, URLs, class names. Immutability prevents tampering after validation.
3. Hashing — String.hashCode() cached after first call. Mutability would invalidate.
4. Thread safety — immutable objects are inherently thread-safe.

Why interviewers ask

Tests if you understand JVM design philosophy.

The String pool

String a = "hello";      // goes into String pool
String b = "hello";      // reuses the SAME object from pool
String c = new String("hello");  // forces new object on HEAP

a == b;            // true — same reference
a == c;            // false — different objects
a.equals(c);       // true — content match
c.intern() == a;   // true — intern() returns pool reference

Follow-up they'll ask

• "How many String objects: String s = new String("hi");" → Two! "hi" in pool, plus new on heap.
• "What is StringBuilder vs StringBuffer?" → Both mutable. StringBuffer is synchronized (slower), StringBuilder is not (faster, single-thread). Use StringBuilder unless you need thread safety.
• "Why does s += "x" in a loop kill performance?" → Each iteration creates new String + new char array. Use StringBuilder.

Wrong answer that gets you rejected

"Strings are immutable so they can't be changed." Why wrong: That's the WHAT. The interviewer wants the WHY (4 reasons above).

---

1.5 — Checked vs Unchecked exceptions

What

• Checked: Must be declared in throws or caught. Compiler enforces. Extends Exception.
• Unchecked: No compile-time enforcement. Extends RuntimeException.

Why interviewers ask

Tests understanding of Java's design philosophy and error handling.

Hierarchy

Throwable
├── Error (system, unrecoverable — OutOfMemoryError, StackOverflowError)
└── Exception
    ├── RuntimeException (unchecked — NullPointerException, IllegalArgumentException)
    └── Other (checked — IOException, SQLException, ClassNotFoundException)

Code

// Checked — compiler forces you to handle
public void readFile() throws IOException {       // must declare
    FileReader f = new FileReader("a.txt");
}

// Or catch
public void readFile() {
    try {
        FileReader f = new FileReader("a.txt");
    } catch (IOException e) {
        // handle
    }
}

// Unchecked — no compiler enforcement
public void divide(int a, int b) {
    int x = a / b;          // throws ArithmeticException if b=0, no declaration needed
}

When to use which

• Checked for recoverable problems (file missing → user can retry)
• Unchecked for programming errors (null reference, illegal argument)

Follow-up they'll ask

• "Why do many devs hate checked exceptions?" → Forces verbose throws chains. Breaks lambdas (lambda can't throw checked). Modern libraries (Spring, Jakarta) lean unchecked.
• "What does try-with-resources do?" → Auto-calls close() on resources, even if exception thrown. Requires AutoCloseable.
• "What's exception chaining?" → throw new MyException("wrapper", originalException) preserves cause.

Wrong answer that gets you rejected

"Errors and Exceptions are the same." Why wrong: Error = JVM-level, don't catch. Exception = app-level, can handle.

---

1.6 — Stream API (Java 8+)

What

Functional-style operations on collections. Lazy, chainable, supports parallel.

Why interviewers ask

Modern Java code uses streams heavily. Confirms you're not stuck in Java 6.

Core pattern

List<String> names = List.of("Rohan", "Asha", "Bob", "Carol");

List<String> result = names.stream()
    .filter(n -> n.length() > 3)        // intermediate (lazy)
    .map(String::toUpperCase)           // intermediate (lazy)
    .sorted()                            // intermediate (lazy)
    .collect(Collectors.toList());      // terminal (triggers)
// [ASHA, CAROL, ROHAN]

Operations

Intermediate (return Stream, lazy): - filter(predicate) — keep matching - map(function) — transform each - flatMap(function) — flatten nested - sorted(), distinct(), limit(n), skip(n)

Terminal (trigger execution): - collect(collector) — to List, Set, Map - forEach(action) — side effect - count(), sum(), min(), max() - reduce(identity, accumulator) - anyMatch(), allMatch(), noneMatch() - findFirst(), findAny() — returns Optional

Real example

// Total age of adult users
int totalAge = users.stream()
    .filter(u -> u.getAge() >= 18)
    .mapToInt(User::getAge)
    .sum();

// Group by city
Map<String, List<User>> byCity = users.stream()
    .collect(Collectors.groupingBy(User::getCity));

// Average response time
double avg = responses.stream()
    .mapToLong(Response::getTimeMs)
    .average()
    .orElse(0);

Method references

Syntax	Meaning
String::toUpperCase	s -> s.toUpperCase()
System.out::println	x -> System.out.println(x)
User::new	() -> new User()
User::getName	u -> u.getName()

Follow-up they'll ask

• "Stream vs Collection?" → Collection holds data. Stream processes data. Streams are lazy and single-use.
• "What's parallelStream?" → Splits into chunks, processes on ForkJoinPool. Use only for CPU-bound, large datasets. Beware of side effects.
• "What does Collector do?" → Defines how to accumulate stream elements. Collectors.toList(), toMap(), groupingBy(), joining(",").

Wrong answer that gets you rejected

"I always use streams instead of for loops." Why wrong: Streams have overhead. For simple iteration, a for-loop is faster and clearer.

---

1.7 — Functional Interfaces

What

An interface with exactly one abstract method (SAM — Single Abstract Method). Can be used as lambda target.

Why interviewers ask

Foundation of lambdas and Stream API.

The Big 4

// 1. Function<T, R> — take T, return R
Function<String, Integer> length = s -> s.length();
length.apply("hello");   // 5

// 2. Predicate<T> — take T, return boolean
Predicate<Integer> isEven = n -> n % 2 == 0;
isEven.test(4);   // true

// 3. Consumer<T> — take T, return void
Consumer<String> printer = s -> System.out.println(s);
printer.accept("hi");

// 4. Supplier<T> — take nothing, return T
Supplier<LocalDate> today = () -> LocalDate.now();
today.get();

Custom functional interface

@FunctionalInterface           // optional but recommended (compiler check)
interface Calculator {
    int calculate(int a, int b);
}

Calculator add = (a, b) -> a + b;
add.calculate(2, 3);   // 5

Follow-up they'll ask

• "What's BiFunction?" → Like Function but takes 2 args: (a, b) -> result
• "UnaryOperator?" → Function — same input/output type
• "Why @FunctionalInterface annotation?" → Compiler error if interface has more than one abstract method

---

1.8 — Generics (bounded types, wildcards, type erasure)

What

Type parameters that let you write classes/methods working with any type while preserving type safety.

Why interviewers ask

Common source of bugs and confusion. Tests deep Java knowledge.

Basic generic class

public class Box<T> {
    private T value;
    public void set(T value) { this.value = value; }
    public T get() { return value; }
}

Box<String> b = new Box<>();
b.set("hello");
// b.set(42);  // compile error — type safety!

Bounded types

// T must be Number or subclass
public class NumberBox<T extends Number> {
    public double doubled() { return value.doubleValue() * 2; }
}

NumberBox<Integer> ok = new NumberBox<>();
// NumberBox<String> bad = new NumberBox<>();  // compile error

Wildcards

// ? extends — covariance (read-only from list's perspective)
public double sum(List<? extends Number> list) {
    double total = 0;
    for (Number n : list) total += n.doubleValue();
    return total;
    // list.add(...)  // ERROR — can't add to ? extends
}

// ? super — contravariance (write-only)
public void addNumbers(List<? super Integer> list) {
    list.add(1);    // OK
    list.add(2);
}

// PECS mnemonic: Producer Extends, Consumer Super
// If you READ from collection — use extends
// If you WRITE to collection — use super

Type erasure (tricky!)

At runtime, generic types are erased to Object. The compiler enforces types at compile time, then strips them.

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
a.getClass() == b.getClass();   // true — both are ArrayList at runtime!

// Cannot do:
public <T> T create() {
    return new T();           // ERROR — T erased
}
public boolean check(Object o) {
    return o instanceof List<String>;   // ERROR
}

Follow-up they'll ask

• "Why type erasure?" → Backward compatibility with pre-generics Java
• "What's a raw type?" → List (no <>) — bypasses type checking, dangerous
• "Diff between List<Object> and List<?>?" → List<Object> only accepts List