3 ms·

> In theory, this should be the easiest discussion to pass while interviewing if you've done some kind of related work or qualified. Instead it's just turning i

> In theory, this should be the easiest discussion to pass while interviewing if you've done some kind of related work or qualified. Instead it's just turning into another insane cargo culted game where you need to do things according to some weird rules and hit certain buzzwords. Your comment reads as if you think system design interviews are good if you can pass them but they are bad if you fail them.

clippy99 1y ago
What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion.
- motorest 1y ago
  > What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion. I think you're trying to rarionalize away the fact that system design involves knowing patterns and how to apply them. In each and every single technical field, it's good to be able to improvise but it's even better to know what you are doing. What you dismiss as "scripted / memorized hoop-jumping experience" actually translates to theoretical and practical knowledge to solve specific problems. Improvisation is a last-resort to fix problems you never faced before. So yeah, this blend of criticism boils down to complaining that the only good tests are the ones you can pass, and everyone who is more experienced, prepared, and outright competent should not given preferential treatment.
  - vincnetas 1y ago
    I think OP is concerned about hiring person who read lots of wikipedia about all types of engines and a person who actually designed and built a simple engine himself. First person can check lots of boxes in interview but could struggle when rubber would meet the road. Second one might look bad, but he can always check wikipedia when needed. (replace wikipedia with AI if needed)
  - sunrunner 1y ago
    > know what you are doing Is blindly copying the same diagrams seen in various GOTO conference slides and ByteByteGo system design newsletters to make sure all the expected parts of your 'architecture' are there really knowing what you are doing, or is it just cargo culting at the level of system design? I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required. Plus if the question is being asked by a company that genuinely could survive on HAProxy and a couple of efficient load-balanced monoliths then it really is cargo culting, especially if you end up with something more complicated then actually required.
    - motorest 1y ago
      > Is blindly copying the same diagrams (...) Do you see any evidence that candidates are blindly copying stuff around? Also, you fail to offer any explanation on why studying systems design topics is supposedly inferior to not studying and just expecting to wing it at job interviews. You only assert that hypothetical candidates indeed have a broader technical background than you, but their knowledge and expertise are useless when compared to your uneducated improvisation skills. Explain why you expect it to make sense? > I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required. Why do you believe this hypothetical scenario is a concern? I mean, either this approach is useless and candidates have no advantage in following it, or this approach is enough to get candidates to outperform you at job interviews. In both scenarios, why do you think that others regurgitating information is a problem?
ddimitrov 1y ago
I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. I'm sure they hired someone who drew a lot of boxes with cute logos because webscale.
- motorest 1y ago
  > I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. It's nice that you estimated throughputs and provided your assessment. Odds are that's not the problem you were tasked to solve? I mean, arguing your way out of proposing a design for scale reads as if you're at a test and you're claiming you shouldn't be asked some questions. > They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. Clarifying questions are an expected part of the process, but by it's own nature the design process is iterative and has a initial design on where to iterate over. If you do not show forward progress or present any tangible design, your own system design skills are immediately called into question as, in the very least, it shows you're succumbing to analysis paralysis. Think about it: you're presented with a problem, and your contribution is to complain about the problem instead of actually offering a solution? What do you think is the output valued by interviewers?
- weq 1y ago
  Regurgitation what amounts to ai slop these days paints a clear picture of your Company to the market. Companies that use l33tcode are filtering out pools of talent, in exchange for monocultures of echo chambers. Makes it easier swing the layoff ax when they need to posture to the market differently. The fact that this ^^^ is run by AI shows just how irrelevant technical interviews like this are these days. Why take a closed book test for a job that you never have to work a day in your life with the book closed? If you are an experienced dev, u can rank other devs pretty quickly with a general conversation about any technology.
tayo42 1y ago
Thinking of it as pass or fail is really the problem. That leads to having some kind of criteria that ends up being gamed. Which is what happened to this style of interviewing. "system design" as it's done now by everyone is a bad interview whether I can pass it or not. You just need to hit the right buzzwords or draw the right boxes. How is that effective?
- motorest 1y ago
  > Thinking of it as pass or fail is really the problem. That leads to having some kind of criteria that ends up being gamed. Which is what happened to this style of interviewing. What do you think a technical interview is? Everyone steps into a job interview hoping to outperform all other candidates in whatever criterias they will be evaluated on. Vibes play a role, but don't you think that being able to demonstrate technical skills matters?
  - tayo42 1y ago
    a technical assessment imo would be more effective if we just talked directly about the topics. If you want to discuss tradeoffs in database choice, just ask about it. Or talk about projects where I actually made those decisions and why. Instead the system design interview has turned into a role playing game where there is a rubric on the other side and you need to hope you hit the topics the interviewer expects. Now it can be memorized. Its detached from reality the same way leetcode questions are and people are memorizing complex answers. This style of interview can be a way to demonstrate technical skills if it allowed it, but instead we have people memorizing how to implement rate limiters or re-designing websites in 30 minutes that have been built up over a decade.

