24 ms·

> I have never in my career had to do anything like designing a large scale system. Giving large scale system design interview questions for a role where someo

> I have never in my career had to do anything like designing a large scale system. Giving large scale system design interview questions for a role where someone never has to work with large scale systems would be a weird cargo cult choice. However, when a job involves working with large scale systems, it's important to understand the bigger picture even if you're never going to be the one designing the entire thing from scratch. Knowing why decisions were made and the context within which you're operating is important for being able to make good decisions. > I've worked with the Linux kernel, I've written device drivers, I've programed in everything from Fortran to Go, and that's what I want to keep doing. Why put me through this? If you were applying to a job for Linux kernel development, device driver development, and Fortran then I wouldn't expect your interviewers to ask about large scale distributed web development either. However, if you're applying to a job that involves doing large scale web development, then your experience writing Linux kernel code and device drivers obviously isn't a substitute for understanding these large scale system design questions.

nineplay 3y ago
The problem is that the system design interview somehow became a necessary component of the FAANG hiring process.
- Zetice 3y ago
  Why would you interview for a role at a FAANG company in the first place?
  - nineplay 3y ago
    In retrospect it was a horrible mistake.
  - bagels 3y ago
    They pay a lot?
  - scarface_74 3y ago
    They want to exchange the most money possible for their labor ?
    - Zetice 3y ago
      This isn’t true, and even if it were, “most money possible” isn’t a meaningful metric.
      - scarface_74 3y ago
        So what companies pay on average than FAANG[1] for developers. The most money possible is far from meaningless. If I work for a company, which one will deposit the most in my bank account in a year and/or the most in my brokerage account when my stock vests? [1] not literally FAANG, the most profitable public tech companies
        Zetice 3y ago
        Most Fortune 100 companies are competitive now, and the most money is extremely meaningless.
        scarface_74 3y ago
        I assure you that the other Fortune 100 companies are not paying even in the same ball park as Facebook, Apple, Amazon, and Google. https://finasko.com/fortune-100-companies/ https://finasko.com/fortune-100-companies/ What do you think the average compensation of those companies are? I’m well aware of the comp levels at at least three of those companies because they are based in my former home town - Delta, Home Depot and Coke. They pay their senior devs about the same amount as an intern I mentored got as a return offer (cash + stock).
        Zetice 3y ago
        I can assure you they are absolutely paying in the same ballpark as Facebook, Apple, Amazon, Google, you just don't know how to limit your searches to the tech roles.
  - tester756 3y ago
    They do some impressive stuff
  - palata 3y ago
    Salary, I suppose?
- zoover2020 3y ago
  Is this a problem? I would argue that this style of interviewing is much more relastic to day-to-day activities than leetcode
  - weego 3y ago
    You'd be arguing wrong imo. No one sits down solo and has to design a system to scale in isolation,and if you do then something up the chain from that moment went very wrong. It's a pointless academia by proxy situation that encourages filling out teams with the kids of people who csn architect and tinker forever but have no capability to actually deliver software anyone wants to use. This becomes more clear when you look across the last 10 years in FAANG and list out what products have actually been delivered that are improvements to users and customers vs what's just infrastructure padding and bought in though acquisition.
    - greiskul 3y ago
      In both FAANG jobs I had I was expected to design systems solo, and then review them with my team. If the system is complex enough, I would probably whiteboard it first with some teammates while I was designing it. It is something that was asked of me in interviews, and comes up often in my day to day job. And being able to design systems, and to help review systems others are designing, is probably the single biggest impact thing I do regularly. It is more useful in day to day than the algorithmic knowledge that was also asked of me during interviews. While there are people that do use complex algorithms in both companies, most software of Google is converting a protocol buffer into another protocol buffer, and in Amazon is the same thing but with JSON. If you are a frontend engineer, you might convert into HTML by plugging the values into a template engine.
- SpicyLemonZest 3y ago
  FAANG and similar companies typically subscribe to something like the "T shaped engineer" philosophy. They're making a conscious choice that their engineers should be comfortable in discussions about distributed systems, performance tradeoffs, etc. regardless of whether they do such things on a regular basis.
- duckfruit 3y ago
  Certainly not at the FAANG I work at. We hire specialized engineers to work on device drivers and OS kernels and absolutely do not ask them questions on how to design distributed web services. I encourage you to apply: https://www.apple.com/careers/us/ https://www.apple.com/careers/us/
- babyshake 3y ago
  And the second part of this is that just as all non-rich people tend to consider themselves as soon to be millionaires temporarily down on their luck, most startups (especially the VC funded ones making big promises to investors) tend to consider themselves soon to be FAANGs temporarily in the early phase of their inevitable hockey stick growth.
- greiskul 3y ago
  My understanding is that this is not the case any more for the more junior software engineer positions in Google and in Amazon, which are expected to them learn system design before being promoted. If you are applying to a more senior position, then yes, there should be a question about system design, and yes, you will probably be doing system design in your work, so it's completely fair game.
