Q1: What happens when you modify a String in Java?

Why they ask: This tests whether you understand immutability — a concept that affects how you write production code, handle security, and manage memory.

What most candidates say: “Strings are immutable in Java.” Then they stop.

What the interviewer wants: Explain that when you “modify” a String, Java creates a new String object in the heap. The original remains unchanged. This is why concatenating Strings in a loop creates N objects and kills performance — you should use StringBuilder instead. Mention the String pool and how intern() works. If you can explain why Strings are immutable (thread safety, security for class loading, caching hashCode), you are ahead of 90% of candidates.

String s1 = "hello";
String s2 = s1.concat(" world"); // s1 is still "hello"
// s2 is a NEW object "hello world"
// In a loop, use StringBuilder:
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append(i); // One object, not 1000
}

Q2: Explain HashMap internals — how does put() actually work?

Why they ask: HashMap is the most used data structure in Java enterprise code. Understanding its internals separates developers who use it from developers who understand it.

The answer they want: HashMap uses an array of buckets. When you call put(key, value), Java calls key.hashCode(), applies a hash function to determine the bucket index, then stores the entry. If two keys hash to the same bucket (collision), entries are stored as a linked list in that bucket. Since Java 8, when a bucket exceeds 8 entries, the linked list converts to a balanced tree (red-black tree) for O(log n) lookup instead of O(n).

Follow-up trap: “What happens if you use a mutable object as a HashMap key and modify it after insertion?” Answer: the hashCode changes, so the entry becomes unretrievable from its original bucket. This is why String (immutable) is the most common HashMap key in practice.

Q3: Write code to find the second highest number in an array without sorting

Why they ask: This is the most common coding question at Indian service companies. It tests basic logic, edge case handling, and whether you can write clean code under pressure.

public static int secondHighest(int[] arr) {
    if (arr.length < 2) throw new IllegalArgumentException("Need at least 2 elements");
    int first = Integer.MIN_VALUE, second = Integer.MIN_VALUE;
    for (int num : arr) {
        if (num > first) {
            second = first;
            first = num;
        } else if (num > second && num != first) {
            second = num;
        }
    }
    if (second == Integer.MIN_VALUE) throw new RuntimeException("No second highest found");
    return second;
}

What separates good answers: Handling edge cases (array with all same elements, array with less than 2 elements), using Integer.MIN_VALUE instead of 0 as initial value, and explaining the O(n) time complexity.

Q4: Given an array of integers, find two numbers that add up to a target sum

Why they ask: The classic Two Sum problem. It tests whether you can optimize from O(n²) brute force to O(n) using a HashMap — the fundamental pattern behind hundreds of interview problems.

public static int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> seen = new HashMap<>();
    for (int i = 0; i < nums.length; i++) {
        int complement = target - nums[i];
        if (seen.containsKey(complement)) {
            return new int[] { seen.get(complement), i };
        }
        seen.put(nums[i], i);
    }
    throw new IllegalArgumentException("No solution found");
}

What the interviewer evaluates: Did you jump to the optimal solution or start with brute force and optimize? Can you explain the time-space tradeoff (O(n) time, O(n) space vs O(n²) time, O(1) space)? Can you handle edge cases (duplicate values, negative numbers)?

Q5: Design an LRU Cache

Why they ask: This is the most asked system design + coding hybrid question at Indian product companies. It tests your understanding of LinkedHashMap, doubly linked lists, and how caching works in real systems.

class LRUCache {
    private final int capacity;
    private final LinkedHashMap<Integer, Integer> cache;

    public LRUCache(int capacity) {
        this.capacity = capacity;
        this.cache = new LinkedHashMap<>(capacity, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<Integer, Integer> eldest) {
                return size() > capacity;
            }
        };
    }

    public int get(int key) {
        return cache.getOrDefault(key, -1);
    }

    public void put(int key, int value) {
        cache.put(key, value);
    }
}

The follow-up: “Now implement it without using LinkedHashMap — use a HashMap + doubly linked list.” This is where the real test begins. Product companies want to see you build the data structure from scratch.

Q6: Find the median of a stream of integers

Why they ask: This tests your knowledge of heap data structures and your ability to maintain running statistics efficiently — a common requirement in real-time data processing systems.

class MedianFinder {
    private PriorityQueue<Integer> maxHeap; // lower half
    private PriorityQueue<Integer> minHeap; // upper half

    public MedianFinder() {
        maxHeap = new PriorityQueue<>(Collections.reverseOrder());
        minHeap = new PriorityQueue<>();
    }

    public void addNum(int num) {
        maxHeap.offer(num);
        minHeap.offer(maxHeap.poll());
        if (minHeap.size() > maxHeap.size()) {
            maxHeap.offer(minHeap.poll());
        }
    }

    public double findMedian() {
        if (maxHeap.size() > minHeap.size()) return maxHeap.peek();
        return (maxHeap.peek() + minHeap.peek()) / 2.0;
    }
}

What GCC interviewers evaluate: Can you explain why two heaps work? Can you prove the time complexity (O(log n) per insertion, O(1) for median)? What happens with integer overflow in the median calculation? Can you extend this to a sliding window median?

Trap 1: The equals() and hashCode() contract

“You have a class Employee with fields name and id. You put an Employee object in a HashSet. Then you change the employee's name. Can you still find it in the HashSet?”

The trap: If you override equals() but not hashCode() (or vice versa), HashSet and HashMap break silently. If you mutate an object after inserting it into a hash-based collection, the hashCode changes but the bucket does not — the object becomes a ghost that exists in the set but cannot be found.

The rule: If two objects are equal (equals() returns true), they must have the same hashCode(). Always override both together. Never mutate objects used as keys in hash-based collections.

Trap 2: ConcurrentModificationException

“What happens when you remove elements from an ArrayList while iterating over it with a for-each loop?”

// THIS THROWS ConcurrentModificationException:
for (String s : list) {
    if (s.equals("remove")) list.remove(s); // BOOM
}

// CORRECT: Use Iterator.remove()
Iterator<String> it = list.iterator();
while (it.hasNext()) {
    if (it.next().equals("remove")) it.remove(); // Safe
}

// OR: Use removeIf() (Java 8+)
list.removeIf(s -> s.equals("remove")); // Cleanest

Trap 3: Integer caching — why == sometimes works for integers

Integer a = 127, b = 127;
System.out.println(a == b);  // true (cached)

Integer c = 128, d = 128;
System.out.println(c == d);  // false (new objects!)

// ALWAYS use .equals() for Integer comparison

Java caches Integer objects from -128 to 127. Within this range, == works because both variables point to the same cached object. Outside this range, new objects are created and == compares references, not values. This has caused real production bugs in banking software.