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

101–110 of 399 posts

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

#101

Post by jefQuery »

I read all 4 parts in the pre-released version on the interviewing.io discord. Here's my feedback:

Loved how much they go into the actual interview dynamics and phrases to say, where as other resources wave away interacting with the interviewer as an implementation detail. Haven't seen that anywhere else on the web and it's super helpful. The framework is also much more fleshed out than, for instance, the HiredInTech system design guide.

However, the 12 tech ideas section was a little too dumbed down for me, though it might be helpful for someone with less experience. I also noticed a few typos (MangoDB, cache vs hash) and told them, and they said they'll fix it in the next version of the guide.

3.5/4 stars; would read again

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

#102

Post by blowski »

pcthrowaway wrote: post #88
blowski wrote: post #77

Earlier quoted context omitted.

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.

I’ve seen first hand people hired who’ve aced the system design interview but then fail to get much done. Building systems in the real world is much more than a few high-level components and algorithms - it’s about all the edge edge cases, tricky stakeholders, ambiguous and changing requirements, sequencing and coordinating small pieces of work.

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

#103

Post by rco8786 »

eschneider wrote: post #92
azornathogron wrote: post #30

Earlier quoted context omitted.

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?

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…

> 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].

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

#104

Post by rednerrus »

cauthon wrote: post #98
rednerrus wrote: post #85

Earlier quoted context omitted.

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.

I have the opposite question from other people in the thread - this seems pretty open-ended. Just as an example, I do bioinformatics work, and "technical system" for someone I'm interviewing (as I understand your question) might encompass any of: - a workflow manager: how it works under the hood, common patterns for modularity/reuse or configuration - a specific pipeline: the stages of cleaning and quantifying raw da…

For our more junior roles, we leave it more open ended because candidates may not have a similar knowledge bases to the panel. For more senior roles we advise that if they pick technologies that are pertinent to the role and likely to be understood by senior/lead/staff engineers, the process will go better for candidates and panel members.

If I were in your position, one of understanding many complex systems, I would advise you to pick where you felt both strong and the panel was likely to have some entry point into.

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

#105

Post by jfarina »

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.

How could you ever interview anywhere if you couldn't provide details of the projects that you worked on?

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

#106

Post by hadlock »

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?

System diagram of a CRUD SAAS isn't going to be a critical business secret in the same way it might be for a company that does stream processing of marketing/advertising data off of twitter or video/radar analytics. Or a real-time fintech trading company. Many companies are a Python/Django monolith on Postgres with redis & || memcached. That system diagram isn't going to let you disrupt the online medical services industry but it's what a lot of them use.

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

#107

Post by rednerrus »

xen2xen1 wrote: post #47
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…

When doing IT people often say "Well, I don't know anything about computers", which I generally found pointless, as with about 30 seconds of talking I can tell if you know anything or not. Your story passes my smell test, as getting someone talking is 90% of telling what they know.

People with broad and deep understanding of technology can typically gauge if someone knows there stuff or not with 30 minutes of them describing a system to you and answering questions about it.

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

#108

Post by jefQuery »

mgraczyk wrote: post #66
leonidasv wrote: post #60

Earlier quoted context omitted.

>I feel like I can easily see through interview practice or coaching How do you spot it? I've had candidates with stellar performance on system design interviews, and I've never had any suspect of them (and the resumé also seemed pretty strong in those cases). But now I'm curious if I missed something.

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…

It feels cool to me that my nontraditional degree for software (ChemE) drilled this into us and now it comes up in my current job: Rate of input - rate of output = rate of accumulation

It’d be fine to just up the queue capacity if the input is just inconsistent/spikey but averages to the input, but under steady state (or steadily increasing growth) higher input, you must increase the output rate or you will outgrow whatever capacity the system has

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

#109

Post by eschneider »

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.

Sure. But the level of description that you're giving in an interview can be pretty generic/non-proprietary. If that wasn't the case, then you really can't reuse any knowledge from job to job and that's just not so.

Sure, every company is going to have their 'special sauce' components, that ARE proprietary, but nobody's going to expect you to unpack those.

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

#110

Post by zekrioca »

rednerrus wrote: post #42
jstx1 wrote: post #13

Earlier quoted context omitted.

Still sounds like a system design interview to me, just a bit less structured.

We've found that candidates who better understand how things are connected make better candidates and operators. We need some way to gauge how well they understand how things are connected. This is as fair of way as we've come up with.

I totally relate to that. In the university setting, I see many students more interested in learning keywords instead of “key concepts” behind such keywords. Think of preferring to learn “k8s” instead of “resource manager”. Today, very few of them knows that etcd is one of the key components in “k8s”.

I guess this behavior is similar to the transformation that happened in other non-CS fields.

Post reply on HN