lisasays 3y ago
You missed the key statement in the commenter's post: "If that's a requirement just say so" Clearly the roles they're applying for are not concerned with the ab initio design of large-scale systems. Which is why they said what they said. They're not whining for the sake of whining. Your experience writing Linux kernel code and device drivers obviously isn't a substitute for understanding these large scale system design questions. A drop-in substitute, no. But an engineer who has the wherewithal to truly master the grisly low-level stuff can easily ramp up reasonably quickly in the large scale stuff as well, if needed. To not understand this is to not understand what makes good engineers tick. We get the fact that, yeah, sometimes, for certain roles a certain level of battle-tested skills are needed in any domain. Nonetheless, there's an epidemic of overtesting (from everything to algorithms, to system design, to "culture fit") coursing through the industry's veins at present. Combined with a curious (and sometimes outright bizarre) inability of these companies to think about what's truly required for the roles -- and to explain in simple, plain English terms what these requirements are in the job description, and to design the interview process accordingly.
taeric 3y ago
Oddly, knowing the limitations of last year's designs can, as often, limit you to last year's solutions. That is to say, the reason things were done in the past almost always come down to resourcing constraints. Yes, it is good to understand constraints. It is also incredibly valuable to be respectful of the constraints that folks were working on before you got there. Even better to be mindful of the constraints you are working on today, as well. With an eye for constraints coming down the line. But, evidence is absurdly clear that large systems are grown far more effectively than they are designed. My witticism in the past that none of the large companies were built with the architectures that we seem to claim are required for growth and success. Worse, many of them were actively done with derision for "best practices" coming from larger companies. Consider, do you know all of the design choices and reasons behind such things as the old Java GlassFish server? Even more amusing, is to watch the slow tread of JSON down the path that was already covered by XML. In particular the attempts at schemas and namespaces.
- jjoonathan 3y ago
  > large systems are grown far more effectively than they are designed It's easy to bake in poorly scaling technical decisions at an early stage that take an obscene amount of engineering effort to undo once the scaling problem become obvious. I've seen intern-days of "savings" turn into senior-years of rework and the scale in my corner of the world is tiny by SV standards. I always assumed that SV companies experienced similar traumatic misadventures, multiplied up by scale, and baked "thinking at scale" into their technical interviews as a crude (but probably somewhat effective) countermeasure. Even if you only ever use the knowledge one time, indirectly and accidentally, by peer-pressuring your buddy into thinking before coding and therefore avoid a $10M landmine, it was all worthwhile.
  - vsareto 3y ago
    If they know the code base well, it shouldn't be that hard to undo intern-level shortcuts. There's another failing here which is that quality wasn't gated well enough.
    - 3y ago
heisenbit 3y ago
I have really good analytical skills which I leverage to tackle issues in large scale system piecewise. I have to suspend my skeptical mind and switch to blue hat thinking to come up with something from scratch. Then I take it apart and iterate over it. I don't think large scale system design is a straightforward process and pretending it is so may very well lead to living in interesting times.
deleted 3y ago
[deleted]

nineplay 3y ago

The problem is that the system design interview somehow became a necessary component of the FAANG hiring process.

Zetice 3y ago
Why would you interview for a role at a FAANG company in the first place?
- nineplay 3y ago
  In retrospect it was a horrible mistake.
- bagels 3y ago
  They pay a lot?
- scarface_74 3y ago
  They want to exchange the most money possible for their labor ?
  - Zetice 3y ago
    This isn’t true, and even if it were, “most money possible” isn’t a meaningful metric.
    - scarface_74 3y ago
      So what companies pay on average than FAANG[1] for developers. The most money possible is far from meaningless. If I work for a company, which one will deposit the most in my bank account in a year and/or the most in my brokerage account when my stock vests? [1] not literally FAANG, the most profitable public tech companies
      - Zetice 3y ago
        Most Fortune 100 companies are competitive now, and the most money is extremely meaningless.
        scarface_74 3y ago
        I assure you that the other Fortune 100 companies are not paying even in the same ball park as Facebook, Apple, Amazon, and Google. https://finasko.com/fortune-100-companies/ https://finasko.com/fortune-100-companies/ What do you think the average compensation of those companies are? I’m well aware of the comp levels at at least three of those companies because they are based in my former home town - Delta, Home Depot and Coke. They pay their senior devs about the same amount as an intern I mentored got as a return offer (cash + stock).
        Zetice 3y ago
        I can assure you they are absolutely paying in the same ballpark as Facebook, Apple, Amazon, Google, you just don't know how to limit your searches to the tech roles.
- tester756 3y ago
  They do some impressive stuff
- palata 3y ago
  Salary, I suppose?
