Java interview questions & practice path

A strong answer covers

• ·equals() defines logical equality; hashCode() returns an int used to bucket objects in hash-based collections
• ·The contract: equal objects must return equal hash codes, and hashCode should be consistent across calls while the object is unchanged
• ·If you override equals() but not hashCode(), two logically equal objects can land in different buckets, so a HashMap or HashSet fails to find or de-duplicate them
• ·Both should be built from the same immutable, identity-defining fields; Objects.equals and Objects.hash make correct implementations easy

Common mistakes

• ×Claiming equal hash codes imply equal objects (collisions are allowed and expected)
• ×Including mutable fields in the calculation, which corrupts the object's location in a hash collection when the field changes
• ×Forgetting the null and type checks in equals(), or using == on object fields instead of Objects.equals

A strong answer covers

• ·Checked exceptions extend Exception (but not RuntimeException) and must be declared or caught; the compiler enforces handling
• ·Unchecked exceptions extend RuntimeException and are not enforced at compile time; Errors signal unrecoverable JVM problems
• ·Use checked exceptions for recoverable conditions a caller can reasonably handle, such as IO failures; use unchecked for programming errors like invalid arguments or null misuse
• ·Good practice: do not swallow exceptions, preserve the cause when wrapping, and avoid overly broad catch blocks

Common mistakes

• ×Catching Exception or Throwable broadly and silently ignoring it
• ×Wrapping and rethrowing without passing the original cause, losing the stack trace
• ×Overusing checked exceptions for conditions the caller cannot act on, cluttering signatures

A strong answer covers

• ·A HashMap is an array of buckets; the key's hashCode is spread and masked to an index, giving average O(1) get and put
• ·Collisions are handled by chaining entries in the same bucket; since Java 8 a bucket converts from a linked list to a balanced tree once it exceeds a threshold (default 8), bounding worst case to O(log n)
• ·When size exceeds capacity times load factor (default 0.75), the table resizes and rehashes all entries
• ·Keys must have stable, correct hashCode and equals; HashMap is not thread-safe, so use ConcurrentHashMap under concurrency

Common mistakes

• ×Saying HashMap is always O(1) and ignoring the degenerate collision case and treeification threshold
• ×Claiming HashMap is thread-safe or that Collections.synchronizedMap gives the same scalability as ConcurrentHashMap
• ×Using a mutable object as a key and mutating a field that participates in hashCode after insertion

A strong answer covers

• ·Generics are a compile-time feature; the compiler checks types then erases them, replacing type parameters with their bounds (or Object) so the bytecode carries no generic type info at runtime
• ·Consequences: you cannot do instanceof on a parameterized type, cannot create arrays of a generic type directly, and List<String> and List<Integer> share one runtime class
• ·The compiler inserts synthetic casts and bridge methods to preserve type safety and polymorphism across erasure
• ·Wildcards and bounds (? extends, ? super) follow PECS, and reifiable info can be recovered via Class tokens or super-type-token tricks

Common mistakes

• ×Believing generic type information exists at runtime and can be reflected on directly
• ×Ignoring unchecked-cast or heap-pollution warnings, especially with varargs of generic types
• ×Confusing List<Object> with List<?> or misapplying extends vs super when producing versus consuming

A strong answer covers

• ·volatile guarantees visibility and ordering (a happens-before edge) for a single field: reads always see the latest write, and it prevents certain reorderings, but it provides no atomicity for compound actions
• ·synchronized provides both mutual exclusion and visibility, establishing happens-before on lock release/acquire, so it can make multi-step updates atomic
• ·volatile suffices for a simple flag or a single publish of an immutable reference; it is not enough for read-modify-write like counter++, which needs synchronized or an Atomic type
• ·Mention the Java Memory Model: happens-before is the correctness contract; AtomicInteger and friends offer lock-free compare-and-swap for single variables

Common mistakes

• ×Assuming volatile makes compound operations like increment atomic
• ×Thinking synchronized only provides mutual exclusion and forgetting its visibility (memory barrier) guarantees
• ×Over-synchronizing everything, causing contention, or under-synchronizing shared mutable state and relying on luck

A strong answer covers

• ·String immutability means the character data cannot change after construction, which makes Strings safe to share across threads without synchronization and safe as HashMap keys since their hashCode is stable and cached
• ·The string pool (interned literals) lets identical compile-time literals share one instance, saving memory; immutability is what makes that sharing safe
• ·Literals are pooled automatically; new String("x") creates a distinct heap object, and intern() returns the pooled canonical instance
• ·Use == only for reference identity and equals() for content; heavy concatenation in loops should use StringBuilder to avoid creating many intermediate objects

Common mistakes

• ×Comparing string content with == and getting surprised by pooled versus new-allocated instances
• ×Claiming immutability guarantees security while ignoring that the pool can retain sensitive data in memory (char[] is preferred for passwords)
• ×Building large strings with + in a loop, creating quadratic allocation instead of using StringBuilder