There's a comfortable trap that experienced engineers fall into: you get good at your tools, your frameworks, your domain — and the fundamentals you never deeply internalised quietly accumulate as gaps. Algorithms and data structures were one of those gaps for me.
Not that I couldn't do the work. Years of building backend systems, databases, APIs — you learn a lot on the job. But there's a difference between knowing that a HashMap gives you O(1) lookup and truly understanding why, when it breaks down, and what to reach for instead.
Why Bother as a Senior Engineer?
A few reasons pushed me to do this properly:
- Interviews — even senior roles at top companies test algorithms. Whether you like it or not, it's the game.
- System design — the right data structure choice can be the difference between a system that scales and one that crawls at load.
- Code review — recognising when a junior's nested loop could be a hash join, or when a list should be a tree, requires solid foundations.
- Personal standard — there's something uncomfortable about not being able to explain Big O to your own team.
The Roadmap
Over the coming months I'll be working through and writing about:
Data Structures
- Arrays, Linked Lists, Doubly Linked Lists
- Stacks and Queues
- Hash Tables — collision strategies, load factors
- Trees — BST, AVL, Red-Black
- Heaps and Priority Queues
- Graphs — adjacency list vs matrix, directed vs undirected
- Tries
Algorithms
- Sorting — merge, quick, heap, radix and when to use which
- Searching — binary search, BFS, DFS
- Dynamic Programming — recognising the pattern, memoisation vs tabulation
- Greedy algorithms
- Graph algorithms — Dijkstra, Bellman-Ford, topological sort
Complexity Analysis
- Big O, Omega, Theta — what they actually mean
- Amortised analysis
- Space complexity — often overlooked
First posts in the series will start appearing from end of February once Java 8 certification is out of the way. Stay tuned.