A strong answer
An array stores elements contiguously, so element i is at base + i × size: O(1) access, O(n) insertion or deletion in the middle because later elements shift, and amortized O(1) appends for a dynamic array. A linked list stores each element in its own node with a pointer to the next: O(n) access by position, but O(1) insertion or deletion once you hold the neighboring node.
In practice, arrays win almost every workload, for reasons Big-O hides. Scanning an array streams through memory: one cache miss per 64-byte line, and the prefetcher fetches ahead. Walking a list is a chain of dependent loads, each potentially a cache miss that can't overlap with the next. Every list node is a separate allocation with pointer and allocator overhead, often 24 bytes or more for a 4-byte integer. And the list's O(1) insertion usually comes after an O(n) walk to find the position, which is much slower for the list. Stroustrup's well-known experiment, inserting random numbers in sorted position, showed a vector beating a list at every size.
Linked lists are still the right choice when you already hold the node, so no search is needed (LRU caches, schedulers), when you splice whole sublists, when elements must keep stable addresses, for intrusive lists that avoid allocation (common in kernels), and as the basis of lock-free stacks and persistent functional lists. For queue-like use at both ends, a ring-buffer deque usually beats both.
What the interviewer is listening for
- The Big-O comparison, stated correctly, including "given the node" for list insertion.
- Cache behavior, allocation and memory overhead as the practical decider.
- Concrete cases where a list is the better tool.
Common mistakes
- Saying linked lists are better for frequent insertions without mentioning the cost of finding the position.
- Forgetting per-node memory overhead.
- Treating Big-O as the whole story.