An Infinite Ocean of Knowledge (My Path to SRM)

Overwhelmed with the sheer amount of books, articles, and papers to read, a myriad of talks and videos to watch, and an ever-increasing number of things to learn I almost gave up. I was frustrated by the chaos that I have created out of open tabs, bookmarks, handwritten notes, and stacks of books on my desk. Instead of motivating and inspiring me the massive amount of available data had a chilling effect on me. It was time for reflection!

My growing island of knowledge

I figured that there were three components in my learning equation. The seemingly infinite ocean of available knowledge which is unknown to me. These were my “unknown unknowns”. Then there was my starting point of things I knew, my “knowledge”. Let’s think of knowledge as an island somewhere in the ocean of unknowns. The coastline of this island is where I knew there was more stuff to learn. Knowing that there are so many things I did not know about was intimidating and demotivating.


Let me give you an example: I knew that multiple CPU architectures existed. I was quite familiar with an older Infineon chip and the x86 architecture. This was all comfortably sitting on my island of knowledge. Closer to the coastline were some facts I remembered about ARMv7. Something close to my island but I would need to extend the coastline a little bit to claim that piece of land from the ocean of unknown. I also had a bookmark about OpenRISC, so while this architecture was pretty unclear to me I knew where to start to make it part of my island as well.

The interesting part is what happened when I rapidly grew my island of knowledge. The more I learned the less educated I felt. I learned about a new technology, a different approach to a well-understood problem, a crazy programming language leveraging unconventional concepts.


This all grew my island but at the same time made my coastline longer. Being aware of even more “unknowns” made me feel stupid. Everything on my coastline seemed interesting, relevant, and a must-learn before interviewing. Although I was moving forward towards my goal it felt like moving away from it faster and faster. It was time to break the vicious circle! I was in need for a more structured approach.

A method to structure the curriculum

The first thing I did was to acknowledge that I will never be able to learn all the things. I would discover more interesting topics than I would ever be able to focus on. My only way out of that dilemma was to prioritize. It became clear to me that I learned most about a fresh topic when applying the new knowledge to a problem. Discovery along the way was a wonderful yet dangerous issue. I wanted to avoid going too deep down the rabbit hole and thus ignoring other important topics. On the other hand, discovering new topics and fresh aspects is an important part of learning and curriculum building. My solution to this was that I allowed myself to quickly dive into an interesting topic as it came up. After about five minutes I would stop investigating further and add the topic or link at the end of my curriculum. My curriculum was growing every day.

Once a week I would go over the curriculum and remove the topics that I sufficiently worked on. The rest would be subject to rigorous prioritization. I would match the topics against the role description to find out which were the most important to work on. I also tried to strike a balance between the different interview types I expected. It’s no use becoming a coding expert but missing out on troubleshooting topics. That said, between the first recruiter screening call and the phone interviews I gave more attention to coding and management. Mostly because I knew these two topics would be part of the first round of interviews.

small After initially discovering topics I weekly re-prioritized my curriculum while it was fed with new items during the learning and application phases.

Prioritization took some time but it was absolutely worth it! Often the topics that I felt the least comfortable with made it to the top of the list. Without prioritization they would probably have been skipped over time and again. There would have been a blank spot in my knowledge. Or, if you like to stay with the metaphor, a lake within my island.

A worked example

Let me share a concrete example of how I applied the four phases to my coding interview curriculum. Prepare for some lightweight graph theory. 🙄

Initial discovery

For the initial discovery phase I browsed websites full of coding questions and tried to find out which types of questions would repeat often. I also read Computer Science Distilled by Wladston Ferreira Filho. I liked that book because it is not offering much in-depth discussion. This made it perfect to get an overview and occasionally find a knowledge gap.

High-level books like “Computer Science Distilled” or the famous SRE book are full of keywords and pointers to topics that are worth looking into.

For example, I wasn’t remembering having ever heard of the knapsack problem. The knapsack problem consequently made it onto my list. I also figured out that for most problem classes and algorithms I never went beyond reading pseudo code implementations. Implementing at least a few of those myself, like breadth-first and depth-first searching on a graph, seemed important and resulted in further items for my growing list.


After a couple of days of discovering about a hundred interesting topics for ramping up my coding learnings I went thorugh the prioritization phase. I reserved time in my calendar for learning sessions for the following week. That was my upper resource limit. Then I had to fill the available time with the most valuable topics first. A topic was valuable if it was something that would provide me an advantage in an interview setting. That is, going into the implementation details of partition schemes for quicksort is less valuable than knowing the tradeoffs of common sorting algorithms. I did allow a bit of time at the end as buffer. Filling my calendar slots starting with the most valuable topics first was, by the way, a knapsack problem. See what I did here?


Most of the basic algorithms and problem solving techniques are discussed in the book Cracking the Coding Interview by Gayle Laakmann McDowell. Some of the less popular details, e.g. the aforementioned partition schemes of quicksort, are documented on Wikipedia. The online coding platform HackerRank is also a great place to learn about a particular topic. The neat thing about online coding platforms is that they often come with challenging tests and edge cases which are run by an automated grading systems. I found that feedback to be very useful in determining if I had still a rough or already a good understanding regarding a topic or algorithm. Another great site for getting lost in interesting implementation discussions is Geeks for Geeks.

Most of the mentioned resources have curated courses especially for interview training for those who chose not to compile their own weekly curriculum.


When I applied my learnings to a path finding task I came across the topic of topological sorting in directed graphs. An unexpected discovery that I added to the list for the next prioritization round. Eventually I would find a suitable time slot for it and learn and implement topological sort. Every time I applied my learnings to a problem my awareness and understanding of the underlying topic grew. Over time I became more confident in picking the right approach to a coding problem and was quite comfortable talking about the tradeoffs of competing approaches.

Since the overall goal is providing signal in an interview setting I had to throw myself into that situation as realistically as possible. For starters, I bought a huge whiteboard and solved interview questions from books and online forums on the whiteboard. I had a timer running and mumbled to myself as if I were communicating with an interviewer. That felt awkward in the beginning, especially when my girlfriend was in the same room. After a while we both got used to me mumbling and techno-babbling. A small confidence boost!

Being whiteboard-interviewed by expert interviewer Polarbärli on breadth-first searching an undirected graph.

Another great way of applying knowledge was to have mock interviews. Since I had no one who could mock interview me I paid for online mock interview sessions. There are plenty of providers out there and not all of them are worth the money. For example, some just connect two learners with each other. This is missing the point of applying the knowledge with a trained interviewer present. While I don’t feel comfortable recommending any provider, I have to say that I have received excellent service and was asked unique questions at TechMockInterview. Your mileage may vary.


Preparing for Google interviews can be a challenging task due to the many topics that must be covered. Disciplined prioritization and thoughtful planning helped me grow my island of knowledge without jeopardizing my morale as I discovered that there is so much that I didn’t know. Getting out of the comfort zone and applying my learnings in an interview-like setting was a crucial step. Only knowledge that has been applied and can be communicated is likely to create a positive signal during an interview.

Further Reading

🔬 Experimental Feature: Subscribe here to receive new articles via email! 🔬