A few cases. In hard-real-time / ISR paths, the O(n) worst case (everything collides, or a resize triggers mid-operation) and generally non-deterministic timing make it risky, you want bounded WCET, so a sorted array with O(log n) binary search or a direct-mapped table is safer. When you need ordering, nearest key, range queries, in-order traversal, a hash table offers none; a sorted array or balanced tree fits. When the key space is small and dense, a hash table is overkill: a direct-mapped lookup table (array indexed by key) gives O(1) worst-case with zero collisions and less code. And when memory is extremely tight, the sparse table (you keep α low, so many empty slots) wastes RAM compared to a compact sorted array. So hash tables shine for large, sparse, unordered keyed lookup with average-case timing tolerances, and are wrong when you need worst-case guarantees, ordering, or maximum memory density.
Data Structures & Algorithms · Interview question
When is a hash table the wrong choice?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Hash Tables
O(1)-average keyed lookup by mapping keys to array slots: collisions, load factor, and why open addressing into a fixed array beats chaining when you have no heap.