Interactive Lab · Data structures
It doesn't scan. It computes where the key lives. A hash table runs the key through a hash function to get a bucket number, then jumps straight there, that's the O(1) magic. But two keys can land in the same bucket (a collision), and as the table fills up the chains grow. Insert keys, watch them collide, then hit Resize and see O(1) come back.
🎬 Watch the 45-second explainer, then try it yourself below ↓
▶ The playground, insert keys, watch where they land
Hash tables are the most-used data structure in software: Python dicts, JS objects, database shards, load-balancer routing, Redis itself. The load-factor resize you just triggered runs silently millions of times a day in production, and hash collisions becoming chains is why worst-case attacks (hash flooding) forced randomized hashing into every language runtime.
The code that's actually running
Insert keys one at a time until two land in the same bucket (a collision), before you look up the second one, predict: does the table jump straight to the wrong answer, or does it scan the little chain to find the right key? Now press ⚡ Fill to overload to push the load factor past 0.75 and hit ⇲ Resize. Why does doubling the buckets make lookups fast again, even though every key had to move?
The takeaway
hash(key) % bucketsso lookup is average O(1): it jumps, it doesn't scan.