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

131–140 of 399 posts

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

#131

Post by old_hat »

ThalesX wrote: post #126
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…

> then I ask about cache invalidation No doubt with a follow up on how the variable would be best named.

That's obvious. It's called "x".

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

#132

Post by yodsanklai »

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…

> I feel like I can easily see through interview practice or coaching, so I don't recommend spending more than an hour or so "preparing" for system design interviews.

I'm very surprised by this recommendation which doesn't match my experience at all. First, lots of candidates don't have experience building such systems, so they need to learn by reading books and articles. Second, the candidates need to be familiar with the structure of the interview and what's expected from them, and that takes practice too.

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

#133

Post by twelve40 »

siva7 wrote: post #46
tootie wrote: post #36

I think it's funny how they say you don't need experience to pass one of the interviews. Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. That and I kept trying to extract imaginary requirements. I still have no idea what they wanted to hear so I just…

You're wondering why you didn't get the job after letting the interviewer feel like their assessment tasks weren't perfectly designed?

Well, the sad truth is that a lot of _interviewers_ actually suck at interviewing, so sometimes an interview devolves into a bewildering game of what this particular person wants to hear today based on their mood, especially with the open-ended questions. It is not always possible to suffer through this process politely and constructively.

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

#134

Post by posharma »

rednerrus wrote: post #9

We've gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It's a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something…

I don't know if you work in FAANG or no, but most FAANG interviews just don't work this way. So, as much as I like this style, it's just 1 company and definitely not the norm. The rest of us are stuck with design Uber, Whatsapp, crap...

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

#135

Post by squeaky-clean »

specialp wrote: post #121
jhp123 wrote: post #94

Earlier quoted context omitted.

these "system design interviews" often focus on systems at the scale of major consumer internet companies, e.g. "design youtube", "design twitter". How many systems of that scale even exist? 100? Only the core developers of those systems would be considered "senior engineer"?

Someone isn't going to design one of these system or has designed some of these systems themselves or during an interview. However for something like YouTube one could say Ok to start simply I would have a frontend form to submit videos, which sends it to a video conversion API queue that calls back when it is completed or could be polled for progress. Now obviously what YouTube really does is much more complicated.…

When I interviewed at Facebook my system design question was for a Yelp-ish clone that would be rolled out to Facebook as a whole. The interviewer told me the design had to be scalable to 1 billion daily users on day 1.

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

#136

Post by ZephyrBlu »

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

Wait, what?

You're saying "you shouldn't have to study for an interview because you either have the experience or you don't" and then you're equating being able to answer a trivia question with experience.

The irony is extremely rich. Being able to answer any particular question cannot measure if someone has the requisite experience. The only thing it tells you is that they can answer that question.

Your judgement of them based on your question is extremely subjective and doesn't tell you whether they "REALLY know the subject" or not. You are just testing your own biases which may yield good results, but call a spade a spade.

> When I do interviews I make sure the candidate is aware that studying will be a pointless endeavor and if I can tell your answers come from one of the interview prep books I'll end the interview early. My interviews ask questions that will tell me if you REALLY know the subject. For example if JavaScript is a requirement I'll throw this at you

How can you tell if someone had simply memorized a few pieces of JS trivia and is regurgitating it to answer your question? The code is not that complex or "totally weird".

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

#137

Post by apsurd »

yunwal wrote: post #127
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…

> People with real experience will have encountered this problem and know that you have to spend time investigating to find the root cause of the backpressure, otherwise you could add capacity to random things without reducing the queue occupancy. Are your queue consumers getting throttled by some downstream service? Are your workers CPU bound? The "right" answer here is basically "we should figure out why the queue…

Your point is good, but in making it, you sound like an adversarial interviewer.

You and OP are actually agreeing with "the correct answer is it depends and now let's discuss context". This echoes my experience as interviewer too. It's a red flag when the candidate responds with "the correct answer". That's what OP is calling out.

I'm replying here because I get the impression you're looking for "the right answer" as you see it: "the first step is to mitigate then do root cause". You're right! But it also could be too adversarial.

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

#138

Post by ozim »

toolz wrote: post #97
eschneider wrote: post #92

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. People are generally looking for a high-level overview of a system you've worked on to see a) that you've really worked on it and b) you can explain it such that it makes sense. Sure, folks will ask you to drill down here and there for more detailed info, but if someone pokes on something where the detai…

I'm not a lawyer, but wouldn't anything you or anyone else developed on company time at another company be owned by that company and thus proprietary? In practice I can't imagine the spirit of any law would be violated by doing an architecture diagram, but it seems likely (to me, at least) the word of the law would be violated.

So no one else can never build todo app or blogging system?

There is term called prior art an for me if you write bunch of props to database like text/numbers it is basically done in every other system.

Unless you build novel db system of course.

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

#139

Post by yieldcrv »

azornathogron wrote: post #30
rednerrus wrote: post #9

We've gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It's a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something…

I like this... in theory. But I don't think I'm allowed to give you a system diagram and detailed explanation of systems I've worked on, because obviously they're proprietary. That seems like a problem. How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they've worked on?

At this point I just build on top of other take-home projects I've done and pretend like its my portfolio.

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

#140

Post by siquick »

posharma wrote: post #134
rednerrus wrote: post #9

We've gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It's a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something…

I don't know if you work in FAANG or no, but most FAANG interviews just don't work this way. So, as much as I like this style, it's just 1 company and definitely not the norm. The rest of us are stuck with design Uber, Whatsapp, crap...

I’ve done multiple interviews like this - “tell us about a system you built”

Not sure if you heard but there are a few other companies that exist outside the FAANG circle

Post reply on HN