JavaEqualityHashingCollectionsjunior level

Keeping equals and hashCode in Sync

the question

Why should you override `hashCode()` whenever you override `equals()` in Java? What can go wrong if you do not?

what they're testing: The interviewer is probing whether you can connect Java's equality contract to the lookup behavior of hash-based collections.

a strong answer

When a class overrides equals(), it should also override hashCode() so equal objects always produce the same hash code. Java's contract is one-way: if a.equals(b) is true, their hash codes must match. Unequal objects may still share a hash code. That is a collision, not a contract violation.

A HashMap or HashSet uses the hash to narrow its search, then checks equality to find the matching key or element. If two logically equal instances produce different hashes, the collection may search different buckets and never compare them with equals(). A lookup with one instance can miss an entry inserted with the other, and a set can retain both. This commonly happens when a class overrides equals() but inherits Object.hashCode(), whose result is not based on the class's logical equality.

Build both methods from the same equality-defining fields. If Customer.equals() depends on customerId, its hash code must be consistent with that choice. Do not change equality-defining state while the object is a key or set element. Hash-based lookup and removal can then become unreliable, and the Map contract leaves behavior unspecified when key mutation affects equality.

Where people slip

the tempting wrong answer, and what's actually true

If two objects have the same hash code, they must be equal.
Unequal objects may share a hash code, so `equals()` still has to resolve collisions.
Overriding `equals()` is enough because `HashMap` will eventually call it.
Different hash codes can direct equal keys to different buckets, so lookup may never compare them with `equals()`.
A correct `hashCode()` must return a unique value for every object.
The contract only requires equal objects to share a hash code, though fewer collisions usually improve hash-table performance.

If they push further

What happens when two unequal objects have the same hash code?

That is a valid collision; the collection compares keys with identity or `equals()` inside the selected bucket. Too many collisions hurt performance, not correctness.

Which fields should `hashCode()` use?

Use equality-relevant state so anything equal under `equals()` necessarily produces the same hash. A constant hash is legal but gives poor distribution.

Why are mutable map keys risky?

Changing equality-defining state after insertion can make lookup and removal unreliable; the `Map` contract leaves behavior unspecified when key mutation affects equality. Prefer immutable keys, or at least do not mutate the fields used by `equals()` and `hashCode()`.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.