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

141–150 of 399 posts

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

#141

Post by apsurd »

ditonal wrote: post #75
moandcompany wrote: post #65

Earlier quoted context omitted.

One of the "heavy practice/coaching/leetcode grinding" signals is when the interviewee immediately dives into proposing a solution and discusses facets of that solution in great detail without bothering to ask clarifying questions or discussing assumptions and the risks/consequences of those assumptions.

I think the opposite is true. An experienced engineer not as versed in interview prep might hear the question to design something, and go ahead and show how they would design it based on their experience doing it in the real world. The leetcode grinder would almost certainly ask clarifying questions since it’s heavily emphasized as part of the rubric in pretty much all system design interview prep material. Of course…

It's funny cuz the leetcode grinder also learns that "asking clarifying questions" is part of the right answer structure too. So the cat-&-mouse game becomes more nuanced, but I do agree that it usually does become apparent that less-experienced candidates are _blindly_ following a strategy they learned somewhere. Interestingly this is not _inherently_ wrong since if you think about it, don't experienced people do the same thing? playbooks and checklists etc.

But TLDR: the hollowness of each step of the approach does become apparent in my experience.

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

#142

Post by [deleted] »

John23832 wrote: post #100

I think to be frank, this gamification of interviews is BS. I’ve built actual production systems at scale. The fact that I need to follow a guide to “demonstrate” my ability to someone who 9/10 hasn’t built (or couldn’t build) anything at scale in production shows where we are in the absurdity matrix.

[deleted]

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

#143

Post by theteapot »

debacle wrote: post #22

I remember once I was interviewing for a senior position where the ask was something like "design a general purpose system for a REST layer on top of an ORM." I had just finished implementing an OSS solution that did exactly that, including some upstream changes we made to improve the system, so I walked through exactly what we did, challenges we faced, etc. I walked out of the interview feeling as though the intervi…

    .----------.  .------.  .-------.
    | REST API |->| ORM  |->| RDMS  |
    '----------'  '------'  '-------'
Too easy. Next question.

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

#144

Post by ZephyrBlu »

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?

If the candidate is exposing flaws in your assessment and making you think that should be a positive signal, not a negative one. Unfortunately people have egos and generally don't take kindly to situations like that.

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

#146

Post by bradlys »

apsurd wrote: post #137
yunwal wrote: post #127

Earlier quoted context omitted.

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

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

Most interviewers are adversarial.

Let's be honest - if an interviewer wants you to pass a system design interview, they'll make it work. I see this with particular candidates all the time. If we want the person to make it through - we'll let them get through. If we don't want them to get through - no amount of correct and behaviorally appropriate answers are gonna make them get through.

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

#147

Post by vineyardmike »

bluetomcat wrote: post #57
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…

Few people at software companies are designing systems from scratch nowadays. If they are, they'll be gluing together third-party middleware applications like database systems, queues, proxies, load balancers, etc. A general understanding of computer architecture, programming language theory, networking and common protocols and formats is more valuable. At that fundamental level, they won't be using recent fancy buzz…

In 2023 knowing which AWS database to choose, even if it’s hosted for you is probably ok for the system design level. Knowing when to use a queue or a load balancer etc is ok even if you didn’t engineer the queue. The company you’re going to probably isn’t implement their own either.

I agree that you need basic networking and protocol understanding etc still. And that being able to talk through problems conceptually is important.

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

#148

Post by nonethewiser »

lhorie wrote: post #99
jeron wrote: post #83

Earlier quoted context omitted.

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.

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?

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

#149

Post by mgraczyk »

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…

This might be true of SRE roles, but not really true for most engineers, particularly not where I currently work. I wasn't completely clear but what I'd be asking for here is how to predict and design for bottlenecks, not how to mitigate active disasters.

Also making a queue bigger is a bad reflexive response to queues being full. I was very involved in the SEV review (postmortem) process at Facebook and witnessed lots of cases where bad situations were made much worse by misguided hasty responses.

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

#150

Post by mgraczyk »

yodsanklai wrote: post #132
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 wi…

As an interviewer, my job is to differentiate between people who have experience vs people who have just read books and articles. I interview mostly L6+, so I will not recommend people who I don't believe have real experience building complex systems at scale.

I think it only takes an hour or so to become familiar with the structure. I can tell during the interview if that's the problem and I will be very patient in explaining what I'm looking for in that sense.

Post reply on HN