I can't say I agree with everything here. I've found live coding to be a useful way to gauge how someone thinks. Prior to the in-person interview, a 10-15 minute phone screen has already been done as well as a easy programming problem that takes most senior developers 5-10 minutes to solve it. So when we bring them in, we think they should be able to "pass" the interview.
When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what.
Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally.
We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.
If this (finishing a program missing only a few lines of code) were all most coding interviews were, I don't think there'd be anywhere near as many complaints about them. That's very similar to what you'd actually be doing on the job.
It's coming up with what you took in your data structures/algorithms class a decade ago on the spot and write full functions about them, especially on a whiteboard, that gets really annoying, and makes programmers feel like they have to refresh their knowledge of an entire class (plus a bunch of other trivia from across CS) every time they want to find a new job.
I like this. Of course I enjoy reading code so that may be why. On the other hand I’ve met a fair number of devs who either can’t read code or just wont. I wonder if the person in your example would have passed had you simply given him a problem to code from scratch.
When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what.
Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally.
We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.