A few days ago my wife and I visited the Teide Observatory on the volcano island of Tenerife. We learned about the donkey’s belly cloud-blocking weather phenomenon that makes the Teide national park the perfect place for stargazing. Yesterday, after sunset, we jumped into our tiny rental car and drove into the Teide crater for some astrophotography.

I was a bit surprised by how thoroughly Google tested my management and leadership skills. Three out of the eight interviews were about management and leadership. That gave me a strong hint that these interviews are similarly important to Google as the technical interviews. I had to reflect about my past leadership experiences in the army, about management in non-profit organizations and my team leading in the realm of event management. I also had to think about how I approached education (which I am passionate about), coaching and mentoring. If I wanted to demonstrate those skills in an interview I knew, I’d better have my story straight and be aware of what I am and am not good at.

Unfortunately, Non-abstract Large System Design (NALSD) is a lesser known concept to most of the engineering world. When I started preparing for the NALSD interview I found resources on pure NALSD to be rare. Therefore, I primarily used the traditional system design wisdom to prepare for this type of interview. I found tons of material on traditional system design and respective interview questions including recorded mock interview sessions. I used those resources to get a better understanding of how distributed systems are designed nowadays. Upon that I built an understanding for NALSD by attaching realistic numbers to the abstract designs I read about.

I found the troubleshooting interview preparation to be one of the more fuzzy ones. The first question I asked myself was: What is Troubleshooting anyway?

Cleverly combining talking to my recruiter with sophisticated Intawebz research I came up with the following definition:

Troubleshooting in the context of interviewing is the ability to approach problem solving in an educated, logical, and structured way. It requires communicating by sharing thoughts and ideas with the interviewer while working through a (potentially networked) distributed system scenario.

At first I was overwhelmed by the sheer amount of topics and learning opportunities. From free videos on YouTube with varying quality to paid courses offering a thoughtful curriculum. Out of the many structured and well-designed learning paths towards coding interviews I had to choose one or two. The secret was to follow one or maybe two of them and not waste time jumping back and forth between tens of different curricula. Sometimes it is better to trust that the author put some serious thought into compiling a suitable learning path.