[cmrdporcupine]

You have set up a strawman -- I didn't say go hire people who haven't seen code, I didn't even say don't do skill testing questions. The question is: at what point in the interview process do you start dumping skill testing questions at them? And I think as the first gate to pass, this is just awful.

Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topic.

In any case, as a tangent: Most of the questions asked in these interviews have little to do with the day to day tasks of software engineers. So I'm not sure they give much insight into the performance of software engineers doing software engineering. But they do give preference to the skills obtained in CS algorithms courses, so there is an intrinsic bias towards hiring new grads.

[binarytox1n]

I did address your question - I ask them to write code first. It may waste your time, but it saves time for my team. You can't code? Ok, the interview is over. Thanks for your time.

There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.

[Traster]

It's also super awkward to talk to someone and get a real good understanding of their experience, how they fit, what they've done, what they'd want to do.... and then find out they can't code. And this does happen. It's much nicer for all involved to do that early in the process and write it off as a formality because it's a humiliation to throw that at someone at the last minute. It's an insulting waste of time for any decent candidate, but there are always candidates who can do everything but code and you have to weed those guys out.

[cellularmitosis]

And from an applicant's perspective, I actually prefer getting the coding part out of the way up-front. It allows me to relax for the rest of the interview and just "be myself".