Asking a developer with a decade-plus of demonstrable experience to whiteboard is like asking an F1 mechanic to draw an engine and label the parts.
A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag.
Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.
Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
Really? You could easily fake that, have a friend who still works somewhere say anything.
> Ask them to bring in an interesting example of their own code to the interview.
That's great if you're willing to weed out people who only code at work.
> Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.
That's what you can do without their own code, but it fails to prove they really wrote it.
Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?
Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.
So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.
> So coding exams are almost a litmus test for "inexperienced programmer" in my view.
You certainly could call them that when they weed out people with 20 years of experience who can't merge 2 sorted lists.
Granted, this was at a company with a notoriously difficult technical screen, but it goes far beyond fizzbuzz or merging two sorted arrays. If you can't do that, there's no way you'll pass, but I'd say you need to be prepared to solve difficult questions from "cracking the coding interview" at the whiteboard in 45 minutes or less, without needing a great deal of help. Minor syntax errors are fine, but your code needs to be pretty tight and close to working.
I walk around with the ability to do fizzbuzz or merge two sorted arrays in my head, and I could code up merge sort or find the path from a root node to descendant in a binary tree with a little thought. But really, no joke, in my experience, these interviews take far, far more than that. I can't speak for everyone, but I personally need to study, hard, for a few weeks to a few months to get into this kind of form, depending on how long it's been since I last did it.
I have no doubt that the degree of technical grilling varies considerably between companies, which is why I'm not doubting what you've said here. However, I am certain that it doesn't tell the whole story - and that many of the companies that claim that there is a desperate shortage of software engineers have set the "no hire" standard to the point where they are rejecting people who could easily do what you've described, and much more.