Choosing HashSet vs TreeSet
Fast recall
Quick revision
Core answer
subSet, headSet, tailSet), or first/last access. Don't pay the log-n tax for sorting you never use.Practical judgment in selecting appropriate data structures based on requirements and performance characteristics
Using TreeSet unnecessarily because sorted order seems nice, paying O(log n) cost for operations that don't require ordering
Give specific scenarios: finding unique words in text (HashSet), displaying unique words alphabetically (TreeSet), finding words in a lexicographic range (TreeSet with subSet method)
Interview-ready guide
Interview answer
I'd start with HashSet as the default because it's faster.
HashSet gives you constant time operations: add, remove, and contains are all order one. That's hard to beat. You only switch to TreeSet when you actually need its ordering features.
So when would you need TreeSet? If you're building something like a leaderboard where you display players sorted by score, TreeSet keeps them sorted automatically, and you can iterate in order. Or if you need range queries, like finding all orders between two timestamps, TreeSet has methods like subSet that make that efficient.
TreeSet also gives you quick access to the smallest and largest elements with first and last. But if you're just tracking unique values, like collecting unique user ids or removing duplicates, HashSet is the better choice.
A common mistake is using TreeSet because sorted output looks nice, even when the business logic never needs the sorting. That's paying a cost for nothing. The performance gap matters at scale.
With a million elements, order one is instant, but order log n is about twenty comparisons per operation. So my rule is simple: use HashSet unless you have a real need for sorted order or range operations. Don't over-engineer it.
Choosing HashSet vs TreeSet
Direct Answer
Default to HashSet for O(1) add/remove/contains when you only need uniqueness. Reach for TreeSet (O(log n), red-black tree) only when you need sorted iteration, range queries (subSet, headSet, tailSet), or first/last access. Don't pay the log-n tax for sorting you never use.
Common Mistakes & Pitfalls
- Defaulting to TreeSet because sorted seems better: keeping things sorted feels tidy, but it pays O(log n) on every operation when the sorted order never gets read. Choose by requirement, not by what looks organized.
- Forgetting Comparable/Comparator:
TreeSetneeds its elements to be comparable. Pick it for custom objects with noComparableand noComparator, and you get aClassCastExceptionat runtime.HashSethas no such requirement. - Reaching for TreeSet when you wanted insertion order:
TreeSetsorts; it does not preserve the order you added things. For first-seen order at O(1),LinkedHashSetis the right pick.
Check your understanding
Answer these without looking back at the article.
- How do you get the smallest element from a TreeSet?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.