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

191–200 of 399 posts

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

#191

Post by emodendroket »

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…

To be honest, since I have to go through preparing for the standard style of interview before a job search anyway, all these novel forms seem like annoyances.

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

#192

Post by LastTrain »

leeny wrote: post #129
modzu wrote: post #68

Earlier quoted context omitted.

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

> It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass.

No way, I’m dying here. “… and my main weakness is probably that I care too much…”

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

#193

Post by gwbas1c »

Are these interviews turning into a "can you regurgitate some memorized information" formality?

As an interviewer: This is always a red flag to me, because being a successful software engineer is much more than memorizing common truisms. (I spend a lot of time cleaning up misinterpreted "truisms.")

As a candidate: If I'm expected to regurgitate truisms, it's a flag that trying to do things "right" will be opposed by people who don't understand how computers / information work; and a lot of friction will come from trying to make something work versus make something fit an inappropriate ideal.

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

#194

Post by Retric »

stale2002 wrote: post #173
rco8786 wrote: post #103

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

If the entirety of your web development knowledge is NDA'ed, then what good are you as a potential employee anyway? You wouldn't be able to build anything, as all your knowledge is NDAed!

What you learned isn’t the same as what was built.

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

#195

Post by angarg12 »

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 work for a big tech co, and our interview training explicitly says to not ask candidates about systems they have built in the past, but to ask them to build brand new systems from scratch.

This seems completely backwards to me. Is like saying "hey, do you know that relevant on the job experience that you have? we don't want to hear anything about it, here you have a made up scenario".

Ok ok, that is a bit cynical. Asking to design novel systems can give you some good insights about the candidate, or help with people who don't have experience building systems yet. Still it seems to me that asking candidates to describe real world systems that they have actually built is much more useful at checking their skills than building imaginary systems.

One argument against this is that candidates can "cheat" by preparing in depth a made up example. But how is that much different than the current approach?

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

#196

Post by angelbar »

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, nobody can never do again anything that he/her do to become a expert?

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

#197

Post by flashgordon »

CardenB wrote: post #188
flashgordon wrote: post #184

Earlier quoted context omitted.

See the reason ops thing works is this can even be applied to something you haven't worked on but purely as a passion project on the side. If you are Saying "oh what if I don't have side projects" you do realize people spend/waste 3+ months going these interviews + tons of mock interviews with companies they have no intention of joining. What does it say about if you are telling me you'd rather waste valuable persona…

I’ll tell you precisely what it says about me: I put in 60 hour weeks at my current job, except for a month before I change jobs, where I put in an additional 2 hours/night to prep for interviews, because that’s what will benefit me for every other company. I care about my career and my family, so I don’t have the luxury of spending it on passion projects outside of work. I’d rather spend the precious little time I h…

But I never said you had to spend all your life on passion projects. How is leet code fair game but asking how they would build something they would to even if they never did or do somehow an indication that I think you are a bad engineer? Because I see today's state of system design question interviewing pretty much like leetcode no (asking this as a faang interviewer)?

Having said that what you said about spending 60 hours at work tells others you will be a much better employee. Which is probably the signal they are looking for?

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

#198

Post by jameshart »

This generally seems like good advice, but it does veer occasionally towards suggesting ways to appear good at system design when actually the point of a system design interview is to show the interviewer how good at system design you actually are.

This is an important distinction because it is not necessarily the case that the only way to pass a system design interview is to come across as being brilliant at it. I will happily take on a developer who shows that they have some good system design instincts but lacks a mature approach to engineering decisionmaking (assuming their other interviews show that they seem teachable and they have the other prerequisite skills). Not every developer is going to be a lead system designer. The interview is to help us figure out what kind of developer you are.

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

#199

Post by angelbar »

blowski wrote: post #77
zinclozenge wrote: post #45

Earlier quoted context omitted.

Square/Block (used to?) ask only 1 system design question and the recruiter would let you know ahead of time so you could prepare for it. Probably because it allows for deeper questioning and answering of relevant technical skills.

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.

That candidate is the best one... the one that can understand and apply any knowledge to resolve the problem in front of him.

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

#200

Post by marcosdumay »

dakiol wrote: post #86
ed25519FUUU wrote: post #82

> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt. As someone who has conducted countless interviews at a FANG, I can not stress this point enough. The ability to just talk about a problem makes a big difference between a mediocre interview and a great interview. Besides, it's what makes an interview fun or lame.

Problem is: as candidate you don't know if "engaging in a back-and-forth conversation about problem constraints" is something the interviewers want. Some interviewers want it, but it's not always like that. And, no, usually discarding an entire company just because the interviewer on duty doesn't like "engaging" is BS.

Well, as the interviewed you must pick one if the two options without any hint.
Post reply on HN