> The problem is that you never find out because if someone bombs the coding part you simply chuckle and say "well that person is clearly a liar, or something!"

> The problem is that you never find out because if someone bombs the coding part you simply chuckle and say "well that person is clearly a liar, or something!" and they don't go any further in the hiring process. This. I've been job-hunting lately and getting asked to do "technical challenges" and such like, which are useless to me because they are entirely asymmetric. They tell me nothing about the company except they are following the latest fad in candidate screening. I pointed out in feedback to one of the testing companies a while back that they had no empirical basis for believing their evaluations didn't reject more qualified candidates for less qualified ones in terms of ability to do the actual job, I got a reply saying, "No, we have all kinds of empirical data! Our clients save $TIME in the hiring process!" Which is great until you realize that perfectly competent engineers are being locked out of the hiring process by this nonsense. We saw a fad for this kind of testing in the mid-90's, just as the dot-com boom was starting to roll, and it didn't end well. The few companies I interviewed at that used coding tests of one kind or another all failed quickly, although it did give me the opportunity to ask an incompetent hiring manager at one of them how I'd managed to get a PhD in physics while having "below average mathematical abilities" according to one of their tests (which I swear had been written by an innumerate.) HR people will simply assert that anyone who fails these kinds of tests is incompetent, and anyone who complains about it is just expressing sour grapes at their own failure, but that all side-steps the issue that there is no significant empirical validation on the quality of hires that such tests produce. Their only real use from my point of view is that if the "interview" process is heavy on "coding challenges" and the like, I'm a lot less likely to bother with going through it, because it speaks to a company that has bought into policies that have no empirical basis and that provide the least amount of information to job seekers, and I'm not all that interested in working in the kind of monocultures such processes produce. For senior people my favoured interview form is to mostly talk about a few obscure language features in their language of choice, and then have a free-form discussion about language design. Senior people who are any good care about languages, and have thought about languages, and can have nuanced, intelligent discussions about languages and the trade-offs involved. It acts as a good foundation for talking about other kinds of design issues as well. For junior people, some basic test of coding competency may be useful, but over the intermediate level they are very likely testing for the wrong thing, and either way we have no evidence.