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

231–240 of 399 posts

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

#231

Post by dilyevsky »

nvarsj wrote: post #159
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…

No offense meant, but your comment already shows your inherent bias. You are looking for people who have solved specific system design problems. That means you are already being overlay narrow in your selection criteria. I have a background in quant dev and HFT for example. When I was doing system design for big tech (at L6 level), I found that the kind of system design questions asked had very little overlap with my…

Like other commenter pointed out you were interviewing for what basically amounts to “tech lead” role without relevant experience. I’m not sure other L4-5s on the team would be happy if someone less experienced is hired in a TL role

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

#232

Post by dilyevsky »

Plasmoid wrote: post #179
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…

A cache is such a red flag when I'm doing a system design interview. I ask people to design a system but the system itself is very write heavy. Like 50 writes per read imbalanced. People will often suggest a cache because it's in the standard interview prep but not actually think about why they need it. They just go right to "I need a cache somewhere".

Ok if not cache then it must be hashtable?

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

#233

Post by djur »

rednerrus wrote: post #96
Salgat wrote: post #87

Earlier quoted context omitted.

Being able to use something you've intimately worked on as part of your job is a huge advantage since you're so familiar with it.

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

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

#234

Post by djur »

flashgordon wrote: post #197
CardenB wrote: post #188

Earlier quoted context omitted.

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…

Leetcode isn't fair game either. It's a despicable practice.

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

#235

Post by djur »

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.

If you can't distinguish between those two types of people by asking additional questions about their design, are you capable of accurately evaluating them in the first place?

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

#236

Post by clucas »

rednerrus wrote: post #52
onlyrealcuzzo wrote: post #31

Earlier quoted context omitted.

> It gives you a chance to explore depth and breadth of their knowledge on something technical that they claim to understand. Assuming you know enough about what they're doing to actually dig in - which, granted, maybe you're only considering interviewing people who are working things you're somewhat familiar with. Ultimately, I don't see how this is different from a technical design interview - in that you can be su…

We've had very few false positives. It's a conversation and we understand and appreciate when people say they don't know. We understand that really good engineers say "I don't know how that works." If all of your answers are "I don't know how that works.", it'll be red flags enough for the team. The team of interviewers has a very wide and deep knowledge of technologies (it's kind of a virtuous cycle). We call it out…

Is this sort of interview common in the industry? This is the first time I've seen someone describe a technical interview I know I could pass with flying colors.

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

#237

Post by thrashh »

nvarsj wrote: post #159
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…

No offense meant, but your comment already shows your inherent bias. You are looking for people who have solved specific system design problems. That means you are already being overlay narrow in your selection criteria. I have a background in quant dev and HFT for example. When I was doing system design for big tech (at L6 level), I found that the kind of system design questions asked had very little overlap with my…

Well I mean your experience isn’t any different than applying for a job that uses Python when you’ve only used C++.

Sure, they can train you to learn Python, but they’re specifically looking for a Python developer. They’re not looking for a generic “person that can learn stuff” when there are many Python developers out there that can pick up the job day one.

In your case, you had to put in a lot of work because you essentially were switching specializations.

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

#238

Post by projectazorian »

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!

The engineering knowledge isn’t under NDA but there’s no way I could fill an hour long interview about the systems I work on without getting into enough specifics about our business processes to violate NDA.

If I were asked a question like this I’d wonder if I were being tested to see how loose-lipped I am with sensitive information.

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

#239

Post by bcrosby95 »

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!

There's a difference between being asked to design a system of the interviewers choice and being asked to design a system you know deeply.

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

#240

Post by ZephyrBlu »

mgraczyk wrote: post #164
nvarsj wrote: post #159

Earlier quoted context omitted.

No offense meant, but your comment already shows your inherent bias. You are looking for people who have solved specific system design problems. That means you are already being overlay narrow in your selection criteria. I have a background in quant dev and HFT for example. When I was doing system design for big tech (at L6 level), I found that the kind of system design questions asked had very little overlap with my…

Well for my own startups I don't do system design interviews. I don't think they're perfect and there are better ways of measuring the same thing if you have more time per candidate. Big companies like Google have to sometimes choose mediocre processes that are Lindy and agreed on. System design interviews are less bad than coding interviews IMO, and they are much more scalable for Google. I think I'm better at spott…

> Another point, your specific background may not matter for L6 roles. I want to know if you can build the sort of thing you will be building in the role you're interviewing for. I don't care if you're good at building something else

Why would you narrow your pool so much, especially when specific experience is usually not what defines higher engineering levels but rather architecture, leadership and communication skills?

If someone is actually skilled in system design they would be able to come into a new domain, understand the constraints and design a system within those constraints.

People seem to superficially pattern match on experience that looks similar, but doesn't really have that much overlap a lot of the time.

My thinking is that most things are far more specific than we realize, so why not mostly forget about specific domain knowledge and focus on applicable high level skills? Domain knowledge is a nice bonus, but you're almost certainly going to have to learn things on the job regardless.

Post reply on HN