Build the mental model
Choosing a data structure comes down to naming the actual access pattern before naming any structure. Ask, in order: do I need to preserve insertion order and iterate it back? — a list (or deque if both ends matter). Do I need O(1) lookup by key with no ordering requirement at all? — a dict or set, backed by hashing. Do I need sorted order maintained continuously while also supporting fast search — a balanced tree (or, if inserts are rare relative to reads, a plain sorted list combined with binary search, which is simpler and cache-friendly). Do I only ever need the current smallest or largest item, repeatedly, as items come and go? — a heap, which keeps that one operation O(log n) without ever fully sorting. Do I need efficient add/remove from both the front and the back? — a deque, since a plain list's front operations are O(n). Do I need prefix-based lookup, like autocomplete? — a Trie, which shares common prefixes across many keys instead of scanning every candidate string. The discipline is resisting the urge to reach for the structure you know best (usually a list or dict) and instead deriving the requirement first — order? uniqueness? extremity? prefix? — then matching it to the structure built for exactly that.
Connect it to a real scenario
Imagine auditing Tutorial Platform's "Trending Now" widget — an engineer re-sorts an entire list every time a view count changes just to show the top 5 lessons. The real access pattern is "repeatedly retrieve the top-k," which a heap serves far more efficiently. Reviewing a data structure choice this way is how you catch a design built on a misread access pattern before it becomes a performance problem in production.
Try the working example
# Scenario 1: always track the 3 most-viewed lessons, updated on every view
# — need repeated access to the current smallest/largest among changing items
# Scenario 2: check in O(1) whether a username has already been taken,
# with no need to ever list usernames in any particular order
# Scenario 3: power an autocomplete box that suggests tutorial titles
# as the user types each additional letter of a prefix
# Scenario 4: maintain a "recently viewed lessons" list where new views
# are added to the front and old views drop off the back once it's fullThe correct matches are Scenario 1 → heap, Scenario 2 → set (or dict), Scenario 3 → Trie, Scenario 4 → deque.5-minute try-it
For each of the four scenarios, choose the most suitable data structure and write one sentence justifying it by naming the scenario's access pattern and why it fits better than the alternatives.
One important caution
Defaulting to a sorted list for Scenario 1 — a sorted list needs O(n) insertion to stay sorted, which is slower than a heap's O(log n) update when view counts change frequently.
Defaulting to a plain list for Scenario 4 — inserting/removing at the front of a list shifts every remaining item, an O(n) operation, missing that a deque gives O(1) front operations for exactly this pattern.
Wikipedia — Abstract data type — Data Structures & Algorithms