4 ms·

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

by nvarsj 4y ago

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 own experience. Because the fields are different and the problems are different. I absolutely had to prepare by spending a lot of time familiarizing myself with big data/internet scale type stuff. Like spending months studying the DDIA book. Which is a lot different from low latency systems. And there's no way I would have passed those system design interviews without doing so. The stark reality is most of the people passing these have prepared heavily and you probably don't pick up on that - because part of the practice (e.g. mock interviews) is to make you sound natural. 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). I think ultimately system design, just like LC interviews, are a proxy for "can you study hard and pass exams". Which is supposed to be a loose proxy for what makes you successful on the job. I have mixed feelings on whether it gets the right people for the job or not.

roguas 4y ago
> Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done. This is something interesting that often is skipped due to "sterile" nature of system design questions(solve puzzle). 90% of system design problems are tightly connected with how your org works internally. Can you depend on particular team or is it better to provide requested functionality internally. This is very often neglected but this moves or breaks stuffs. Imagine you have to build a complete traffic system architecture for the city that will start settling in a year? It will likely be ongoing thing for you, you will observe how street layout works and adjust, build new streets, make city highway from point A to point B etc. but over time. Doing this apriori is going to go horribly bad.
mgraczyk 4y ago
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.
- ZephyrBlu 4y ago
  > 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 Why would you narrow your pool so much, especially when specific experience is usually not what defines higher engineering levels but rather architecture, leadership and communication skills? If someone is actually skilled in system design they would be able to come into a new domain, understand the constraints and design a system within those constraints. People seem to superficially pattern match on experience that looks similar, but doesn't really have that much overlap a lot of the time. My thinking is that most things are far more specific than we realize, so why not mostly forget about specific domain knowledge and focus on applicable high level skills? Domain knowledge is a nice bonus, but you're almost certainly going to have to learn things on the job regardless.
