Si dos objetos son iguales según equals, deben devolver el mismo hashCode; los objetos distintos pueden compartir hash, aunque idealmente no lo hagan. Si lo rompes, las colecciones basadas en hash fallan: un objeto metido en un HashMap queda inalcanzable porque la búsqueda va a otro bucket. equals también debe ser reflexivo, simétrico, transitivo y consistente, y mutar un campo usado en el hash después de insertar pierde la entrada igual de bien.
Por qué lo preguntan los entrevistadores
Es una comprobación de fundamentos que predice bugs reales, sobre todo en bases de código que usan entidades como claves de mapa o dentro de sets. El entrevistador quiere la implicación en un solo sentido bien enunciada, más el fallo práctico: un set que contiene un elemento que no puede encontrar. Las repreguntas suelen ir a las entidades JPA, donde hacer equals sobre un id generado es una trampa clásica, y a los records, que generan ambos por ti.
Cómo estructurar tu respuesta
- Enuncia el contrato como una implicación, no como una equivalencia.
- Describe el fallo concreto en un HashMap o un HashSet.
- Menciona la mutabilidad de los campos usados en el hash.
- Di qué haces en la práctica: records, o una clave de negocio estable.
Ejemplo de respuesta
La regla va en un solo sentido: los objetos iguales deben tener hash codes iguales, pero hash codes iguales no implican igualdad, y por eso el mapa sigue llamando a equals dentro del bucket. Si sobrescribo equals y olvido hashCode, dos objetos que son iguales caen en buckets distintos, así que puedo meter algo en un HashSet y que contains devuelva false para un objeto idéntico. La versión más sutil es la mutación. Si un campo usado en el hash cambia después de que el objeto esté en un set, la entrada queda en el bucket equivocado y se pierde de hecho, lo que aparece como una fuga porque tampoco se puede eliminar. En la práctica uso records para los tipos de valor, así ambos métodos se generan y quedan consistentes. Con entidades JPA voy con cuidado, porque usar un id generado significa que equals cambia cuando la entidad se persiste, así que una entidad metida en un HashSet antes del flush se comporta distinto después. Uso una clave natural o de negocio estable cuando existe, y si no evito meter entidades sin guardar en colecciones basadas en hash.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo implementarías equals para una entidad JPA con un id generado?
- ¿Qué te genera un record, y cuándo no es lo que quieres?
- ¿Por qué una función hash mala degrada un HashMap aunque sea correcta?
Más preguntas para Desarrollador Java
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas