Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

271–280 of 399 posts

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

#271
post #159

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…

Even if you do have the exact kind of experience they're looking for, the interviews usually are built around an assumption like "this system needs to be built from day one to scale to massive traffic" which is not the way projects usually are approached in the real world.

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

#272
post #97

Earlier quoted context omitted.

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.

How could you ever interview anywhere if you couldn't provide details of the projects that you worked on?

Leetcode questions?

(Don't kill me, you all. I'm joking).

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

#273

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…

Yup, exactly this. The easiest way to weed out bad candidates is to listen to all the buzzwords they rattle out and ask them to explain a single one and how it is relevant to their design.

My first instruction to candidates always is – only talk about things you know. If your system design interview prep book told you that you should use time series databases for a certain category of questions but you don't actually know how they work, you will be screwed by trying to incorporate them in your design. Just use MySQL instead and tell me its pros and cons for this use case.

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

#274
post #268

Earlier quoted context omitted.

"Great, that'll do nicely. Vacuum cleaners are complicated and interesting machines. What can you tell me about how a vacuum cleaner is built and how it works? Also, vacuum cleaners are pretty old tech. Is there room for further innovation in that area? If so, what angles would you explore if you worked at a vacuum cleaner company?"

This is a great way to get BS'd into thinking someone is qualified when they're not. Work sample tests are all you need.

"Awesome, then you've got nothing to worry about!"

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

#275

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

"I'm known for hiring the best engineers". BUT if you're really known for hiring the best engineers, please show us your accomplishments! You just told us you look for trivia which means you're great at hiring engineers who are good at language trivia. That set has a pretty small overlap with "best" engineers. "Best" itself has a small overlap with "useful" engineers. Your trivia knowledge is great to impress like mi…

This is not trivia. For better or for worse truthy evaluation is a fundamental part of the language which is what this code snippet appears to be primarily testing.

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

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

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

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

#277

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…

> 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. I'm very surprised by this recommendation which doesn't match my experience at all. First, lots of candidates don't have experience building such systems, so they need to learn by reading books and articles. Second, the candidates need to be familiar wi…

I can't say about other companies but I have personally done many, many of these interviews over the years and can say with 100% confidence that someone who has spent days/weeks/months studying system design interview material but not had any actual experience building such systems in a production setting will get weeded out in the first few minutes.

Now some interview prep might actually help a lot of people, but it will help you better present your existing knowledge, not replace it.

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

#278

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…

> 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 2 years (by their own admission).

Left a sour taste.

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

#279

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.

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. Everyone has lofty resumes with the choicest buzzwords. Everyone can come up with war stories about how they single-handedly kept the internet alive. And everyone can write the names of a dozen references who can vouch for all of this.

The moment you start to test these claims, 90% of these candidates cannot write a line of code or describe a simple distributed system by drawing a few boxes on a whiteboard. So the current process is what we end up with.

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

Post reply on HN