How to Rock a Systems Design Interview

http://blog.palantir.com/2011/10/28/how-to-rock-a-systems-design-interview/

by regs • 15 years ago

75 18 15 years ago

blog.palantir.com

jtchang2• 15 years ago

Designing systems well means understanding tradeoffs when you have choices. And these days you tend to have a lot of choices.

From what hardware you run to what software stack you use. A good systems architect will make these decisions on the fly.

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.

mrleinad4• 15 years ago

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

jchonphoenix• 15 years ago

This is probably the most painful way to learn this, but I'd recommend writing your own highly concurrent kernel from scratch.

Once you've done that, you'll understand a ton about how to think and how design decisions will affect you later on.

mrleinad4• 15 years ago

Really, I wouldn't know where to start. I think that approach would be unfeasible to almost anyone.

hello_moto• 15 years ago

This one is tough and I would love to be able to learn more from a mix of reading + assignments as well.

There are several books I would recommend:

1) Database Design and Implementation by Edward Sciore:

http://www.wiley.com/WileyCDA/WileyTitle/productCd-EHEP00071...

This book teaches RDBMS from conceptual perspective up to implementing your own RDBMS (using Java albeit).

2) OS Design XINU Approach (look for the PC edition)

http://www.amazon.com/Operating-System-Design-XINU-Approach/...

3) Bunch of UNIX/Linux books

- The Design of the UNIX Operating System (M. Bach)

- Design and Implementation of BSD 4.4/FreeBSD 5.2

Unfortunately I don't think jumping to the most recent Linux kernel books would be feasible.

4) Look for any books that teaches both concepts and provide simple implementation of the said concepts.

For example:

http://www.amazon.com/Definitive-Guide-SQLite-Experts-Source...

Find a book that teaches the concept of Graphics Pipeline and try to implement it yourself: http://www.viznet.ac.uk/files/d39pipeline.gif

5) Check out the Java SDK (the actual implementation, not how to use the library) and HotSpot VM guides

- Concurrent, NIO/IO, Networking, Threading

- Garbage Collection, optimization, Class Loading, etc

I think the more you learn, exercise, and understand many system designs out there could help you to build your own "intuition" in the future.

luckydude3• 15 years ago

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.

One of our guys plotted the memory latency benchmark here:

http://www.bitmover.com/mem_lat.jpg

He shows you that and says "tell me everything you can tell me from this graph". It's usually a two hour conversation.

jfoutz• 15 years ago

Wow. So, less than 300k or so and you stay in L1, which is crazy fast. Contiguous reads must have some trick for streaming into L1 in anticipation of the request. The only explanation i have for the large stride/large read speedup is maybe you're laying out data in separate memory modules so you get some parallel reads. I guess that curve from 8b to 4kb comes from increasing collisions? Is this even vaguely right?

That's a cool graph.

luckydude3• 15 years ago

I think you might stare at it some more. You can puzzle out L1 size, L1 associativity, L1, L2, main memory latency, the cost of a TLB miss and probably a bunch of other stuff I've forgotten.

Tuna-Fish• 15 years ago

> Wow. So, less than 300k or so and you stay in L1, which is crazy fast.

Look at the colors again. L1 is ~12KB or less. 300kbish is probably L2.

I tried hard to recognize the CPU from the graph, and failed. Any help?

jtchang2• 15 years ago

What is sad is that if you were to plot, say hard drive access times, on the same chart and just adjust the axis you'd realize that memory latency is orders of magnitude faster than any hard drive access.

All those access times are nanoseconds. Traditional hard drives are usually in the 4-8 millisecond range. Even SSDs clock in at around .2 milliseconds...which is 200,000 nanoseconds.

luckydude3• 15 years ago

Take a trip through lmbench results, it's worthwhile. You'll get bandwidth and latency of disks, file systems, network, memory, as well as context switch costs.

It's a tiny set of tests and if you memorize the results you can sit in any design session, decompose a problem into the basic events, and prove that the design can or can not work in short order.

socratic• 15 years ago

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.

However, for what it's worth, the two best resources I've seen for systems design are:

Hints for Computer System Design: http://cseweb.ucsd.edu/classes/wi08/cse221/papers/lampson83....

How to Design a Good API: http://www.youtube.com/watch?v=aAb7hSCtvGw

What else should be in this bibliography?

basugasubaku• 15 years ago

That's not what the article says at all. In fact, a CS education is likely not good enough. There are plenty of new graduates who do not know much about, e.g., IPC or have a good feel for real world performance numbers. The article rightly recommends working on actual systems including OSS projects.

traveldotto1• 15 years ago

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.

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.

How to Rock a Systems Design Interview

Related Stories