
How to Rock a Systems Design Interview - regs
http://blog.palantir.com/2011/10/28/how-to-rock-a-systems-design-interview/
======
socratic
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....](http://cseweb.ucsd.edu/classes/wi08/cse221/papers/lampson83.pdf)

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

What else should be in this bibliography?

~~~
basugasubaku
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.

------
luckydude
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
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.

~~~
luckydude
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.

------
jtchang
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.

------
traveldotto1
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.

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

~~~
jchonphoenix
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.

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

~~~
scott_s
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?)

~~~
mrleinad
I'm a Systems' Engineering student, almost finished my career. I'm working
full time already, and my job involves programming and design as well, but I
want to learn more and improve my skills. I have some time to hack on the
side, but not so much, since I'm trying to wrap up everything related to my
career at the moment.

~~~
scott_s
You mean your career as a student? Have you taken any CS courses? (It's okay
if you haven't, it's just an easy way for me to know what you know.) What kind
of programming and design do you do at your job?

~~~
mrleinad
Yes, sorry. I meant that I'm close to getting my degree, and I'll be a
system's engineer (that's what's going to be printed on my diploma). The
entire degree is based on CS courses, so yes, I got my share of them.

Although we have two courses on System's design and System's engineering,
teachers here are not very good, and I feel I didn't learn almost anything
from them. That's why I want to read more about it and really improve my
skills there.

At my daily job I work on several short-time projects, using MS technologies.
Sometimes I code .NET, do some basic design for an application, but nothing
really big. I don't stop and think about scalability, performance, etc. Those
things usually come unannounced later when the application starts to fail in
some environments. So, you can see, I'd benefit from learning more about
System's design.

