Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

301–310 of 399 posts

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

#301

Earlier quoted context omitted.

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

> 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. I mean, it's a cool thought process to go "Ooh, maybe I can store up repeated things so I don't need to repeat an expensive access process often!" It's a byproduct of modern computin…

Well yeah, if you can say all this in the interview then you will be fine. 90% of candidates will instead read "add cache to improve performance" in their interview prep guide and repeat it verbatim.

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

#302
post #297

Earlier quoted context omitted.

You are talking about minimizing the expected or average latency, which is very rarely important. The actual goal will depend on the broader system but typically you want to minimize the latency of the worst 95%, 99%, 99.9% etc of requests. Whether or not the cache reduces latency depends on the distribution of the cache hits. In practice, items that miss a simple LRU cache often have the longest latency in other par…

Well folks, you heard it here. Average latency is rarely important and if someone presents a very standard and common way to reduce latency of a system, you should dismiss them because they should be aware that your specific system that they have no knowledge of would result in 99% of cache misses. I used to work at Google long ago in the platforms division, in fact I worked on the BigTable cache (among other things,…

What's your ldap? I can look you up and see what you were working on, and whether it required making design decisions around reduced average system latency.

And yeah this is exactly my point. If you present a "standard and common" solution that isn't applicable to the question I actually asked, and if you blindly apply solutions without thinking about what problem is actually being solved, then that's bad in an interview.

Average latency is usually not the thing you want to reduce because it's not representative of what any actual user is experiencing.

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

#303
post #284

Earlier quoted context omitted.

> There's a good chance at my career phase I have more experience than the interviewer. This happens a lot. I was once in the process for google and was asked a time series systems design problem. I said, “lets throw this in a time series db”. The interviewer had no idea what a time series’s db was. Mind you this was an interview for Google Cloud and the person worked on SPANNER. They also has been at the company for…

What's the sour taste -- what's the problem? Like, what's wrong with being interviewed by someone with less experience than you?

Right, that means the interview is on easy mode. A clear indication that the candidate has something to offer to the org.

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

#304
post #297

Earlier quoted context omitted.

Well folks, you heard it here. Average latency is rarely important and if someone presents a very standard and common way to reduce latency of a system, you should dismiss them because they should be aware that your specific system that they have no knowledge of would result in 99% of cache misses. I used to work at Google long ago in the platforms division, in fact I worked on the BigTable cache (among other things,…

What's your ldap? I can look you up and see what you were working on, and whether it required making design decisions around reduced average system latency. And yeah this is exactly my point. If you present a "standard and common" solution that isn't applicable to the question I actually asked, and if you blindly apply solutions without thinking about what problem is actually being solved, then that's bad in an inter…

Why would you do that? Now you're being weird and kind of creepy.

With that said, to the best of my knowledge it is the same as my HackerNews handle, so you are welcome to find whatever info you'd like on that, but please understand your request is very creepy and akward.

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

#305
post #295

Earlier quoted context omitted.

> I get what you are saying, but I have done tech recruiting for a long time and the reality is that everyone claims they have built complex production systems at scale Then we need a better test, but the gamification and badgering isn’t effective imo. > And once in a while some genius superstar 10x programmer comes along who is too good for these silly interviews... well that's fine we don't need that arrogance eith…

Cool then go design a better process that picks out the best engineers on the planet without asking them any engineering questions. Clearly you are smarter and have accomplished more than anyone at any company you have interviewed with, so it should be a cakewalk for you. Heck you can make billions by finally cracking the tech interview problem.

Lol woah. I’m just giving my perspective on the problem. Your response seems like you’re hurt.

Maybe I’m not the one with an issue after all.

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

#306
post #300

This is, unfortunately, painting an overly rosy view of the interviewer. A lot of the time your interviewer is just going to be some senior person with an interview guide. They'll be asking you to design Netflix, without any experience with video or streaming themselves. Rather than "trying crazy stuff", I've found that an important step is asking a few questions early in the interview to see if they understand relev…

Interviewing is a two way street. You can judge the company as much as they judge you. If you find yourself in front of such an interviewer then move on somewhere else.

That's entirely valid, but you might have to do a lot of interviewing if you expect every interviewer to be excellent.

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

#307

I think to be frank, this gamification of interviews is BS. I’ve built actual production systems at scale. The fact that I need to follow a guide to “demonstrate” my ability to someone who 9/10 hasn’t built (or couldn’t build) anything at scale in production shows where we are in the absurdity matrix.

Yeah, I don't think I want a job that asks such questions. I've done the webscale BS. I've done actual architecture that exists in reality. At this stage in my career there's nothing an interviewer can do but insult me. You might say that this is hubris about my own skill but it has nothing to do with how good I am. My resume has a LOOONG track record of consistent work in the industry. Call my references, do some ac…

Well said. I’m nearing 30 years industrial experience. The last interview I had was 6 engineers and the HR chick all in the room grilling me. Next time I’ll get up and leave.

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

#308
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…

I'm also a former interviewer from Google. I typically interview people for L6+ roles. What's being called "bias" here may simply be "experience" and a fundamentally different understanding of the System Design interview's purpose. Side note: Systems Design interviews are reserved for "senior" level candidates (L5+). It is a significant inflection point for expectations, as senior-level employees are expected to navi…

It would be great if every interview was like this. But I see system design, even at top tier companies, to be similar to leetcode. An algorithmic problem with a standard solution, where the interviewer is looking for that standard solution. There is more degrees of freedom, but not really. Interviewers are looking for memorized answers from the same few prep materials.

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

#309

Earlier quoted context omitted.

Weird example since letting you take an interview in a different language than they use is very common

I don’t agree because not all interviews work that way, especially for teams that write cpp and c — they don’t let candidates interview in JS for instance. I had a high level eng join a domain specific team I was on and he didn’t do well because he didn’t know the domain very well. He had general skills around leadership and communication that someone of his level should have, and it kept him afloat, but for a high l…

> I don’t agree because not all interviews work that way, especially for teams that write cpp and c — they don’t let candidates interview in JS for instance.

I think this is a bit of a special case since these languages are largely restricted to specialized domains these days. I don't think many people are deciding between building a Web app with Python or C.

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

#310

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…

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

> Maybe that's what you want :shrug:

That just seems rude...but to the larger point, there are a lot of signals that you can pick up if you have the ability...if you have zero ability to read people and you can literally only understand if they are answering abstract technical questions correctly, you as an interviewer would probably better be replaced by a web form.

Post reply on HN