deleted 4y ago
[deleted]
moandcompany 4y ago
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 navigate through and resolve ambiguity. These interviews are not about determining if the candidate can or has solved a particular problem. When a candidate has a particular solution in mind for the presented problem, they better be prepared to explain and justify why. (Take everything I say with a grain of salt, as there's no guarantee that an arbitrary interviewer you encounter shares the following understandings) While Google's interviewing process for tech ladders is deliberately designed to minimize any potential interviewer bias in the process (i.e. the interviewer's role is structured to ask, as a starting point, approved questions and take notes --sometimes verbatim-- on the candidate's response for the hiring committee to make a hiring decision, the Systems Design interview is the one type of interview that does and --should-- rely on the interviewer's judgment. The same Systems Design interview question can be given to candidates across a range of target levels. What may be frustrating for junior candidates in particular is that unlike leetcode or cracking the coding interview questions, these questions are not intended to be or can be "completely solved." There are no specific "correct" answers. There is no book of solutions to be memorized for such questions. This is deliberate, knowing that people try to memorize answers for interviews. This does not mean a candidate can not, nor should not practice how to show their experience. The tenets of systems design questions in engineering interviews are to: 0) Foster collaboration. The interview is about understanding how the candidate goes about solving a problem and understanding their experience solving problems (with others). 1) Give the candidate an open-ended question that is not meant to be memorizable, nor exhaustively solvable within the allotted time. This allows an interviewer/hiring committee to observe and judge a candidate's problem solving approach and experience, versus memorization. 2) Give the candidate an opportunity to show their experience -- The question and approach should be sufficiently broad to allow the candidate to surface areas where they have particular depth from their past work experience, and the interviewer to probe/explore those depths. The interviewer's evaluation of the candidate responses and performance during a systems design interview should include the interviewer's expectations of what a candidate would at least ask or address with the presented problem. Better yet, the interviewer should include what they would expect a candidate for a given target level to address, and further specify what additional things an L+1, L+2, etc would have addressed. Ultimately systems design interviews are not about a candidate's answers for "What" or "How" to build ______, but surfacing a candidate's judgement skills and understanding of the "Whys" along the way.
dilyevsky 4y ago
Like other commenter pointed out you were interviewing for what basically amounts to “tech lead” role without relevant experience. I’m not sure other L4-5s on the team would be happy if someone less experienced is hired in a TL role
- sockgrant 4y ago
  Was on a team this happened on and a lot of the l4 l5 Eng gossiped about how little our L7 knew
  - emodendroket 4y ago
    I don't think someone gossiping about how their work superiors are fools is really notably strange to be honest.
    - dilyevsky 4y ago
      I dunno where you worked but this is def not normal at least within technical ladder ime
- nvarsj 4y ago
  Big tech interviews aren't team specific or even experience specific (with some exceptions). Teams do a wide variety of work, including stuff similar to low latency C++/Java, and team selection doesn't happen until after passing interviews. It's not really a question of relevant experience at all - it's about passing the standardized exam that is a big tech interview. Experience comes more into play when doing team selection afterwards.
thrashh 4y ago
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 essentially were switching specializations.
- ZephyrBlu 4y ago
  Is that the highest order bit when you're hiring someone though? For almost all roles, I don't think it is.
  - thrashh 4y ago
    No but for a popular job listing in a well known company with hundreds of applicants, there are going to be dozens of people who have similar experience as you, plus have the exact qualification that they are asking for, putting you at an automatic disadvantage.
- emodendroket 4y ago
  Weird example since letting you take an interview in a different language than they use is very common
  - sockgrant 4y ago
    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 level technical IC you need to be at worst fluent in the domain and at best a technical leader in the group. At lower levels of IC generalist is fine, the blast radius of your technical decisions is smaller so it’s less risky to learn on the job. But yeah, not knowing the domain you’re going to join, whether it’s a type of work or a programming language, you won’t be as effective.
Hermitian909 4y ago
> 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.
emodendroket 4y ago
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.
fatnoah 4y ago
> 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). A few years ago, I did my round of "big tech" interviews as a manager and was somewhat naive in that I did zero prep work, but I did have almost 2 decades of actually building systems. I found system design to be the "easy" and fun part of the process (including at Google). However, if I didn't have experience with scaling and redundancy in web applications, it wouldn't have been nearly as fun. That said, once I was in the door (different big tech co), there was absolutely zero need for any of that knowledge. Now that I'm back at a startup, it's all relevant again!

by nvarsj 4y ago

roguas 4y ago

> Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done. This is something interesting that often is skipped due to "sterile" nature of system design questions(solve puzzle). 90% of system design problems are tightly connected with how your org works internally. Can you depend on particular team or is it better to provide requested functionality internally. This is very often neglected but this moves or breaks stuffs. Imagine you have to build a complete traffic system architecture for the city that will start settling in a year? It will likely be ongoing thing for you, you will observe how street layout works and adjust, build new streets, make city highway from point A to point B etc. but over time. Doing this apriori is going to go horribly bad.

mgraczyk 4y ago

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.

ZephyrBlu 4y ago
> 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 Why would you narrow your pool so much, especially when specific experience is usually not what defines higher engineering levels but rather architecture, leadership and communication skills? If someone is actually skilled in system design they would be able to come into a new domain, understand the constraints and design a system within those constraints. People seem to superficially pattern match on experience that looks similar, but doesn't really have that much overlap a lot of the time. My thinking is that most things are far more specific than we realize, so why not mostly forget about specific domain knowledge and focus on applicable high level skills? Domain knowledge is a nice bonus, but you're almost certainly going to have to learn things on the job regardless.

deleted 4y ago

[deleted]

