> Similar to leet code style interviews a lot of the times we're not checking for what we need.
right, all interview formats are imperfect...but some are more or less imperfect than others.
a crucial difference in my mind, is that leetcode-on-the-whiteboard style interviews correspond quite poorly to the actual day-to-day job of coding.
a well-prepared system design question, on the other hand, does correspond fairly well to part of the actual job - we have an existing system, it has a performance problem, or needs a new feature we didn't anticipate originally that requires the design to be reworked in some way. and we're sitting in a meeting trying to come up with what we think will be the Least Bad option.
(importantly, the question I like to use is not a greenfield "design Tinder for dogs" / "design Youtube for cats" type of question, because as you say those can be reduced to a formula that candidates can regurgitate, instead I'm intentionally asking a question about a brownfield system that I summarize for them first)
ultimately, that's what I'm probing for with that interview style - I don't particularly care whether a candidate arrives at some "right answer" or not, I'm looking for "do I want to sit in a meeting with you and try to hammer out a design to some non-trivial problem that you and me and other people on the team will then go and implement?"
> a crucial difference in my mind
> a well-prepared system design question
> importantly, the question I like to use
i.e. you're just saying your version is better (than the general 1). Even if I agree with you, that's not the point. The point is that the water is polluted in >80% of the places so anyone coming to drink water will be weary regardless.
> reduced to a formula that candidates can regurgitate
> instead I'm intentionally asking a question about a brownfield system that I summarize for them first
You'll get the filtered version even if you claim your water is clean. The problem isn't the question.
> do I want to sit in a meeting with you and try to hammer out a design
i.e. it's not a technical skills test but a behavioral or personal preference interview. As above but to make it 200% clear I've never done ANY real world system design like I would in ANY interview. So you're not likely going to get this outcome either.
In the real world someone is going to get this task e.g. a principal engineer and they're going to come up with some draft (maybe ask for help for a bit) and then hold a meeting to discuss / refine it. No 1 is creating these diagrams live with other people unless there's some place with enough "architect-level" engineers that have nothing to do. Furthermore, it'd be really expensive if all the stakeholders are present. What you do get is the principal filling different gaps based on different discussions potentially over a week or so.
The discussion potentially happens over many short segments as well, e.g. "should we add a cache (to the performance engineer)" ... (2 hours later) ... "I think we need a WAF, thoughts? (to the security engineer)".
In conclusion you'd not want to sit in a meeting with me and try to hammer out a design because:
- I'm trying to force myself to do something I don't do (and no 1 does) and so it's not the real me
- I'm under pressure from the interview and the broken situation so behaving differently
- I've had so little time to consider your "unique Brownfield" scenario that I'm always going to go with safe options instead of more novel or closer to my personality approaches i.e. again not me
right, all interview formats are imperfect...but some are more or less imperfect than others.
a crucial difference in my mind, is that leetcode-on-the-whiteboard style interviews correspond quite poorly to the actual day-to-day job of coding.
a well-prepared system design question, on the other hand, does correspond fairly well to part of the actual job - we have an existing system, it has a performance problem, or needs a new feature we didn't anticipate originally that requires the design to be reworked in some way. and we're sitting in a meeting trying to come up with what we think will be the Least Bad option.
(importantly, the question I like to use is not a greenfield "design Tinder for dogs" / "design Youtube for cats" type of question, because as you say those can be reduced to a formula that candidates can regurgitate, instead I'm intentionally asking a question about a brownfield system that I summarize for them first)
ultimately, that's what I'm probing for with that interview style - I don't particularly care whether a candidate arrives at some "right answer" or not, I'm looking for "do I want to sit in a meeting with you and try to hammer out a design to some non-trivial problem that you and me and other people on the team will then go and implement?"