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

251–260 of 399 posts

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

#251

Post by InitialLastName »

projectazorian wrote: post #244
zbuf wrote: post #128

Earlier quoted context omitted.

It's a reasonable hurdle; an employee who previously signed an NDA (or any one, for that matter) needs to be able to design new systems without regurgitating verbatim parts of an old one under NDA. So it's really not a big ask to navigate their own NDA and come up with something interesting to talk about at an interview.

I’m going to be way more strict about confidentiality with an interviewer I don’t know at all than with a trusted colleague. For all I know you get beers every week with the CTO of my current employer’s largest competitor. Besides which there’s a way more interesting variation on the question, which is “how would you design our product?” Got that one in my last big tech interview and quite enjoyed it.

I suspect I got my current job in part by correctly predicting (in some detail) the product they were about to launch but hadn't announced yet.

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

#252

Post by kevinmchugh »

nonethewiser wrote: post #157
mgraczyk wrote: post #66

Earlier quoted context omitted.

It's possible in those cases that the candidates were really good. The main tells are a mismatch between apparent practical experience and apparent knowledge of the design space. I always dig into a few specific technical aspects of the design as far as possible to see how deep the candidate can go. For example, if there's a queue I'll ask what would happen if in production the queue starts to fill, and how to mitiga…

What do you expect them to say instead? I take your word for it that they’re trying to trick you or something - it’s not my story. But it kinda comes off like you’re denigrating people for not knowing something.

In an interview it is a negative to not know something. It's a bigger negative to not know something and try to hide that, or to be ignorant of the ignorance. "I don't know" is a fine answer in an interview. "I don't know, here's where I would look" is better

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

#253

Post by pedrosorio »

CardenB wrote: post #188
flashgordon wrote: post #184

Earlier quoted context omitted.

See the reason ops thing works is this can even be applied to something you haven't worked on but purely as a passion project on the side. If you are Saying "oh what if I don't have side projects" you do realize people spend/waste 3+ months going these interviews + tons of mock interviews with companies they have no intention of joining. What does it say about if you are telling me you'd rather waste valuable persona…

I’ll tell you precisely what it says about me: I put in 60 hour weeks at my current job, except for a month before I change jobs, where I put in an additional 2 hours/night to prep for interviews, because that’s what will benefit me for every other company. I care about my career and my family, so I don’t have the luxury of spending it on passion projects outside of work. I’d rather spend the precious little time I h…

Is that 6 AM - 6 PM nonstop work M-F? Or 8 hours on the weekdays and Saturday with a 12 hour sprint on Sunday?

How many of those 60 are spent in meetings?

Superhuman working hours for someone with a family.

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

#254

Post by CamperBob2 »

ikiris wrote: post #230
CamperBob2 wrote: post #219

Earlier quoted context omitted.

So draw the block diagram of something you worked on in school. Or, I don't know, a radio or something, if you're a hardware person. Someone who answers, "I can't draw anything for you because everything I know about is somebody's private IP," isn't going to get the job. At least, not if I'm doing the interviewing. You must know something about something else. Right?

Sure, I'd like to draw a vaccum cleaner, because this interview seems to suck and be unrelated to my job role. :)

"Great, that'll do nicely. Vacuum cleaners are complicated and interesting machines. What can you tell me about how a vacuum cleaner is built and how it works? Also, vacuum cleaners are pretty old tech. Is there room for further innovation in that area? If so, what angles would you explore if you worked at a vacuum cleaner company?"

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

#255

Post by everydayentropy »

stale2002 wrote: post #173
rco8786 wrote: post #103

Earlier quoted context omitted.

> 98% of what you'd be inclined to diagram out and explain for a system design interview isn't remotely proprietary Maybe we're just on different wavelengths, but literally every single thing I work on that would be a good candidate for this sort of interview is extremely proprietary...and I'm just working on regular ol' backend services at [generic big tech].

If the entirety of your web development knowledge is NDA'ed, then what good are you as a potential employee anyway? You wouldn't be able to build anything, as all your knowledge is NDAed!

This comment is a prime example of how the non-technical founder understands the world.

Proprietary systems are company IP. Talking about the design of the system is protected by the NDA, which the exercise described above is asking the candidate to do.

You hire for the skills to develop your own proprietary system. The employer doesn't own the skill. The employer owns anything those skills produced for the employer.

You wouldn't want your employees giving the recipe to your secret sauce away to your competitor, right? That's what everyone is talking about.

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

#256

Post by skizm »

codeisawesome wrote: post #187
omniglottal wrote: post #23

