What Is a Data Structure?
Data structures are containers that organize data in specific ways. Each one has strengths and trade-offs.
What Is It?
A data structure is just a way to organize data. That's it.
Every data structure you'll ever use is a container with rules about how data goes in, how it comes out, and how it's arranged inside.
But here's the key insight: there is no single best data structure. Different problems need different containers. Looking up a word in a dictionary needs a different container than managing a print queue. The container you choose determines how fast your code runs — and sometimes the difference is between milliseconds and hours.
This course is about building data structures from scratch. You won't just use them — you'll write them yourself. That's what takes you from memorizing buzzwords to actually understanding what's going on.
Analogy
The Kitchen Analogy
Imagine you just moved into a new kitchen and have 200 items to store: plates, spices, utensils, canned goods, cleaning supplies.
You could throw everything into one giant pile on the counter. All your items are technically stored. But finding the paprika means digging through everything — every single time.
Instead, you use different containers based on how you'll use things:
- A stack of plates — you always grab from the top and add to the top. You never dig to the middle. This is a stack.
- A spice rack — each slot is labeled and you jump directly to "paprika" without scanning. This is like a hash map.
- A queue at a deli counter — first person in line gets served first. This is a queue.
- A bookshelf — items side by side in numbered positions. Slot 1, slot 2, slot 3. You can jump to any slot instantly. This is an array.
- A chain of paperclips — each one is connected to the next. To reach the fifth one, you follow the chain from the first. This is a linked list.
The items are the same. The containers are different. The choice of container determines how fast you can do what you need.
Try It Yourself
How It Works
Why So Many Data Structures?
Every data structure makes a trade-off. Here are the main tensions:
- Fast reads vs. fast writes. Arrays let you read any element instantly, but inserting in the middle is slow — you have to shift everything over. Linked lists let you insert anywhere quickly, but reading the nth element is slow because you must walk the chain.
- Memory vs. speed. A hash map uses extra memory to give you near-instant lookups. An array uses minimal memory but may require scanning.
- Sorted vs. unsorted. Keeping data sorted makes searching fast. But it makes inserting slow — you have to maintain the order. Unsorted data is quick to insert but slow to search.
- Simple vs. complex. A stack only supports two operations — but those operations are extremely fast. A binary search tree supports many operations, but the code is more involved.
The Structures We'll Build
Here's a roadmap of every data structure we'll implement from scratch in this course:
Sorting and Searching
For each one, we'll answer: How is it stored in memory? What operations does it support? How fast are those operations? When should you use it?
Two Fundamental Categories
At the core, all data structures fall into two camps based on how they use memory:
Contiguous Structures
Elements sit side by side in memory
arrays, strings
Linked Structures
Elements scattered in memory, connected by pointers
linked lists, trees, graphs
Contiguous structures are fast to read because you can calculate exactly where any element is. Linked structures are flexible because they can grow and shrink without moving existing elements.
Examples
Example 1: Choosing the right structure
Problem: You need to store a playlist of songs that users can add to, remove from, and play in order.
- An array makes playing in order fast (go index by index), but removing a song from the middle means shifting everything after it.
- A linked list makes removal fast (just re-link the neighbors), but jumping to the 50th song means walking through 49 nodes.
- A doubly linked list gives you efficient removal AND the ability to go forward and backward.
Example 2: The operations matter
Problem: You're building an autocomplete feature. As the user types, you need to find all words that start with a given prefix.
- A sorted array could use binary search to find the start of the prefix range — decent.
- A hash map gives instant lookup for exact words, but it can't find prefixes efficiently.
- A specialized tree structure built for prefix matching is purpose-built for this exact problem.
The right structure isn't about the data — it's about the operations you need to perform on it.
Example 3: Same data, different structures, different speeds
Suppose you have 1,000,000 user records and need to find user #742,891.
Same data. Same question. Wildly different performance.
Common Mistakes
- Thinking one data structure is always best. Beginners often learn about hash maps and try to use them for everything. Hash maps are great for key-value lookups but terrible for finding the minimum element or anything involving ranges.
- Ignoring the actual operations you need. Before picking a data structure, list the operations your program will perform most. If you're constantly searching, optimize for search. If you're constantly inserting, optimize for insertion.
- Forgetting about memory. A hash map might be faster than a sorted array for lookups, but it uses significantly more memory. For large datasets, that matters.
- Thinking using = understanding. Knowing that "a stack is LIFO" is not the same as understanding how a stack is built and why push/pop are fast. This course exists to bridge that gap.
Best Practices
- Before picking a data structure, list the operations you need (insert, delete, search) and how often each one happens
- Every data structure gives you something and costs you something else — always ask what the trade-off is
- When in doubt, start with the simplest structure (usually an array) and only switch when you can explain why it's too slow
- Build each structure from scratch at least once — actually writing the code cements understanding in a way that reading never will