Data Structures

Ask why a program uses a linked list instead of an array and the honest answer is usually a trade-off, not a rule: an array gives constant-time access to any element by index but is expensive to resize or to insert into the middle of, while a linked list makes insertion and removal cheap but forces a linear walk just to reach the fifth element.

That kind of trade-off, not memorizing definitions, is really what data structures as a subject is about. A typical course moves from arrays and linked lists (singly and doubly linked) into stacks and queues, then into trees, where binary search trees introduce the idea of maintaining sorted order efficiently, and finally into hash tables and graphs, which tend to be where students hit the steepest learning curve because the mental model stops being a simple line of boxes.

Hash tables in particular cause recurring confusion — students often treat them as a black box that's "just fast" without understanding collision handling or why a poorly chosen hash function degrades performance toward the same worst case as a plain list. Tree traversal (in-order, pre-order, post-order, breadth-first) is another common sticking point, mainly because recursion and traversal order both need to click at once.

A tutor working on data structures with a specific student usually starts from whichever structure is causing the actual course or assignment trouble, then connects it back to the underlying trade-offs — time complexity for common operations, memory overhead, whether order needs to be preserved — since those trade-offs are what most exam and interview questions are really testing, more than syntax for a particular language's implementation.