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

261–270 of 399 posts

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

#261

Post by shepherdjerred »

fatneckbeard wrote: post #250

i am having a problem understanding why FAANG is gatekeeping system design google - search is broke, youtube doesnt make money and is a hotbed of predators facebook - should basically be in prison for aiding war crimes and child suicides netflix - is quickly circling the drain because you can't algorithm creativity amazon - almost all of their products and services lose money apple - siri is slightly better than stub…

What are you suggesting? That these companies have poor system design? That they don't need to hire smart technically minded engineers because their problems aren't technical?

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

#262

Post by leonidasv »

ditonal wrote: post #75
moandcompany wrote: post #65

Earlier quoted context omitted.

One of the "heavy practice/coaching/leetcode grinding" signals is when the interviewee immediately dives into proposing a solution and discusses facets of that solution in great detail without bothering to ask clarifying questions or discussing assumptions and the risks/consequences of those assumptions.

I think the opposite is true. An experienced engineer not as versed in interview prep might hear the question to design something, and go ahead and show how they would design it based on their experience doing it in the real world. The leetcode grinder would almost certainly ask clarifying questions since it’s heavily emphasized as part of the rubric in pretty much all system design interview prep material. Of course…

The business goal of interviews is not to select the best one, but to narrow down candidates with an acceptable fit for the role.

An interview system with a high false-negative rate is not seem as problematic if the false-positive rate is also low. The cost of not hiring a very good candidate is way lower than the cost of hiring a bad one (even considering the opportunity cost in most cases).

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

#263

Post by [deleted] »

kridsdale1 wrote: post #218
rednerrus wrote: post #207

Earlier quoted context omitted.

We don’t ask people to describes systems the worked on previously. We ask them to diagram a technical system that they understand well.

If you are an expert one one system that you have built and maintained for ten years, then that’s all you know.

[deleted]

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

#264

Post by Existenceblinks »

Existenceblinks wrote: post #185
John23832 wrote: post #100

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 like to work with companies that make a lot of profit on their 5 digit customers where Single machine is enough. But we can make it 3 behind an LB. I absolute hate business whose infra is a bunch of message broker, lambda, queue .. yet make little money.

Addendum (since quite many upvotes): for the latter, they break a team of 8 (this is already a small team apart from the whole org) into 2 teams each 4 and break a monolith app into 2 microservices. At the time I saw that, the company started to have more and more managers. Guess what, not even making a break-even yet!

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

#265

Post by tourist2d »

mlhpdx wrote: post #152
azornathogron wrote: post #30

Earlier quoted context omitted.

I like this... in theory. But I don't think I'm allowed to give you a system diagram and detailed explanation of systems I've worked on, because obviously they're proprietary. That seems like a problem. How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they've worked on?

Show me a system you’ve worked on that wasn’t put together from knowledge from previous education and jobs (yours and others), documentation from vendors, stack overflow, code generators , etc. I would hate to be a stakeholder in a company whose value depends on employees not talking about and reusing the incremental skills and knowledge gained while working there.

NDAs don't care where you sourced your knowledge from.

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

#268

Post by Jach »

CamperBob2 wrote: post #254
ikiris wrote: post #230

Earlier quoted context omitted.

Sure, I'd like to draw a vaccum cleaner, because this interview seems to suck and be unrelated to my job role. :)

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

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

#269

Post by John23832 »

nonethewiser wrote: post #120
John23832 wrote: post #100

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 guess I'm not sure if you're suggesting otherwise, but gamification is not unique to interviews. It's a natural response to any system that relies on metrics or measurements. The request to design a theoretical system is gamification as much the guide for answering it is. These games exist because it elicits answers that can be used to learn about someone's real experience level. It's great that you feel confident…

Paper designs have very little to do with production systems.

It’s like trusting a doctor fresh out of medical school without residency.

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

#270

Post by emodendroket »

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…

> The purpose of the system design interview is to convince me that you could build, or lead a team to build, the thing that we are discussing at a company like the one where you are interviewing. 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. Unless you are interviewing somewhere with very inexperienced interviewers...

I don't agree with this because I bombed a couple interviews till I spent the time going through the prep. I distinctly remember an interview completely going off the rails because I was asked about a retail Web site and said "honestly I'd usually start with a simple app server - SQL database setup to start; no reason for the complexity of anything more complex till you've proven you've got the traffic and have scaling problems." That's my honest opinion, borne out by real-world experience, for most people thinking of doing something like that, but it obviously wasn't what the interviewer wanted to hear and it's not like I would have been capable of giving a fancier design; I just didn't know how you're supposed to approach the question.

Post reply on HN