Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Rock a Systems Design Interview

blog.palantir.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: How to Rock a Systems Design Interview

#11

Post by mrleinad »

scott_s wrote: post #8
mrleinad wrote: post #7

Earlier quoted context omitted.

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 back…

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.

Re: How to Rock a Systems Design Interview

#12

Post by 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.

Re: How to Rock a Systems Design Interview

#13

Post by basugasubaku »

socratic wrote: post #5

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 Syst…

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.

Re: How to Rock a Systems Design Interview

#14

Post by scott_s »

mrleinad wrote: post #11
scott_s wrote: post #8

Earlier quoted context omitted.

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 back…

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.

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?

Re: How to Rock a Systems Design Interview

#15

Post by jtchang »

luckydude wrote: post #4

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.

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.

Re: How to Rock a Systems Design Interview

#16

Post by luckydude »

jfoutz wrote: post #10
luckydude wrote: post #4

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.

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? Th…

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.

Re: How to Rock a Systems Design Interview

#17

Post by luckydude »

jtchang wrote: post #15
luckydude wrote: post #4

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.

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.

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.

Re: How to Rock a Systems Design Interview

#18

Post by Tuna-Fish »

jfoutz wrote: post #10
luckydude wrote: post #4

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.

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? Th…

> 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?

Re: How to Rock a Systems Design Interview

#19

Post by mrleinad »

scott_s wrote: post #14
mrleinad wrote: post #11

Earlier quoted context omitted.

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.

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?

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.

Post reply on HN