clippy99 1y ago

What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion.

motorest 1y ago
> What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion. I think you're trying to rarionalize away the fact that system design involves knowing patterns and how to apply them. In each and every single technical field, it's good to be able to improvise but it's even better to know what you are doing. What you dismiss as "scripted / memorized hoop-jumping experience" actually translates to theoretical and practical knowledge to solve specific problems. Improvisation is a last-resort to fix problems you never faced before. So yeah, this blend of criticism boils down to complaining that the only good tests are the ones you can pass, and everyone who is more experienced, prepared, and outright competent should not given preferential treatment.
- vincnetas 1y ago
  I think OP is concerned about hiring person who read lots of wikipedia about all types of engines and a person who actually designed and built a simple engine himself. First person can check lots of boxes in interview but could struggle when rubber would meet the road. Second one might look bad, but he can always check wikipedia when needed. (replace wikipedia with AI if needed)
- sunrunner 1y ago
  > know what you are doing Is blindly copying the same diagrams seen in various GOTO conference slides and ByteByteGo system design newsletters to make sure all the expected parts of your 'architecture' are there really knowing what you are doing, or is it just cargo culting at the level of system design? I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required. Plus if the question is being asked by a company that genuinely could survive on HAProxy and a couple of efficient load-balanced monoliths then it really is cargo culting, especially if you end up with something more complicated then actually required.
  - motorest 1y ago
    > Is blindly copying the same diagrams (...) Do you see any evidence that candidates are blindly copying stuff around? Also, you fail to offer any explanation on why studying systems design topics is supposedly inferior to not studying and just expecting to wing it at job interviews. You only assert that hypothetical candidates indeed have a broader technical background than you, but their knowledge and expertise are useless when compared to your uneducated improvisation skills. Explain why you expect it to make sense? > I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required. Why do you believe this hypothetical scenario is a concern? I mean, either this approach is useless and candidates have no advantage in following it, or this approach is enough to get candidates to outperform you at job interviews. In both scenarios, why do you think that others regurgitating information is a problem?

ddimitrov 1y ago

I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. I'm sure they hired someone who drew a lot of boxes with cute logos because webscale.

motorest 1y ago
> I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. It's nice that you estimated throughputs and provided your assessment. Odds are that's not the problem you were tasked to solve? I mean, arguing your way out of proposing a design for scale reads as if you're at a test and you're claiming you shouldn't be asked some questions. > They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. Clarifying questions are an expected part of the process, but by it's own nature the design process is iterative and has a initial design on where to iterate over. If you do not show forward progress or present any tangible design, your own system design skills are immediately called into question as, in the very least, it shows you're succumbing to analysis paralysis. Think about it: you're presented with a problem, and your contribution is to complain about the problem instead of actually offering a solution? What do you think is the output valued by interviewers?
weq 1y ago
Regurgitation what amounts to ai slop these days paints a clear picture of your Company to the market. Companies that use l33tcode are filtering out pools of talent, in exchange for monocultures of echo chambers. Makes it easier swing the layoff ax when they need to posture to the market differently. The fact that this ^^^ is run by AI shows just how irrelevant technical interviews like this are these days. Why take a closed book test for a job that you never have to work a day in your life with the book closed? If you are an experienced dev, u can rank other devs pretty quickly with a general conversation about any technology.

tayo42 1y ago

Thinking of it as pass or fail is really the problem. That leads to having some kind of criteria that ends up being gamed. Which is what happened to this style of interviewing. "system design" as it's done now by everyone is a bad interview whether I can pass it or not. You just need to hit the right buzzwords or draw the right boxes. How is that effective?

motorest 1y ago
> Thinking of it as pass or fail is really the problem. That leads to having some kind of criteria that ends up being gamed. Which is what happened to this style of interviewing. What do you think a technical interview is? Everyone steps into a job interview hoping to outperform all other candidates in whatever criterias they will be evaluated on. Vibes play a role, but don't you think that being able to demonstrate technical skills matters?
- tayo42 1y ago
  a technical assessment imo would be more effective if we just talked directly about the topics. If you want to discuss tradeoffs in database choice, just ask about it. Or talk about projects where I actually made those decisions and why. Instead the system design interview has turned into a role playing game where there is a rubric on the other side and you need to hope you hit the topics the interviewer expects. Now it can be memorized. Its detached from reality the same way leetcode questions are and people are memorizing complex answers. This style of interview can be a way to demonstrate technical skills if it allowed it, but instead we have people memorizing how to implement rate limiters or re-designing websites in 30 minutes that have been built up over a decade.