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

331–340 of 399 posts

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

#331

Post by vasco »

grufus wrote: post #330

Issue with system design is that our industry is so highly opinionated about things. You design something to the best of your abilities, it works (though may have its pros and cons) and then you go present it to a crowd of engineers (HN, say) ... and you get destroyed. There will always be people telling you that these were dumb choices and that that's obvious. And if you go and do what they say is the obviously bett…

That just means there's still space to be creative. If we were printing books or something "mature" we'd be automated away already.

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

#332

Post by vrnvu »

Can we stop saying that the 'over engineering interview' is a 'system design interview'?

Most real life problems don't get solved by adding queues and moving to an event driven architecture with thousands of micro-services.

What I'd expect from a senior engineer is deep technical understanding of how a queue works (epoll, poll, io multiplexing, io non blocking, readiness) for example.

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

#333

Post by emodendroket »

okdood64 wrote: post #317
emodendroket wrote: post #270

Earlier quoted context omitted.

> The purpose of the system design interview is to convince me that you could build, or lead a team to build, the thing that we are discussing at a company like the one where you are interviewing. 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. Unless you are interviewing somewhere with very inexperien…

> I just didn't know how you're supposed to approach the question. For your example, I would ask them to define what scale we were operating in, and what the footprint would be, etc. Then you could start off with a more complex design (which seems like what the interviewer wanted.)

Well I know that now because I watched a bunch of prep videos and then easily passed interviews despite my experience not significantly changing in the intervening time. But that's my point; if you don't prep you have to just guess which aspects of this pretend scenario you're meant to be taking seriously and which are OK to gloss over. I had other interviews go off the rails because I offered too much detail about a smaller part of the system and discussion of it dominated the entire time but even though the interview kept engaging this discussion it wasn't actually what they wanted. "Don't bother prepping because you can't; it's just measuring your real abilities" is just not right, in my opinion.

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

#334

Post by rednerrus »

kridsdale1 wrote: post #212
rednerrus wrote: post #96

Earlier quoted context omitted.

There have to be parts of what you work on that are not covered by NDA. Solving problems like this would be indicative of someone we would want on our team.

When I worked at Apple they made it abundantly clear that EVERYTHING was under NDA. Even things like “what version of the standard library do you use”. Or “what are computers for”. And that any minuscule transgression of the NDA would result in me Being immediately deported, divorced, and likely put in front of a firing squad.

That can’t tell you that you can’t explain how Kubernetes works or NGINX or the JVM. Any one of those things would be perfectly acceptable as a starting point.

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

#335

Post by rednerrus »

djur wrote: post #233
rednerrus wrote: post #96

Earlier quoted context omitted.

There have to be parts of what you work on that are not covered by NDA. Solving problems like this would be indicative of someone we would want on our team.

The problem you're asking them to solve is a legal one, but you are not interviewing lawyers. I have never worked for a single employer that didn't require an NDA, and the NDAs are always written in a way that can be easily interpreted as "do not tell anyone anything about what you do here".

The question is not tell me what you do in your current job. The question is describe a technology or system that you understand well. Do you understand how the underlying systems work? You don’t have to tell me that your current company uses kubernetes to describe how kubernetes works. Your current job can’t keep you from describing how kubernetes works. Kubernetes is just an example here you could pick any technology that you’re comfortable with.

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

#336

Post by rednerrus »

kridsdale1 wrote: post #215
rednerrus wrote: post #125

Earlier quoted context omitted.

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

I worked at apple in the past. It would be a violation to answer your questions.

You can’t tell me how HTTPS works because of your NDA?

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

#337

Post by rednerrus »

CamperBob2 wrote: post #219
ikiris wrote: post #203

Earlier quoted context omitted.

I literally can't diagram 90% of the stacks I've worked on in the last 8 years because they're highly NDA.

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?

This is why this question is so informative. There are a ton of people in this thread arguing that they can’t describe any technologies they understand because of NDAs.

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

#338

Post by rednerrus »

ramraj07 wrote: post #180
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…

How many rounds of interviews do you typically do? What other interviews if any? Curious what good orgs are doing in this regard!

We do phone screen, team fit, technical. Technical is two part, the diagram and a group exercise debugging something. That’s it. It’s 3.5 hours total.

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

#339

Post by rednerrus »

recfab wrote: post #322
bhvangoo wrote: post #27

Earlier quoted context omitted.

hmm interesting approach, really like it. Where do you work? and are you hiring now?

I would also like to know these things. This sounds like a type of interview that respects my time, which makes me think there is a good chance the company as a whole will respect my time and humanity as well.

This is exactly what we’re going for. It lets candidates know that we value their time and have worked as hard as we can to create an interview process that lets us gauge whether or not you’d be a good fit for the job in the least amount of time as possible.

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

#340

Post by rednerrus »

jahewson wrote: post #54
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 like this approach because it doesn’t provide measurable or repeatable criteria for comparing candidates. It also suffers from a sort of Gell-Mann amnesia where a candidate who spouts good-sounding BS about a topic you’re not familiar with is assumed to be competent across the board.

The process is repeatable. We ask all candidates for the same role the same questions and ask them to do the same technical tasks. The other component of our technical interview has something more similar to scoring.

We’ve found that this diagram exercise is actually a lot harder to BS your way through because the expectation is that we’re going to probe into your answers and it’s supposed to be something you understand well.

Post reply on HN