I got such fatigue from scrolling through so very much prologue, introduction, expectation-setting, and general "here is what we are going to say and here is how you may expect we will say it" fluff that I gave up, pages in, before getting to any apparent content.

Part 2 link at the bottom starts getting more specific: https://interviewing.io/guides/system-design-interview/part-... I like some parts of part 1 too, like this paraphrased quote from a senior FB engineer “I’ve learned more about distributed systems reading the internal interview wiki at FB than anything I ever actually built myself… the actual systems at scale are designed by platform teams and most engineers don’…

That is why the infra team get paid the big bucks (bigger than normal SWE) and are basically untouchable in layoff rounds. I know FB was still in full hiring mode for infra folks, even in the middle of layoffs / hiring freezes. I assume this is the same at the other FAANG / FAANG-adjacent companies.

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

#257

Post by Kranar »

mgraczyk wrote: post #155
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…

What I am saying here is that it's not true in all cases, so candidates should avoid blurting out rehearsed sentences like that. Caches usually reduce load on the thing behind the cache. They can sometimes reduce latency in ways that matter, but often don't. For example if the p99 requests all miss in cache, then the cache won't help.

But that's not true, the total latency including a cache is:

P(cache_hit) * cache_read_latency + (1 - P(cache_hit)) * cache_miss_latency

Assuming your scenario of 99% cache misses, that means you need a cache whose read latency is less than 1% of the cost of a cache miss. There are plenty of ways to design such a cache so that you still get a net performance benefit, even in your greatly exaggerated scenario.

One very simple example of an incredibly cheap cache that is almost certainly going to cost less than 1% of the cache miss latency is a bloom filter. Bloom filters can be tuned to be incredibly space efficient as well.

https://en.wikipedia.org/wiki/Bloom_filter

Please don't be so dismissive of people who answer questions by giving generally good and standard advice, just because you have some silly corner case that you want to play "gotcha" on.

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

#258

Post by Misdicorl »

nonethewiser wrote: post #148
lhorie wrote: post #99

Earlier quoted context omitted.

The way it typically fall aparts for my candidates is I ask about optimizations, they say X could be cached, then I ask about cache invalidation and lo and behold, it didn't even occur to them that the cache needs to be invalidated at some point, so they blurt something along the lines of doing the entire expensive operation again and checking it against the cache, or something similarly nonsensical. More common than…

Isn’t it better to know you can add a cache to reduce latency, even if you’re not sure how to invalidate it?

I started typing no, but then....

I honestly can't decide which would be worse: a developer who literally doesn't know what a cache is or one who installs caches with bad invalidation policies.

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

#259

Post by meese712 »

xapata wrote: post #122
rickreynoldssf wrote: post #117

First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies. ...that said. This kind of thing annoys me. You shouldn't have to study for an interview. Either you meet the requirement and have the experience or you don't. Reading books and stuff like this is really a cheat by the person being interviewed. You many have studied enough to "pass the test" but you really don'…

> best engineers Precision is different from recall. You're asking trivia. I'd rather ask questions that can't be studied for, only practiced through years of experience. I also sometimes hire people who don't know JavaScript, yet.

Don't see how you could consider the question they posed to be trivia for someone who knows javascript? Abuse of truthy evaluation is very rampant. All the JS codebases I've worked on are filled with `if (!myArray.length)` and etc. I would be very sad if anyone with a year of JS experience couldn't get this problem.

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

#260

Post by mgraczyk »

Kranar wrote: post #257
mgraczyk wrote: post #155

Earlier quoted context omitted.

What I am saying here is that it's not true in all cases, so candidates should avoid blurting out rehearsed sentences like that. Caches usually reduce load on the thing behind the cache. They can sometimes reduce latency in ways that matter, but often don't. For example if the p99 requests all miss in cache, then the cache won't help.

But that's not true, the total latency including a cache is: P(cache_hit) * cache_read_latency + (1 - P(cache_hit)) * cache_miss_latency Assuming your scenario of 99% cache misses, that means you need a cache whose read latency is less than 1% of the cost of a cache miss. There are plenty of ways to design such a cache so that you still get a net performance benefit, even in your greatly exaggerated scenario. One ver…

You are talking about minimizing the expected or average latency, which is very rarely important. The actual goal will depend on the broader system but typically you want to minimize the latency of the worst 95%, 99%, 99.9% etc of requests. Whether or not the cache reduces latency depends on the distribution of the cache hits. In practice, items that miss a simple LRU cache often have the longest latency in other parts of the system, in which case the cache would not reduce p99 latency.

EDIT: I recommend reading the Google SRE book or the famous "tale at scale" article.

https://www.barroso.org/publications/TheTailAtScale.pdf

Post reply on HN