Scribd
Upload
5 views7 pages

Java Common Mistakes

The document outlines five common mistakes Java developers make during interviews that can lead to rejection. Key mistakes include using '==' for string comparison instead of '.equals()', failing to override 'hashCode()' when 'equals()' is overridden, not closing resources properly, misunderstanding the difference between 'volatile' and 'synchronized', and assuming 'HashMap' is thread-safe. Avoiding these mistakes can help candidates stand out in interviews.

Uploaded by

itspawan.yadav930
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views7 pages

Java Common Mistakes

The document outlines five common mistakes Java developers make during interviews that can lead to rejection. Key mistakes include using '==' for string comparison instead of '.equals()', failing to override 'hashCode()' when 'equals()' is overridden, not closing resources properly, misunderstanding the difference between 'volatile' and 'synchronized', and assuming 'HashMap' is thread-safe. Avoiding these mistakes can help candidates stand out in interviews.

Uploaded by

itspawan.yadav930
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

■ 5 Common Java Mistakes

That Fail Interviews


■ These are mistakes that even freshers and mid-level
developers often make in interviews.

■ Master them to stand out and avoid rejection.

➡■ Swipe to learn each mistake in detail.


■ Mistake #1: Using == for Strings

Many developers mistakenly use '==' to compare strings.

'==' checks if two references point to the SAME object.

'.equals()' checks if two strings have the SAME VALUE.

Example:

String a = "Java";

String b = new String("Java");

[Link](a == b); // false

■ Always use '.equals()' for comparing string values.


■ Mistake #2: Overriding equals() but not
hashCode()
When you override equals() without hashCode(), collections like HashMap
or HashSet break.

Objects that are 'equal' might end up in different hash buckets.

This causes issues in lookups, removals, and duplicate handling.

■ Rule: If you override equals(), ALWAYS override hashCode() too.


■ Mistake #3: Not closing resources

Database connections, file readers, sockets — leaving them open causes


memory leaks and performance issues.

Older code used finally blocks. Java 7+ introduced try-with-resources:

try (Resource r = ...) {

// use resource

} // auto-closes resource

■ Use try-with-resources for safe and clean code.


■ Mistake #4: Misunderstanding volatile vs
synchronized
'volatile' ensures VISIBILITY: all threads see the updated value.

It does NOT ensure atomicity (no race condition protection).

'synchronized' ensures both ATOMICITY and VISIBILITY.

■ Use 'volatile' for simple flags.

■ Use 'synchronized' blocks or locks for compound operations.


■ Mistake #5: Assuming HashMap is
thread-safe
HashMap is NOT thread-safe. In concurrent environments it can cause
data loss, corruption, or even infinite loops.

Example: multiple threads inserting into a HashMap may overwrite data.

■ Prefer ConcurrentHashMap for concurrent access.

■ Alternatively, wrap with [Link](map)


(coarse-grained).
■ Final Tip

These 5 mistakes often decide PASS or FAIL in interviews.

Avoid them, and you'll stand out as a strong Java candidate.

■ Which one surprised you most? Comment below ■

■ Follow for daily Java interview prep & backend tips ■

You might also like