A data structure is a specific way of organising and storing data to enable efficient access and modification — common examples include arrays (ordered, indexed lists), linked lists (a chain of connected elements), stacks (last-in-first-out), and queues (first-in-first-out). Choosing the right data structure for a task significantly affects a program's efficiency: an array offers fast access to any element by its position, while a linked list makes inserting or removing elements in the middle more efficient. An algorithm's efficiency is often described using Big O notation, which characterises how its runtime or memory use grows as the input size increases — helping compare different approaches to the same problem beyond just 'does it work?'
Example
Searching for a specific name in an unsorted list of a million names requires checking each one until you find it (potentially all million, in the worst case) — but if that same list were sorted alphabetically, a binary search could find the name by repeatedly halving the search area, needing only about 20 comparisons instead of up to a million, illustrating how the right data structure (a sorted list) combined with the right algorithm (binary search) can dramatically improve efficiency.
Key terms
Data structure:
A specific way of organising and storing data for efficient access and modification.
Big O notation:
A way of describing how an algorithm's runtime or memory use grows as input size increases.
Questions
1. A data structure is:
A specific way of organising and storing data
A type of programming error
Something unrelated to how data is stored
A fixed, unchangeable single value
2. An array is:
An ordered, indexed list
A type of encryption
Something with no defined structure
A single isolated value with no list involved
3. A stack follows a:
Last-in-first-out order
First-in-first-out order
Completely random order
No defined order at all
4. A queue follows a:
First-in-first-out order
Last-in-first-out order
Completely random order
No defined order at all
5. Big O notation describes:
How an algorithm's runtime or memory use grows with input size
A type of file format only
Nothing related to algorithm efficiency
A fixed value that never changes for any algorithm
6. A linked list is:
A chain of connected elements
A single unconnected value
A type of encryption method
Something unrelated to data structures
7. Choosing the right data structure for a task can significantly affect:
A program's efficiency
Nothing about how a program performs
Only a program's visual appearance
Only the programming language used
8. Why might a linked list be more efficient than an array for frequently inserting or removing elements in the middle of a collection?
A linked list can adjust connections between nearby elements directly, while an array often needs to shift many other elements to make room or fill a gap
A linked list and an array always perform insertions and removals with exactly identical efficiency
Arrays are always more efficient than linked lists for every possible operation, with no exceptions
The specific data structure used has no bearing on how efficiently elements can be inserted or removed
9. Why might a stack (last-in-first-out) be a natural data structure for implementing an "undo" feature in software?
The most recently performed action needs to be the first one undone, which matches exactly how a stack retrieves its most recently added item first
A stack retrieves items in the exact order they were originally added, making it unsuitable for an undo feature
Undo features in software are never actually implemented using any particular data structure
Last-in-first-out ordering has no genuine connection to how an undo feature needs to behave
10. Why might a queue (first-in-first-out) be a natural data structure for managing tasks waiting to be printed at a shared office printer?
Print jobs are typically expected to be processed in the order they were submitted, matching exactly how a queue releases its earliest added item first
A queue processes the most recently added item first, making it unsuitable for managing a print job order
Print job management is never actually handled using any specific data structure
First-in-first-out ordering has no genuine connection to how a shared printer queue is expected to behave
11. Why is Big O notation useful for comparing two different algorithms that solve the same problem, beyond just testing them on a small sample of data?
It describes how each algorithm's performance scales as input size grows, revealing which approach remains efficient for genuinely large, real-world data sets
Big O notation only ever provides useful information for very small data sets, never larger, real-world ones
Testing algorithms on a small sample of data always reveals exactly the same information as Big O analysis
Comparing how algorithms scale with input size provides no additional useful insight beyond simple testing
12. Why might an algorithm described as O(n) (linear time) generally be considered more scalable than one described as O(n²) (quadratic time) as input size grows very large?
An O(n) algorithm's running time grows proportionally with input size, while an O(n²) algorithm's running time grows much faster, becoming a significant problem for large inputs
O(n) and O(n²) algorithms always have exactly identical running times regardless of how large the input size becomes
Quadratic time algorithms always run faster than linear time algorithms as input size increases, the reverse of the actual relationship
The specific Big O classification of an algorithm has no bearing on how well it scales to larger input sizes
13. Why might a program using an array-based data structure need to allocate more memory than currently required, anticipating future growth, while a linked list doesn't face this same issue?
Arrays are typically stored in one contiguous block of memory, so resizing can require allocating a new, larger block, whereas a linked list can simply attach new elements wherever memory is available
Arrays and linked lists always handle memory allocation and growth in exactly the same way with no meaningful difference
Linked lists require exactly the same kind of upfront memory allocation planning as arrays do
The way a data structure is stored in memory has no bearing on how it needs to handle growth or resizing
14. Why might an algorithm with better Big O performance sometimes still run slower in practice on a small data set than a "less efficient" one?
Big O describes scaling behaviour as input grows large, so for very small inputs, other factors (like simpler overhead) can outweigh theoretical efficiency advantages
Big O notation always perfectly predicts an algorithm's actual real-world running time on any and every data set size
An algorithm with better Big O performance is always faster in every single practical situation with no exceptions
Real-world performance on small data sets has no genuine connection to how Big O notation is used or interpreted
15. Why does searching an unsorted list of a million items potentially require checking all million items, while a sorted list allows binary search to find an item in only about 20 comparisons?
Binary search exploits the sorted order to repeatedly eliminate half of the remaining possibilities, whereas an unsorted list provides no such structure to narrow the search efficiently
Sorted and unsorted lists always require exactly the same number of comparisons to find a specific item
Binary search provides no genuine efficiency advantage over checking every single item in an unsorted list
The order of items in a list has no bearing on how efficiently a specific item can be located within it
16. Why might choosing an inefficient data structure for a large-scale, real-world application (like a social media platform with millions of users) cause serious practical problems, even if it works fine during small-scale testing?
Inefficiencies that are negligible at a small scale can become severe bottlenecks affecting speed and cost as data volume grows to real-world scale
Data structure choice never actually matters for large-scale applications, only for very small testing scenarios
An inefficient data structure always performs identically regardless of whether an application is being tested at a small or large scale
Real-world applications with millions of users are never actually affected by the specific choice of data structure used
17. Why might a software engineer need to weigh trade-offs between different data structures (like faster access versus more efficient memory use) rather than assuming one is always universally "best"?
Different data structures excel at different operations, so the most appropriate choice depends on the specific requirements and priorities of a given task
One single data structure is always objectively and universally the best choice for absolutely every possible programming task
Data structures never actually involve any meaningful trade-offs between different performance characteristics
The specific requirements of a programming task have no bearing on which data structure would be the most appropriate choice
18. Why might a hash table (a data structure using a function to map keys directly to storage locations) allow for extremely fast lookups compared to searching through an unsorted list?
A hash function calculates roughly where an item should be stored, allowing near-direct access rather than needing to check items one by one
Hash tables always require checking every single stored item one by one, identically to searching an unsorted list
Hash functions provide no genuine advantage in locating data compared to a simple, unsorted list
The specific method used to organise and locate data within a structure has no bearing on lookup speed
19. Why might a recursive algorithm (one that calls itself to solve smaller versions of the same problem) be a natural fit for a problem like navigating a tree-shaped data structure (like a file system with nested folders)?
A tree structure is naturally self-similar at every level (each folder can contain more folders), matching how recursion repeatedly applies the same logic to progressively smaller sub-problems
Recursive algorithms are never actually suitable for working with tree-shaped or hierarchical data structures
Tree-shaped data structures like nested folder systems have no genuine structural similarity to how recursion operates
Navigating a nested folder system always requires a completely different algorithmic approach than recursion could ever provide
20. Why might choosing an appropriate sorting algorithm matter significantly for a system that regularly sorts very large data sets, even if multiple algorithms would eventually produce the same correctly sorted result?
Different sorting algorithms have very different Big O time complexities, so the wrong choice could make sorting large data sets impractically slow even though the final sorted output would be identical either way
All sorting algorithms always take exactly the same amount of time to sort a data set regardless of its size
The specific sorting algorithm chosen has no bearing on performance as long as it eventually produces a correctly sorted result
Sorting algorithm choice only ever matters for very small data sets, never for large-scale, real-world systems
21. Understanding data structures and algorithms mainly helps you to:
Choose and evaluate efficient ways to organise data and solve computational problems as scale increases
Assume all data structures perform with exactly identical efficiency regardless of the task
Ignore how algorithm efficiency scales as input size grows larger
Treat data structure choice as irrelevant to a program's real-world performance
Answer key (parent copy)
1. A specific way of organising and storing data
2. An ordered, indexed list
3. Last-in-first-out order
4. First-in-first-out order
5. How an algorithm's runtime or memory use grows with input size
6. A chain of connected elements
7. A program's efficiency
8. A linked list can adjust connections between nearby elements directly, while an array often needs to shift many other elements to make room or fill a gap
9. The most recently performed action needs to be the first one undone, which matches exactly how a stack retrieves its most recently added item first
10. Print jobs are typically expected to be processed in the order they were submitted, matching exactly how a queue releases its earliest added item first
11. It describes how each algorithm's performance scales as input size grows, revealing which approach remains efficient for genuinely large, real-world data sets
12. An O(n) algorithm's running time grows proportionally with input size, while an O(n²) algorithm's running time grows much faster, becoming a significant problem for large inputs
13. Arrays are typically stored in one contiguous block of memory, so resizing can require allocating a new, larger block, whereas a linked list can simply attach new elements wherever memory is available
14. Big O describes scaling behaviour as input grows large, so for very small inputs, other factors (like simpler overhead) can outweigh theoretical efficiency advantages
15. Binary search exploits the sorted order to repeatedly eliminate half of the remaining possibilities, whereas an unsorted list provides no such structure to narrow the search efficiently
16. Inefficiencies that are negligible at a small scale can become severe bottlenecks affecting speed and cost as data volume grows to real-world scale
17. Different data structures excel at different operations, so the most appropriate choice depends on the specific requirements and priorities of a given task
18. A hash function calculates roughly where an item should be stored, allowing near-direct access rather than needing to check items one by one
19. A tree structure is naturally self-similar at every level (each folder can contain more folders), matching how recursion repeatedly applies the same logic to progressively smaller sub-problems
20. Different sorting algorithms have very different Big O time complexities, so the wrong choice could make sorting large data sets impractically slow even though the final sorted output would be identical either way
21. Choose and evaluate efficient ways to organise data and solve computational problems as scale increases