How to Rock a Systems Design Interview
blog.palantir.com
How to Rock a Systems Design Interview
1–10 of 19 posts
Re: How to Rock a Systems Design Interview
#2Designing 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.
Re: How to Rock a Systems Design Interview
#3Can anyone recommend a good reading on systems design? I'm already reading "Software architecture in practice".
Re: How to Rock a Systems Design Interview
#4Most 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.
Re: How to Rock a Systems Design Interview
#5Obviously, 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?
Re: How to Rock a Systems Design Interview
#6Can anyone recommend a good reading on systems design? I'm already reading "Software architecture in practice".
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.
Re: How to Rock a Systems Design Interview
#7Can anyone recommend a good reading on systems design? I'm already reading "Software architecture in practice".
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.
Really, I wouldn't know where to start. I think that approach would be unfeasible to almost anyone.
Re: How to Rock a Systems Design Interview
#8Earlier quoted context omitted.
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.
Really, I wouldn't know where to start. I think that approach would be unfeasible to almost anyone.
Your response is valid, as I think the suggestion was too aggressive. But I do endorse (what I think is) his main point: understanding how to design systems comes from working on them, not reading about them. So it's better to work on problems than to read about them.
More specific advice depends on what your background is and what you're doing now. (For example, are you a student? A CS student? How much of a CS background to you have? Are you working full-time? If so, does your job involve programming? Do you have time to hack on the side?)
Re: How to Rock a Systems Design Interview
#9Can anyone recommend a good reading on systems design? I'm already reading "Software architecture in practice".
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.
Re: How to Rock a Systems Design Interview
#10Most 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.
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.