Why this matters beyond interviews
Data structures get a bad reputation as "interview trivia," but the honest reason to know them is simpler: picking the wrong one is one of the most common ways real code gets slow. Choosing between an array and a hash map isn't academic — it's the difference between a page that loads instantly and one that times out once your data grows.
Arrays: the default, for a reason
An array stores items in contiguous memory, in order. Reading any index is instant — O(1) — because the computer can calculate exactly where that item lives. The cost shows up when you insert or remove from the middle: everything after that point has to shift, which is O(n).
Use arrays when you mostly read by position and append to the end. Avoid them when you're constantly inserting or removing from the front or middle of a large list.
Hash maps: trading order for speed
A hash map (a plain JavaScript object, or a Python dict) gives you near-instant lookup by key — average-case O(1) — by converting the key into a number (a hash) that points directly to a memory slot. You give up ordering guarantees in exchange for speed.
# Checking membership: array vs hash map
if user_id in list_of_ids: # O(n) — checks every item
...
if user_id in set_of_ids: # O(1) average — hash lookup
...That single change — list to set — is one of the most common "why is this slow" fixes in real code review.
Linked lists: rare in practice, but worth understanding
A linked list is a chain of nodes, each pointing to the next. Inserting or removing a node is O(1) once you have a reference to it, since you're just relinking pointers — no shifting. The tradeoff: you lose random access. To reach the 500th item, you walk the chain from the start, one node at a time.
You'll rarely reach for one directly in application code (arrays usually win in practice due to CPU cache behavior), but the concept underlies things you do use constantly — like how a browser's history stack or an undo/redo feature is often modeled.
Stacks and queues: same idea, different discipline
A stack is last-in-first-out — think of a stack of plates, you take from the top. A queue is first-in-first-out — a checkout line. Both can be built on top of an array or linked list; what makes them "a stack" or "a queue" is just the rule you enforce about which end you add to and remove from.
Stacks show up in undo history, and in how function calls track their own return points (the "call stack" — where "stack overflow" gets its name). Queues show up anywhere work needs to be processed in the order it arrived, like a background job processor.
Trees: when hierarchy is the point
A tree is a set of connected nodes with no cycles — one root, and everything branches down from there. File systems, HTML's DOM, and comment threads (including the ones on this site) are all naturally trees. Searching a balanced tree is O(log n) — each comparison eliminates half the remaining possibilities, which is why sorted data structures like this stay fast even as they grow into the millions.
The one habit worth building
Before reaching for a data structure out of habit, ask what you're actually optimizing for: fast lookup, ordered iteration, fast insertion at a specific point, or memory efficiency. There's rarely a structure that wins at all four — picking one is always a tradeoff, and the "best" choice is the one that matches what your code actually does most often.
Comments