When applying for jobs, you’ve probably seen posts that say “read the company blogs, look at their papers”. You’re probably thinking: “oh that’s cute, I’ll be aware if they ask me some questions about it”. Wrong! What they’ll actually ask you to do, is (re)-design and scale out those very systems that took them years to build.

What’s the reason for this madness? Well, think if you were conducting a senior-level design interview. What would you ask about? Perhaps something you are familiar with… Perhaps something your company has published papers on…

As I alluded previously, this becomes more important the more senior you get. In someways it makes sense, they want you to help lead the build and scale out of products, and this is their way to test that.

What resources are there?

Compared to studying up on algorithms and coding, there is hardly anything out there at all. The site interview bit has a few examples, as does Gayle’s book, though they are toy examples compared to the interviews I experienced. If you search really hard there are a few other blog posts as well.

This dearth of information got me wondering why Gayle’s otherwise wonderful book is lacking in the design area. There are a couple of questions, but certainly it’s not even one tenth the book, whereas it will be at least half your interview if you are senior.

Suddenly it came to me. According to LinkedIn, Gayle left Google before 3 years of post graduate experience. The reason her book does not cover many design questions, is that she could not have been at the level where it was expected to give that style of interview.

While I cannot claim to be an expert in this style of interview, i.e. I’ve not been in the 100s of interviews that Gayle has for algorithms; I’ve now been through enough to actually understand what I think they are asking about, and some tips on how to prepare for them.

So how to prepare for this?

I think the important areas for these design interviews are system fundamentals and scale-out architectures.

While it is unlikely you will be asked to write detailed code for these topics, you need at least be aware that they exist, if not able to design most of their algorithms and discuss trade-offs in some level of detail on a whiteboard.

Regardless of memorising all of these, reading them once for familiarity is probably a good idea. Remember, you will want to adjust what you are studying based on position.

Scale Out Architectures

This topic is a little painful for me, the scale-out distinction of scalability didn’t really exist when I graduated university, the focus was purely scale-up:

To scale vertically (or scale up/down) means to add resources to (or remove resources from) a single node in a system,

To scale horizontally (or scale out/in) means to add more nodes to (or remove nodes from) a system

The way to prepare is to read the fundamental papers, and understand how they scale-out. So lets pick a company to study; e.g. Google, of course.

Google has been completely revolutionary as a company for the computer science industry, by openly publishing papers of their technology, and allowing others to reproduce it (Hadoop) and build on top of the concepts (Spark?). Their big overview that you have to read is The Data Center As A Computer, then take a look at their original papers, and perhaps Yahoo!’s open source versions:

System Fundamentals

Most of these topics should have been covered during an undergraduate CS degree, so you should only need to revise them.

Microsoft Azure has published some very helpful infographics, detailing common cloud architecture patterns.

One last fundamental that is worth going over, is the 8 Fallacies of distributed systems.

Putting it all together

Time to use those back of the envelope skills…

No really! After understanding how these systems work, it’s critical to apply the numbers every engineer should know, so that you can design and estimate how to deploy a scale-out service. The service needs to meet your storage, throughput, and latency requirements; given your CPU, memory, disk, and I/O resources.

Remember that the shape of the system can be very different given different resources, while still achieving the desired metrics; though the goal is always the same, minimise the $$$ cost of the system.

If this all seems unfamiliar, you are not that alone. In a subsequent post, I’m going to describe a template about how think about and work through these problems, then as an exercise for myself, I will post about different scale-out systems with deployment examples.

References

If somehow you managed to do all of the above… then here are some engineering blogs worth reading for the latest developments:

  1. Don’t flame me here. ↩