The problem we have today is that the Cracking the Coding Interview/leetcode grinder approach toward interviewing has now overrun the original purpose of system design interviews. It looks like people that lack the understanding of their purpose, or experience to conduct these interviews properly, now run these interviews, and/or often run the show, writing books/articles/etc, which perpetuate the cargo cult behavior of regurgitating patterns described in some influencer book/article/video.
This is somewhat associated with the title-inflation we've seen in our industry where "senior" and "staff" level engineers today seem to have much less experience than persons with the same titles a decade ago, and the people running these interviews are today's "senior and staff" engineers, or managers with very shallow engineering experience.
Systems design interviews were meant to be non-grindable, open-ended interview questions which allow a very experienced engineer as interviewer to understand the interviewee's experience and approach in solving systems-level problems.
The original purpose of the systems design question in engineering interviews was to:
1) Give the candidate an open-ended question that is not meant to be memorizable or fully solved within the allotted time.
2) Give the candidate an opportunity to shine -- expose and demonstrate areas where they have particular depth from their past work experience
Systems Design interviews employ the judgment of the highly experienced engineer as interviewer, rather than checking for a specific answer.
As an interviewee, the first phase of a systems design interview is really about asking questions to better understand context/constraints/considerations/etc before formulating solutions.
The second phase of a systems design interview is about communicating your understanding of the "whys" and clarifying/refining those understandings with your interviewer.
Ironically, we also have a post on Hacker News today ("The hardest part of building software is not coding, it's requirements") [https://news.ycombinator.com/item?id=36597709] which speaks to the point that systems design interviews really being a test to see how a candidate elicits requirements and considers trade-offs, when developing solutions for problems.
This is somewhat associated with the title-inflation we've seen in our industry where "senior" and "staff" level engineers today seem to have much less experience than persons with the same titles a decade ago, and the people running these interviews are today's "senior and staff" engineers, or managers with very shallow engineering experience.
Systems design interviews were meant to be non-grindable, open-ended interview questions which allow a very experienced engineer as interviewer to understand the interviewee's experience and approach in solving systems-level problems.
The original purpose of the systems design question in engineering interviews was to: 1) Give the candidate an open-ended question that is not meant to be memorizable or fully solved within the allotted time. 2) Give the candidate an opportunity to shine -- expose and demonstrate areas where they have particular depth from their past work experience
Systems Design interviews employ the judgment of the highly experienced engineer as interviewer, rather than checking for a specific answer.
As an interviewee, the first phase of a systems design interview is really about asking questions to better understand context/constraints/considerations/etc before formulating solutions.
The second phase of a systems design interview is about communicating your understanding of the "whys" and clarifying/refining those understandings with your interviewer.
Ironically, we also have a post on Hacker News today ("The hardest part of building software is not coding, it's requirements") [https://news.ycombinator.com/item?id=36597709] which speaks to the point that systems design interviews really being a test to see how a candidate elicits requirements and considers trade-offs, when developing solutions for problems.