Earlier quoted context omitted.
The interviews I had, usually are a discussions about the projects I had done and the choices I had made and questions that stem from there. I am not sure what is unsatisfying about interviews like that.
This interview process selects for someone with whom the interviewer might enjoy having meetings. I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess. The data shows that humans are terrible at every kind of interview assessment. This is why I appreciate an approach with mechani…
I think the problem with whiteboardy-type interviews is they've become closer to trivia. The fact that you grinded LeetCode and others read CTCI kind of prove that, no? As in, people go far out of their way to learn a skill _just to pass the interview_.
> I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess.
Interviewing is a skill and should be treated as such. This means possessing a set of skills any dev off the floor won't necessarily have, and that should be expected. 99% of devs don't have the skills required to conduct a whiteboard interview as an interviewer correctly either, and yet that seems to be generally accepted as okay.
> The data shows that humans are terrible at every kind of interview assessment.
Exactly, which is why, in my posts above, I pointed at things other than the interview as reasons you might be very happy with the quality of your coworkers work. It seems silly to say "The data shows that humans are terrible at every kind of interview assessment", but then also attribute anything from your job to a specific style of interview assessment, right?
You'd get further as a company by investing in training, code quality (review, analysis, etc), leadership, and healthy firing processes.