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

A senior engineer's guide to the system design interview

interviewing.io

Post reply on HN
Print view View original

81–90 of 399 posts

Re: A senior engineer's guide to the system design interview

#81

Post by rednerrus »

operatingthetan wrote: post #72
rednerrus wrote: post #49

Earlier quoted context omitted.

We call this out in our pre-interview handout. If you've got an NDA, choose something that isn't included in your NDA or figure out a way to describe it at a high level. We caution candidates that if we dig in and we run into something blocked by the NDA it creates challenges with our evaluation. It doesn't necessarily have to be something that you're working on. It just has to be something that you understand well e…

>We caution candidates that if we dig in and we run into something blocked by the NDA it creates challenges with our evaluation. So you're penalizing those under NDA and unecessarily limiting your candidate pool.

There’s no penalty. There are plenty of technologies that you’re working with that aren’t under NDA. We’re not asking you to diagram what you’re working on, we asking you to diagram something technical that you understand well.

Re: A senior engineer's guide to the system design interview

#82

Post by ed25519FUUU »

> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt.

As someone who has conducted countless interviews at a FANG, I can not stress this point enough. The ability to just talk about a problem makes a big difference between a mediocre interview and a great interview. Besides, it's what makes an interview fun or lame.

Re: A senior engineer's guide to the system design interview

#83

Post by jeron »

coolspot wrote: post #80
mgraczyk wrote: post #53

I am on the interviewer side of ~1 system design interview per week and have done probably around 100 of them at Google and other companies. Most of the advice here is good, although it could be condensed quite a bit. The biggest red flag for me as an interviewer is when candidates list off concepts or technologies they don't understand. DO NOT say things like "we can't do this because of the CAP theorem" or "we shou…

> DO NOT say things like "we should add a cache to reduce latency” We should add a cache to reduce latency tho…

yeah, not sure what is too hard to understand about that. Perhaps it depends on the context but I highly doubt you can go wrong by saying a cache should be added to reduce latency.

Re: A senior engineer's guide to the system design interview

#84

Post by dakiol »

wholinator2 wrote: post #79
siva7 wrote: post #56

Earlier quoted context omitted.

I hear the "Why are books important" pretty often when guiding developers. All of the best architects i know of spend much time honing their skills. That won't happen if all you see is just the company you're working at. The worst architects i've worked with stopped learning outside of their job tasks. It's also a step to understand that design patterns and system design are all within the core competency of the seni…

While I'm sure that the best employees make their entire lives about work skills, I just can't imagine that being a fulfilling life personally. If i have to spend my nights reading books about work, outside of work, then I don't want to be the best. I have other hobbies I'm more interested in than, "becoming a better employee". Now, I do feel different about academia though. I could understand doing fundamental resea…

> I just can't imagine that being a fulfilling life personally. If i have to spend my nights reading books about work, outside of work, then I don't want to be the best. I have other hobbies I'm more interested in than, "becoming a better employee".

I'm the guy who reads books about my career (not about my work) outside of work (in my free-time) and during working hours as well. I love my career (computer science) and I love reading well-known tech/cs books. I don't do it to be the "best employee". I couldn't care less about what I do at work (I, like 99% of the people here, work for a totally useless tech company that nobody would care about if it disappeared tomorrow). What I do at work is stupid distributed systems in Go + Kafka + postgres + k8s (totally uninteresting stuff, but pays very well though). I genuinely enjoy readings books from Stevens, Kerrisk, Kleppmann, etc., just like I enjoy reading sci-fi/drama/etc. novels. I usually end up learning stuff that's actually useful at work, and once in a while I apply such knowledge at work, but I do it only for the raises and promotions.

There are people out there who doesn't give a fuck about tech companies, but care deeply about tech.

Re: A senior engineer's guide to the system design interview

#85

Post by rednerrus »

cyc116 wrote: post #63
sroussey wrote: post #50

Earlier quoted context omitted.

Your ideas of what should be secret or not may not at all be what the candidate agreed to in their employment contract and NDA.

Exactly. Not to mention high level business logic could be inferred from system architecture. Sure sounds like a good way to perform recon on a target company.

We say specifically “diagram a technical system you understand well.” It’s going to be challenging to work in technology if the only technical system you understand well is the one you’re currently working on and only the parts that are under NDA.

Re: A senior engineer's guide to the system design interview

#86

Post by dakiol »

ed25519FUUU wrote: post #82

> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt. As someone who has conducted countless interviews at a FANG, I can not stress this point enough. The ability to just talk about a problem makes a big difference between a mediocre interview and a great interview. Besides, it's what makes an interview fun or lame.

Problem is: as candidate you don't know if "engaging in a back-and-forth conversation about problem constraints" is something the interviewers want. Some interviewers want it, but it's not always like that. And, no, usually discarding an entire company just because the interviewer on duty doesn't like "engaging" is BS.

Re: A senior engineer's guide to the system design interview

#87

Post by Salgat »

rednerrus wrote: post #81
operatingthetan wrote: post #72

Earlier quoted context omitted.

>We caution candidates that if we dig in and we run into something blocked by the NDA it creates challenges with our evaluation. So you're penalizing those under NDA and unecessarily limiting your candidate pool.

There’s no penalty. There are plenty of technologies that you’re working with that aren’t under NDA. We’re not asking you to diagram what you’re working on, we asking you to diagram something technical that you understand well.

Being able to use something you've intimately worked on as part of your job is a huge advantage since you're so familiar with it.

Re: A senior engineer's guide to the system design interview

#88

Post by pcthrowaway »

blowski wrote: post #77
zinclozenge wrote: post #45

Earlier quoted context omitted.

Square/Block (used to?) ask only 1 system design question and the recruiter would let you know ahead of time so you could prepare for it. Probably because it allows for deeper questioning and answering of relevant technical skills.

It’s hard to tell between those who know their stuff, and those who are good at memorising all the various courses that tell you what to say. By telling the candidate what system to design you make the latter’s job easier.

If someone can quickly learn enough about a system that they can convince a domain expert they understand it well in a deep technical discussion, they're probably a good candidate for hiring, since your business likely consists of many complex systems, and the candidate will theoretically be able to onboard faster.

Re: A senior engineer's guide to the system design interview

#89

Post by N_A_T_E »

jeron wrote: post #83
coolspot wrote: post #80

Earlier quoted context omitted.

> DO NOT say things like "we should add a cache to reduce latency” We should add a cache to reduce latency tho…

yeah, not sure what is too hard to understand about that. Perhaps it depends on the context but I highly doubt you can go wrong by saying a cache should be added to reduce latency.

Only two hard things in computer science, blah blah.

Re: A senior engineer's guide to the system design interview

#90

Post by gilbetron »

coolspot wrote: post #80
mgraczyk wrote: post #53

I am on the interviewer side of ~1 system design interview per week and have done probably around 100 of them at Google and other companies. Most of the advice here is good, although it could be condensed quite a bit. The biggest red flag for me as an interviewer is when candidates list off concepts or technologies they don't understand. DO NOT say things like "we can't do this because of the CAP theorem" or "we shou…

> DO NOT say things like "we should add a cache to reduce latency” We should add a cache to reduce latency tho…

If you need to reduce average latency and the cache would actually do that, sure. Cache doesn't magically make all your network latencies drop, though.
Post reply on HN