The better way is as the interviewer to do your homework and to engage on the level of the interviewee, so as not to start off with insulting their intelligence. Realize that your company is as much in the hot-seat as the candidate is.
There are plenty of developers that are capable of writing code and explaining how and why they've done it. Your difficulty communicating ideas doesn't directly translate to being a better developer.
>The better way is as the interviewer to do your homework and to engage on the level of the interviewee
I'm not sure you've ever reviewed resumes, but they pretty frequently absolutely suck, targeted or not targeted, or otherwise not accurately representing skills. It can go from completely clueless "buzzword bingo" to "obviously I'm skilled enough to not need to mention the silly stuff like TCP"
>Realize that your company is as much in the hot-seat as the candidate is.
...and for those companies that do understand that?
Where is the substance to this comment? What stance are you taking or solutions you proposing?
I must say, that doesn't check out to me. Writing code is a small part of building apps, and while some organizations have ICs who implement a spec, and a whole team who builds that spec, I think it's clear most orgs would be better off with someone who doesn't require the spec in the first place to figure out what code to write, and doesn't need to be browbeaten to do it in a way that makes sense to their team.
I do not know what this means or what relevance it holds to our context.
> and that usually only one party feels like they need to engage, the other is in a position of power and is the gatekeeper to 'the job' and so feels no need to engage
Again, what are you saying? Recall, we are discussing the very silly claim that "you'll end up with team players but with nobody who will actually get the job done" based on an interview scenario where the interviewee is required to perform part of the problem-solving a job entails, just not a part which is not explicitly implementing a solution alone (coding).
This language about the interviewer not "engaging" and "[not realizing] they represent the company" seems like an entirely separate conversation. Additionally, your usage of "I've seen this numerous times" and initial assumption that the interviewing company would "start off with insulting [the interviewee's] intelligence" don't really make me feel like you're discussing a good-faith interview, instead pre-supposing all interviews are performed in bad faith and interviewees are right to be offended by what they are being ask.
I dislike this muchly, but indeed, the top of this comment tree addresses this attitude directly, something you entirely ignored:
> [As an interviewer], I'm asking [each question] for a reason; you might think it's stupid, but I wouldn't ask if I didn't care what your answer was
So I do not understand why you continued to go forward assuming the interviewing company is acting in bad faith. They are not, that attitude makes no sense, and the context has already directly been set for our conversation that the interviewer is asking this question in good faith because they believe it to be a signal wrt employee value.
Please understand, as someone who interviews, one of the critical filters we introduced was evaluating candidates on their interactivity & collaboration. Doing this explicitly has resulted in a marked uptick in the quality of our candidates. Of course, we still aggressively apply filters that ensure these candidates can code and have implemented solutions of similar complexity & domain as we expect them to architect & create, but introducing the collaboration filter has resulted in coworkers of remarkable ability to solve problems quickly and continuously, both as individuals and in direct collaboration. I would easily say you would fail this filter entirely, and you should take care to not allow your bitter attitude to calcify.