[flagged]
A senior engineer's guide to the system design interview
161–170 of 399 posts
Re: A senior engineer's guide to the system design interview
#162Earlier quoted context omitted.
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…
What do you expect them to say instead? I take your word for it that they’re trying to trick you or something - it’s not my story. But it kinda comes off like you’re denigrating people for not knowing something.
If they bring up graphql, I expect them to say something like "none of the advantages of graphql are applicable in this case, so it may make sense to use if it's already well supported. All else being equal it's probably not a good fit"
The key is that the response should reflect the actual design we're discussing, it should be more specific than something that could be said in any interview.
Re: A senior engineer's guide to the system design interview
#163First 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'…
It's rational for most candidates to study interview prep books because that is what the majority of companies want. Not saying I like it, but why would you want to filter out candidates who are just using basic common sense?
Re: A senior engineer's guide to the system design interview
#164I 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 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 spotting genuine experience vs preparation than most interviewers because I've done a lot of interviews. On the other hand I don't think I can tell 100% of the time, and it's not black and white to begin with.
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. This is less true for L4 and L5.
Re: A senior engineer's guide to the system design interview
#165I remember once I was interviewing for a senior position where the ask was something like "design a general purpose system for a REST layer on top of an ORM." I had just finished implementing an OSS solution that did exactly that, including some upstream changes we made to improve the system, so I walked through exactly what we did, challenges we faced, etc. I walked out of the interview feeling as though the intervi…
I’ve got an interview coming up for a senior role on a UX engineering team (design system, component libraries, etc). The interview is just the standard set of backend system design and leetcode problems. It’s a pretty big red flag to me that the skills being evaluated are so tangential to the actual job. It doesn’t give me any confidence that the people I will be working with have the skillset I consider important,…
They always tell us, when you're interviewing candidates, they're also interviewing you. Show them why they should work here.
Re: A senior engineer's guide to the system design interview
#166I 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…
Re: A senior engineer's guide to the system design interview
#167Earlier quoted context omitted.
I don't know if you work in FAANG or no, but most FAANG interviews just don't work this way. So, as much as I like this style, it's just 1 company and definitely not the norm. The rest of us are stuck with design Uber, Whatsapp, crap...
I’ve done multiple interviews like this - “tell us about a system you built” Not sure if you heard but there are a few other companies that exist outside the FAANG circle
And they pay well like FAANG? Examples?
Re: A senior engineer's guide to the system design interview
#168Earlier quoted context omitted.
>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.
But it’s clearly a handicap.
Re: A senior engineer's guide to the system design interview
#169Earlier quoted context omitted.
> Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. So.. you argued with the interviewer about their question being 'invalid'. That's not going to be a winning strategy. If you have to insist on making comments like these, a better way to express it wo…
I don't know why you assume I was rude about it. I phrased it all equivalently to how you said. A lot of my background was in tech services so I'm very well practiced in asking these kind of questions. They pretty much waved off all of them saying it wasn't relevant.
> They pretty much waved off all of them saying it wasn't relevant.
Well, if they are asking how to build a highly scaleable system, then statements about how to build a not highly scaleable system would not be relevant.
Re: A senior engineer's guide to the system design interview
#170Earlier quoted context omitted.
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…
If you havent designed a system from scratch, or designed a major change, you arent a senior engineer.
If you carry this attitude, you aren't a senior engineer.