Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

241–250 of 399 posts

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

#241
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.

Sure. But the level of description that you're giving in an interview can be pretty generic/non-proprietary. If that wasn't the case, then you really can't reuse any knowledge from job to job and that's just not so. Sure, every company is going to have their 'special sauce' components, that ARE proprietary, but nobody's going to expect you to unpack those.

I doubt it's common, but my friend had an experience where they kept trying to direct him towards specific technical topics of particular interest to the business.

He worked for their competitor, but not in the capacity the interviewer was trying to delve into, so in addition to scummy, it was pointless and annoying.

At some point my friend cut the interview off.

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

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

Is that the highest order bit when you're hiring someone though? For almost all roles, I don't think it is.

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

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

> Now that I'm in the system, the other stark reality is that little of this system design matters. Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done (like pretty much every big company).

Having been on the "support" side of an engineering org (supporting teams building product features) the thing I've noticed is that if you don't maintain a certain "density" of people with these system design skills things start to go off the rails. People start showing up with designs resting on some very fundamental misunderstandings or designed with no eye towards simplicity and things turn dysfunctional quickly.

It's worth noting that there are also better and worse designed system design interviews. Good ones give space to demonstrate "taste" as well as technical chops.

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

#244
post #128

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

I’m going to be way more strict about confidentiality with an interviewer I don’t know at all than with a trusted colleague. For all I know you get beers every week with the CTO of my current employer’s largest competitor.

Besides which there’s a way more interesting variation on the question, which is “how would you design our product?” Got that one in my last big tech interview and quite enjoyed it.

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

#245

Earlier quoted context omitted.

This is a pretty common situation in the US for folks who work on government contracts.

Yup. I’m outside DC. Somewhere near half my software engineer (and adjacent fields) friends are under contract to either the military or NSA/CIA. Most of them with TS/poly clearances. Ask one of the what they’re working on and the most you’ll get is something like “dig data on platform X”. If platform X is something public, they could talk about the platform. But, talking about any project specifics, implementation d…

[flagged]

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

#246

Earlier quoted context omitted.

I somewhat take issue with this. (3+ decades of very hands on (read: coding) architecting, including some learning experiences in orbit. I've been coding code-doodling since teenage years.) A lot of what non-coding architects traditionally brought to the table has been taken over by experts designing OSS protocols, data formats, etc. Take things like data frames that are now exploding in ML space. Seniors today, agre…

I always thought that non-coding architects still had at least some background in coding. What does the path of a never-had-coded architect looks like?

DBA or sysadmin, I would imagine. So more “never wrote application code” than “never wrote a single line of code for anything ever.”

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

#247

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

Ok if not cache then it must be hashtable?

To crack any IT interview, just breadth-first search the hashtable in a dictionary and you're golden.

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

#248
post #94

Earlier quoted context omitted.

If you havent designed a system from scratch, or designed a major change, you arent a senior engineer.

these "system design interviews" often focus on systems at the scale of major consumer internet companies, e.g. "design youtube", "design twitter". How many systems of that scale even exist? 100? Only the core developers of those systems would be considered "senior engineer"?

It doesn’t take a ton of scale to hit limits in traditional 3 tier architecture. I think many many companies have similar designs but built with OSS.

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

#249
Interviewing (especially system design) is a skill you have to learn these days. It's also a performance. You can complain about how flawed it is all day, and believe me I do (I'm a staff FAANG swe), but you gotta play the game. Knowing how to methodically break down the problem into smaller components and be able to confidently present the information in a manner that's easy to follow/collaborate is actually a real on-the-job skill of any experienced engineer. You have to be able to demonstrate this in an interview. The people at interviewing.io are legit and this guide is a great prep tool

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

#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 stubbing your toe on a sharp metal object

Post reply on HN