Core Data Structures
Arrays, hash maps, trees, heaps — and the operation costs that decide which one you reach for.
70 minDifficulty 3/5cs · interviewAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
Why this exists
Searching for one item in a list of a million takes up to a million comparisons with an array, and about twenty with a balanced tree, and roughly one with a well-built hash map — same task, three wildly different costs, purely because of which structure holds the data. Picking the right one isn't academic; it's the difference between a page that loads instantly and one that times out.
The mental model
Every data structure is a specific trade-off between how fast you can look something up, insert something new, delete something, and how much memory it costs — no structure wins at everything simultaneously. Knowing the actual operation your code does most often is what tells you which structure's trade-offs actually fit.
How it works
Arrays: fast indexed access, slow arbitrary insertion
`array[500]` is O(1) — the memory address is computed directly from the index, no searching required. Inserting or removing an element in the MIDDLE of an array is O(n), because every subsequent element has to physically shift over by one position to close or open the gap. Appending to the END is typically O(1) (amortized), which is why arrays excel at ordered, index-accessed, append-heavy data.
Hash maps: near-constant lookup by key, no inherent order
A hash map computes a numeric hash from a key and uses it to jump nearly directly to where that key's value lives, giving average O(1) lookup, insertion, and deletion regardless of how many entries exist. The cost is that entries have no inherent order — iterating a hash map doesn't guarantee any particular sequence, and a poor hash function or too many collisions can degrade this to O(n) in the worst case.
Trees: ordered data with logarithmic operations
A balanced binary search tree keeps elements sorted and guarantees O(log n) for search, insertion, and deletion — for a million elements, that's about 20 comparisons, not a million. The structure achieves this by halving the search space at each step, the same principle as `debugging-method`'s bisection, but built permanently into the data's shape rather than performed once.
Heaps: fast access to the minimum or maximum, nothing else
A heap guarantees O(1) access to the smallest (or largest) element and O(log n) insertion and removal of that extreme value — but finding an ARBITRARY element buried inside a heap is O(n), since the structure is only organized relative to the top. This narrow but extremely efficient specialty is exactly what a priority queue (like a task scheduler picking the highest-priority job next) needs.
The mechanism
The dominant operation in your actual usage pattern — not a theoretical worst case, but what your code does most often — determines the right structure. Indexed, sequential, or append-heavy access favours arrays. Lookup by an identifier with no ordering need favours hash maps. A need for both sorted order and fast search favours a balanced tree. Repeatedly needing just the current minimum or maximum favours a heap.
flowchart TD Q[What operation dominates?] -->|indexed access, ordered, append| Arr[Array] Q -->|lookup by key, order doesn't matter| Hash[Hash Map] Q -->|need sorted order + fast search| Tree[Balanced Tree] Q -->|repeatedly need the min/max| Heap[Heap]
What people get wrong
- A hash map is always the fastest choice, since O(1) beats O(log n) and O(n).
- O(1) average-case for a hash map assumes a good hash function and manageable collisions — and it provides no ordering guarantee at all, which is a real cost when you actually need sorted iteration, not just lookup. Choosing purely by big-O notation without considering what the structure DOESN'T provide (like order) leads to reaching for a hash map and then bolting on a separate sort every time you need ordered output, which negates the advantage.
- Arrays are simple and therefore always the safe default choice for a collection.
- An array's O(n) cost for arbitrary insertion or deletion becomes a genuine bottleneck once the collection is large and mutated frequently in the middle — the 'simple' choice can be the slow one for exactly the operations your code actually does most. Reaching for an array by default without considering the actual access pattern is how a feature that works fine with 100 items becomes noticeably slow at 100,000.
- A heap is just a sorted list with a different name.
- A heap only guarantees the minimum (or maximum) is efficiently accessible at the top — the rest of its internal structure is NOT fully sorted, which is exactly what makes insertion and removal of the extreme value cheaper (O(log n)) than maintaining a fully sorted structure would be. Expecting to efficiently find or iterate arbitrary elements in sorted order from a heap will lead to writing code that's actually O(n log n) — sorting the whole heap — when a different structure would have supported that access pattern natively.
When not to use it
- You need to repeatedly find and remove the highest-priority item from a growing collection.
- A heap, specifically — used as a priority queue, giving O(log n) for both insertion and extracting the top item, which a sorted array would only match for the extraction but not the insertion.
- You need to check whether an item exists in a collection, with no need to iterate in any particular order.
- A hash set (or hash map with dummy values), giving average O(1) membership checks — far faster than scanning an array (O(n)) for large collections.
Terms
- Big-O notation
- — A way of describing how an operation's cost grows relative to the size of the input, independent of specific hardware or constant factors.
- Amortized
- — Describing a cost that averages out to a certain complexity over many operations, even if a specific individual operation occasionally costs more (like an array resizing).
- Hash collision
- — When two different keys produce the same hash value, requiring extra handling that can degrade a hash map's average O(1) performance if collisions are frequent.
- Priority queue
- — An abstract data type supporting efficient access to the highest (or lowest) priority element, commonly implemented with a heap.
In an interview
You need to check if a value exists in a collection of a million items, many times per second. Which structure, and why not an array?
- a hash set gives average O(1) membership checks regardless of collection size
- an array requires O(n) in the worst case, scanning up to every element
- the difference is negligible at small n but becomes significant at large n or high call frequency
Can you recall it?
Why does a hash map provide fast lookup but no ordering guarantee, while a balanced tree provides both sorted order and reasonably fast search?