Take-home tests. Lower-stress environments for coding tests - working on their own hardware, working remotely, no panel interviews, no actively combative/aggressive interviews. Also, cool aspect of that: all of these options will make the interview process more appealing for everyone. And if the justification for angry/combative/aggressive interviewing is "well, that's how our culture is", I would say the company has a bigger problem to fix.
But people are already crying over take-home tests being like working for free for the company, and then there's no way to prove they aren't cheating, which is a showstopper. That by itself is definitely not a "better suggestion for filtering out people who can't code".
> all of these options will make the interview process more appealing for everyone.
No for people who can competently handle an onsite interview and don't want hours of extra work at home.
> And if the justification for angry/combative/aggressive interviewing is "well, that's how our culture is", I would say the company has a bigger problem to fix.
Maybe you being so disingenuous makes you feel better, but interviews aren't "angry/combative/aggressive" just because someone asks to see some code on a whiteboard.
I've participated in a lot of interviews on both sides of the process.
In my experience, the whole process goes a lot smoother when there's a take-home exercise. It turns the in-person interview portion into a technical discussion about a recent mini-project unencumbered by NDAs and trade secrets.
If you can't quickly determine if an applicant "cheated" on the take-home exercise through a simple discussion, then you may want to recuse yourself from performing interviews.
If an applicant can't make enough time for an appropriately scoped exercise, I think it's likely they're unqualified or they don't value the opportunity enough to make time. Those are undesirable qualities the recruiting/interview process is intended to filter out.
