No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question.
>> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard.
The ability to see a hard problem, develop your own solution, and translate that into code is a pretty important skill. "Skills" aren't all about knowledge.
>> If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate?
It's a lot more complex than that. It's not just about filtering out bullshitters. It's also about identifying people who might be great but are unable to talk about it. There's also lots of people who are great but haven't been in situations where they've been able to tackle interesting challenges (either because of their inexperience, industry, etc). Or maybe they've done interesting things but in a related field that's hard to understand.
But, yes, absolutely train interviewers. (Interviewing isn't really a role that you hire for.) But even a very well trained interviewer might not be very effective in a behavioral interview.
>> I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production?
There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be.
>> The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before.
The interviewer is comparing the candidate to other candidates on the same question. So if a candidate is getting rejected because they failed to be perfect, this means that other candidates are actually getting to perfect solutions. Or you just have a crappy interviewer who rejects everyone.
>> Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before?
If that's the case? Nothing. But that's not the case.