4.5 — Inside an object: the hash trick
Lesson 4.2 explained the array's speed: an index is a number, and numbers do arithmetic — start + index × size, jump, done. But an object finds values by name: prices.mug answers instantly even in an object with ten thousand keys. And you can't multiply "mug" by eight. So… how?
The answer is one of the great tricks of computer science: turn the word into a number first. A hash function scrambles any string into a number, the number picks a storage bucket, and lookup-by-name becomes lookup-by-number — O(1) again.
The structure this builds is called a hash map, and once you see it, half of computing (and half of interview questions) clicks into place.
const prices = { pen: 2, mug: 9, fan: 15 };
console.log(prices.mug);
console.log(prices["fan"]);
// under the hood, roughly:
// hash("mug") → 7 → bucket 7 holds 9State the problem honestly. Without a trick, finding "mug" among an object’s keys would mean scanning them one by one — O(n), the climbing cost line from 4.2. Fine for 3 keys; a disaster for the 10,000-key objects real programs juggle. Objects need what arrays have: a way to COMPUTE where a thing lives.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
The full honest picture. A hash function maps a string to a number. The number is squeezed into the bucket range — commonly with a remainder, hash % bucketCount (% means “what’s left over after dividing”). The key AND value are stored in that bucket. Lookup re-hashes and jumps.
Collisions put a small pile in one bucket; when piles grow, the engine quietly makes more buckets and re-files everything — keeping average lookup O(1).
Even more honestly: V8 gives objects an extra optimization layer first. It calls them hidden classes — objects with the same property layout share a lookup shortcut. For objects used like dictionaries, V8 falls back to true hash-map mode. Both roads end at the same promise: finding a property does not scan the keys.
Fun fact: a cloakroom runs the same algorithm. You hand over your coat and get ticket 47; retrieval is “hook 47, walk straight there” — nobody searches the racks. The ticket machine is the hash function: it turns you (a name) into a number the room can jump to.
⌨️ the same lookup, two costs
Feel the difference with your own hands: find Zoe’s number in an ARRAY (walk and check — the O(n) way), then in an OBJECT (one hash jump — the O(1) way).
requirements:
- Create
contacts, an ARRAY of two objects:{ name: "ana", num: 111 }and{ name: "zoe", num: 333 }. - Find Zoe the array way: a variable
foundstarting at0, a 2.6-styleforloop over the array, anifcomparing each element'snameto"zoe"— store the matchingnum. Printfound. - Now build
contactsObj, an OBJECT: keyana→111, keyzoe→333. Print Zoe's number with a single direct lookup — no loop.
when you press RUN, the console must show exactly:
✏️ Quick check 1
hash("mug") gave 7 today. You restart the program and hash "mug" again tomorrow. Type the number it gives.
✏️ Quick check 2
An object holds 10,000 keys. Does reading obj.zebra SCAN through the keys? Type yes or no.
✏️ Quick check 3
The array-lookup cost from 4.2 was O(1) by INDEX. Object lookup is O(1) by ___ — type the missing word.
🗣️ Now teach it back
An interviewer asks: “Why is looking up a value by key in an object O(1)? Strings aren’t numbers — what’s actually happening?” Give the full answer: hash function, buckets, collisions.
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.