How, exactly, would you do that?
Say you open a new position and you get 100 resumes a day, every day, until you shut down the role and pick someone.
How are you hiring the best candidate overall?
How long are you waiting for "the best"?
How many resumes are you really evaluating per day? With 100 coming in, how do you know you didn't miss "the best" one?
1. https://en.wikipedia.org/wiki/Secretary_problem literally tells you exactly what to do in your situation. I'm sure someone, probably a professor or fun video on social media has told you about this a dozen times in your life, but if you didn't pay attention you can always Google it or ask ChatGPT https://chatgpt.com/share/67d3a121-13e4-8006-9ae3-625838875e...
2. While I said the goal was to hire the best candidate, this was as compared to someone who is just barely better than not filling the position. Hiring a top 5 candidate is also very good. The argument in GP was (paraphrasing) "I know people that aren't good programmers but they can manage to do little changes to existing code therefore you shouldn't give interview problems these dummies can't solve."
I could talk for hours on this subject with concrete examples if anyone ever asked.
I think another problem is that there are so few engineers/architects who really "get it" on this subject. I can only think of a few ex-coworkers with whom I could have the kind of in-depth conversation about app design and organization that I'm picturing.
I've never worked in big tech, always for startups or non-tech corps with a few rock star devs and a lot of decent devs. So maybe it's different at a FAANG. But in my head I'm picturing a bunch of algo-geniuses whose code turns into a big mess over time when requirements take a right-turn and break all their beautiful abstractions. I've worked on a few apps like that and it's not fun.
Your template sounds like a fine way to ask such a question. I think the issue is managers or someone above simply don't want to invest in proper interview questions and instead just do that FAANG does. Even though very few companies need such core algorithmic knowledge but need people who can properly navigate legacy code. FAANGs will actually make sure new hires learn the code base, unlike many companies thst want you to "hit the ground running".
Haha I hate all the code I wrote more than 5 years ago.
But being able to break things down and come up with a solution is not necessarily something that needs to be done quickly, in the time you have for an interview. Quite often I've been faced with a new problem and done absolutely nothing visible for ages. Literally just reading around the problem, asking questions, and sketching in my mind without writing a single line of code.
This is often faster and better than starting immediately.
In a large environment, someone may rarely need to start from nothing, so the interview format throws them.
That said, I think being able to break down a problem to solve it with code is a really important skill. Without it, the person will always have to lean on others to fill that skill gap.