In most of my programming jobs, explaining your work was most of the job and writing code was less important.
The whiteboard environment is a bit unnatural but I don’t want to hire someone who gets the right answer if they can’t explain it to me.
That's not what is being asked. It's explaining your thought process while actively doing the work in an "unnatural" environment.
> The whiteboard environment is a bit unnatural
I don't know anyone that codes on a whiteboard.
> but I don’t want to hire someone who gets the right answer if they can’t explain it to me.
Again, that's not what is being asked. They are being asked to explain their work before they get an answer.
In short, that’s a limitation of the study.
The study is comparing “explain your thought process aloud as you solve the problem” against “solve the problem by yourself and don’t explain anything”. There’s a whole range of sensible middle options, like “solve the problem by yourself and explain it afterwards” or “solve the problem with the interviewer and then explain it”.
I’ll say for sure, not everyone interviews this way. A lot of devs running interviews think of it as a “test” with pass/fail. I’d say the better interviewers see it as an opportunity to dig around and figure out how to get evidence of the candidate’s skills. That means being creative, that means responding to what the candidate says and finding opportunities to focus on their strengths.
I don't think this necessarily means the "answer question alone and present answer after" approach is the right solution to interviewing, but it does show that interviewers might need to take some steps to make the process less opaque and daunting to lower candidates' potential anxiety.
From my direct knowledge of some “top firms”, if you only cared about correctness then you wouldn’t be able to fill out the interview feedback form.
Transparency may help, but in my experience, that’s what recruiters actually do and some of them are fairly good at it. The recruiter has a strong incentive to get you hired (they get bonuses for hiring people!) and will explain as much of the process as they can, if you are willing to listen.
That said, there seems to be a fair bit of turnover in tech recruiting.
And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out.
Perhaps what we should be working towards is making it more transparent- it's still ubiquitous for candidates to be rejected without feedback- and more objective, and improving the technical interview process further. I'm not arguing for throwing out the baby with the bathwater.
Versus explaining your code to your coworker whom you've worked with for the past X time who understands some of your eccentricities or idiosyncrasies and without a pass/fail judgment lingering over your head like a sword of Damocles.
I say that as someone who cares a lot about writing easy to read code and has no problem explaining it. Also, I'm very bad at solving a problem while being required to think out loud.
Sometimes this explaining happens in textual format, like code reviews and design specifications, but often it happens verbally. Absent an explanation, it's hard to build consensus among the parties involved (co-workers, users, management) that your solution (as manifested by the resulting code) is the right one, and for anything non-trivial, you surely can't expect others to just assume that it is the right one.
There’s a simple strategy for this, which works fairly well in both interviews and meetings. You give people time to focus and think about the problem and solving it, and don’t force people into discussions right away. It’s not a panacea but in practice it is very effective.
The reason why this is important in meetings, as someone running a meeting, if you don’t give people time to think, it will always be the same one or two voices in the room. This is why brainstorming sessions suck. The same thing applies when you are choosing who will take responsibilities—the same few people always speak up first.