zoover2020 3y ago
Is this a problem? I would argue that this style of interviewing is much more relastic to day-to-day activities than leetcode
- weego 3y ago
  You'd be arguing wrong imo. No one sits down solo and has to design a system to scale in isolation,and if you do then something up the chain from that moment went very wrong. It's a pointless academia by proxy situation that encourages filling out teams with the kids of people who csn architect and tinker forever but have no capability to actually deliver software anyone wants to use. This becomes more clear when you look across the last 10 years in FAANG and list out what products have actually been delivered that are improvements to users and customers vs what's just infrastructure padding and bought in though acquisition.
  - greiskul 3y ago
    In both FAANG jobs I had I was expected to design systems solo, and then review them with my team. If the system is complex enough, I would probably whiteboard it first with some teammates while I was designing it. It is something that was asked of me in interviews, and comes up often in my day to day job. And being able to design systems, and to help review systems others are designing, is probably the single biggest impact thing I do regularly. It is more useful in day to day than the algorithmic knowledge that was also asked of me during interviews. While there are people that do use complex algorithms in both companies, most software of Google is converting a protocol buffer into another protocol buffer, and in Amazon is the same thing but with JSON. If you are a frontend engineer, you might convert into HTML by plugging the values into a template engine.
SpicyLemonZest 3y ago
FAANG and similar companies typically subscribe to something like the "T shaped engineer" philosophy. They're making a conscious choice that their engineers should be comfortable in discussions about distributed systems, performance tradeoffs, etc. regardless of whether they do such things on a regular basis.
duckfruit 3y ago
Certainly not at the FAANG I work at. We hire specialized engineers to work on device drivers and OS kernels and absolutely do not ask them questions on how to design distributed web services. I encourage you to apply: https://www.apple.com/careers/us/ https://www.apple.com/careers/us/
babyshake 3y ago
And the second part of this is that just as all non-rich people tend to consider themselves as soon to be millionaires temporarily down on their luck, most startups (especially the VC funded ones making big promises to investors) tend to consider themselves soon to be FAANGs temporarily in the early phase of their inevitable hockey stick growth.
greiskul 3y ago
My understanding is that this is not the case any more for the more junior software engineer positions in Google and in Amazon, which are expected to them learn system design before being promoted. If you are applying to a more senior position, then yes, there should be a question about system design, and yes, you will probably be doing system design in your work, so it's completely fair game.

lisasays 3y ago

You missed the key statement in the commenter's post: "If that's a requirement just say so" Clearly the roles they're applying for are not concerned with the ab initio design of large-scale systems. Which is why they said what they said. They're not whining for the sake of whining. Your experience writing Linux kernel code and device drivers obviously isn't a substitute for understanding these large scale system design questions. A drop-in substitute, no. But an engineer who has the wherewithal to truly master the grisly low-level stuff can easily ramp up reasonably quickly in the large scale stuff as well, if needed. To not understand this is to not understand what makes good engineers tick. We get the fact that, yeah, sometimes, for certain roles a certain level of battle-tested skills are needed in any domain. Nonetheless, there's an epidemic of overtesting (from everything to algorithms, to system design, to "culture fit") coursing through the industry's veins at present. Combined with a curious (and sometimes outright bizarre) inability of these companies to think about what's truly required for the roles -- and to explain in simple, plain English terms what these requirements are in the job description, and to design the interview process accordingly.

taeric 3y ago

Oddly, knowing the limitations of last year's designs can, as often, limit you to last year's solutions. That is to say, the reason things were done in the past almost always come down to resourcing constraints. Yes, it is good to understand constraints. It is also incredibly valuable to be respectful of the constraints that folks were working on before you got there. Even better to be mindful of the constraints you are working on today, as well. With an eye for constraints coming down the line. But, evidence is absurdly clear that large systems are grown far more effectively than they are designed. My witticism in the past that none of the large companies were built with the architectures that we seem to claim are required for growth and success. Worse, many of them were actively done with derision for "best practices" coming from larger companies. Consider, do you know all of the design choices and reasons behind such things as the old Java GlassFish server? Even more amusing, is to watch the slow tread of JSON down the path that was already covered by XML. In particular the attempts at schemas and namespaces.

jjoonathan 3y ago
> large systems are grown far more effectively than they are designed It's easy to bake in poorly scaling technical decisions at an early stage that take an obscene amount of engineering effort to undo once the scaling problem become obvious. I've seen intern-days of "savings" turn into senior-years of rework and the scale in my corner of the world is tiny by SV standards. I always assumed that SV companies experienced similar traumatic misadventures, multiplied up by scale, and baked "thinking at scale" into their technical interviews as a crude (but probably somewhat effective) countermeasure. Even if you only ever use the knowledge one time, indirectly and accidentally, by peer-pressuring your buddy into thinking before coding and therefore avoid a $10M landmine, it was all worthwhile.
- vsareto 3y ago
  If they know the code base well, it shouldn't be that hard to undo intern-level shortcuts. There's another failing here which is that quality wasn't gated well enough.
  - 3y ago

heisenbit 3y ago

I have really good analytical skills which I leverage to tackle issues in large scale system piecewise. I have to suspend my skeptical mind and switch to blue hat thinking to come up with something from scratch. Then I take it apart and iterate over it. I don't think large scale system design is a straightforward process and pretending it is so may very well lead to living in interesting times.

deleted 3y ago

[deleted]