moandcompany 4y ago

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 navigate through and resolve ambiguity. These interviews are not about determining if the candidate can or has solved a particular problem. When a candidate has a particular solution in mind for the presented problem, they better be prepared to explain and justify why. (Take everything I say with a grain of salt, as there's no guarantee that an arbitrary interviewer you encounter shares the following understandings) While Google's interviewing process for tech ladders is deliberately designed to minimize any potential interviewer bias in the process (i.e. the interviewer's role is structured to ask, as a starting point, approved questions and take notes --sometimes verbatim-- on the candidate's response for the hiring committee to make a hiring decision, the Systems Design interview is the one type of interview that does and --should-- rely on the interviewer's judgment. The same Systems Design interview question can be given to candidates across a range of target levels. What may be frustrating for junior candidates in particular is that unlike leetcode or cracking the coding interview questions, these questions are not intended to be or can be "completely solved." There are no specific "correct" answers. There is no book of solutions to be memorized for such questions. This is deliberate, knowing that people try to memorize answers for interviews. This does not mean a candidate can not, nor should not practice how to show their experience. The tenets of systems design questions in engineering interviews are to: 0) Foster collaboration. The interview is about understanding how the candidate goes about solving a problem and understanding their experience solving problems (with others). 1) Give the candidate an open-ended question that is not meant to be memorizable, nor exhaustively solvable within the allotted time. This allows an interviewer/hiring committee to observe and judge a candidate's problem solving approach and experience, versus memorization. 2) Give the candidate an opportunity to show their experience -- The question and approach should be sufficiently broad to allow the candidate to surface areas where they have particular depth from their past work experience, and the interviewer to probe/explore those depths. The interviewer's evaluation of the candidate responses and performance during a systems design interview should include the interviewer's expectations of what a candidate would at least ask or address with the presented problem. Better yet, the interviewer should include what they would expect a candidate for a given target level to address, and further specify what additional things an L+1, L+2, etc would have addressed. Ultimately systems design interviews are not about a candidate's answers for "What" or "How" to build ______, but surfacing a candidate's judgement skills and understanding of the "Whys" along the way.

dilyevsky 4y ago

Like other commenter pointed out you were interviewing for what basically amounts to “tech lead” role without relevant experience. I’m not sure other L4-5s on the team would be happy if someone less experienced is hired in a TL role

sockgrant 4y ago
Was on a team this happened on and a lot of the l4 l5 Eng gossiped about how little our L7 knew
- emodendroket 4y ago
  I don't think someone gossiping about how their work superiors are fools is really notably strange to be honest.
  - dilyevsky 4y ago
    I dunno where you worked but this is def not normal at least within technical ladder ime
nvarsj 4y ago
Big tech interviews aren't team specific or even experience specific (with some exceptions). Teams do a wide variety of work, including stuff similar to low latency C++/Java, and team selection doesn't happen until after passing interviews. It's not really a question of relevant experience at all - it's about passing the standardized exam that is a big tech interview. Experience comes more into play when doing team selection afterwards.

thrashh 4y ago

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 essentially were switching specializations.

ZephyrBlu 4y ago
Is that the highest order bit when you're hiring someone though? For almost all roles, I don't think it is.
- thrashh 4y ago
  No but for a popular job listing in a well known company with hundreds of applicants, there are going to be dozens of people who have similar experience as you, plus have the exact qualification that they are asking for, putting you at an automatic disadvantage.
emodendroket 4y ago
Weird example since letting you take an interview in a different language than they use is very common
- sockgrant 4y ago
  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 level technical IC you need to be at worst fluent in the domain and at best a technical leader in the group. At lower levels of IC generalist is fine, the blast radius of your technical decisions is smaller so it’s less risky to learn on the job. But yeah, not knowing the domain you’re going to join, whether it’s a type of work or a programming language, you won’t be as effective.

Hermitian909 4y ago

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

emodendroket 4y ago

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.

fatnoah 4y ago

> 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). A few years ago, I did my round of "big tech" interviews as a manager and was somewhat naive in that I did zero prep work, but I did have almost 2 decades of actually building systems. I found system design to be the "easy" and fun part of the process (including at Google). However, if I didn't have experience with scaling and redundancy in web applications, it wouldn't have been nearly as fun. That said, once I was in the door (different big tech co), there was absolutely zero need for any of that knowledge. Now that I'm back at a startup, it's all relevant again!