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

121–130 of 399 posts

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

#121

Post by specialp »

jhp123 wrote: post #94
fdgsdfogijq wrote: post #61

Earlier quoted context omitted.

If you havent designed a system from scratch, or designed a major change, you arent a senior engineer.

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. But the follow up questions could be like OK your form works and now your video site becomes enormously successful and your video transcoder is overloaded, what would you do? Well I could parallelize the consumers of the queue to some large number, and scale based on load...

So isn't going to be something like I would architect my own massively parallel converter database and binaries written from scratch to process all the various formats which is probably closer to what is done in reality. But senior and lead engineers should indeed understand tradeoffs, parallelization, queues, data storage concerns. They are given as questions because people know from a use case view how they generally work.

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

#122

Post by xapata »

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.

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

#123

Post by candiddevmike »

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

I think it's a combination of a lot of interviewers priding themselves when they "stump the chump" and a possibly subconscious optimization to find folks who won't upset the status quo.

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

#125

Post by rednerrus »

_visgean wrote: post #111
rednerrus wrote: post #81

Earlier quoted context omitted.

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.

When I interviewed with apple they said pretty much everything they do is proprietary and considered secret. I imagine for some of these people working there for years it would be hard to avoid breaking nda

There’s no place where we are asking you to diagram the system that you’re working on. We ask you to diagram a system you understand well. Are you using messages queues, container orchestration, network components, cloud infrastructure, Java/rust/go/Python/etc.? Tell me about one of those components and how they connect together in theory vs the specifics of your system. Everyone who works in technology works with, mostly, complicated interconnected systems. The point of this exercise isn’t to design a system or tell me about a system that you’ve designed as much as it is about helping the team to understand the breadth and depth of your technology knowledge. Good engineers typically find creative ways help us understand their knowledge without disclosing NDA material.

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

#126

Post by ThalesX »

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…

> then I ask about cache invalidation

No doubt with a follow up on how the variable would be best named.

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

#127

Post by yunwal »

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…

> 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 is filling up before changing anything", but very few candidates answer that way.

This is the opposite of what "people with real experience" do, at least in production-down situations. The first step is to mitigate, the second step is to root cause. If there's some no-brainer step that has a chance of alleviating the issue while you root-cause, and is unlikely to make things worse, you should take it.

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

#128

Post by zbuf »

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.

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.

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

#129

Post by leeny »

modzu wrote: post #68
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.

its an ad, and they nailed the seo

Hey, founder of interviewing.io here. We actually did zero thinking about SEO. We had someone look at this guide at the end through an SEO lens, but then we decided that that would make the content not as good and would make the guide less readable.

(As an aside, I think in recent years, the spirit of SEO has become more about just making good stuff and less about hacking...)

Anyway, it wasn't for SEO. It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass.

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

#130

Post by p1necone »

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…

> database systems

When was the last time building a database from scratch was a sane approach to building something?

Post reply on HN