How to Rock a Systems Design Interview

Obviously, this is marketing rather than a serious treatment of the topic. It seems to basically say: "in order to design a system, you should have a regular undergraduate Computer Science education" which seems maybe like a prerequisite (and maybe informative about their hiring process) but not very useful.<p>However, for what it's worth, the two best resources I've seen for systems design are:<p>Hints for Computer System Design: <a href="http://cseweb.ucsd.edu/classes/wi08/cse221/papers/lampson83.pdf" rel="nofollow">http://cseweb.ucsd.edu/classes/wi08/cse221/papers/lampson83....</a><p>How to Design a Good API: <a href="http://www.youtube.com/watch?v=aAb7hSCtvGw" rel="nofollow">http://www.youtube.com/watch?v=aAb7hSCtvGw</a><p>What else should be in this bibliography?

Most of what they want is exactly why I wrote lmbench, it measures latency and bandwidth of just about everything that you should care about.<p>One of our guys plotted the memory latency benchmark here:<p><a href="http://www.bitmover.com/mem_lat.jpg" rel="nofollow">http://www.bitmover.com/mem_lat.jpg</a><p>He shows you that and says "tell me everything you can tell me from this graph". It's usually a two hour conversation.

Designing systems well means understanding tradeoffs when you have choices. And these days you tend to have a lot of choices.<p>From what hardware you run to what software stack you use. A good systems architect will make these decisions on the fly.<p>To get better at designing systems you have to actually look at ones in practice. Especially ones you think are bad. Because often what led to that design was a series of tradeoffs. And systems design tends to run end to end. You have to think about not only speed and reliability but often ease of use.

Some of these system designs interview and algorithm interviews are just overrated. You are literally testing how much "alike"" this candidate is thinking like you do, which sometimes is not the right way to conduct an interview.<p>How many people remember the pseudo-code for quick sort right away? A true engineering test or interview should be done in coding tests and his/her ability to QA his/her own code, and explain it in a clear fashion.

Can anyone recommend a good reading on systems design? I'm already reading "Software architecture in practice".