When I was young and eager to please I would put up with this sort of thing. In fact, I used to think there must be something wrong with me, that I was a bad programmer for not having every data structure and sorting algorithm perfectly memorized at all times.
Now that I'm starting to get old and realize it's all BS, if you ask me to write quicksort on a whiteboard I'm going to roll my eyes and walk out.
When they are unable to answer "When was the last time someone implemented one from scratch" then I ask them "Why are you asking candidates questions that are not relevant to the job? Wouldn't it be better to evaluate the candidates against the role they will fill?"
Then if they give B.S. answers you can politely say "Thanks, but no thanks" and then go - I try and dig a bit deeper to establish whether there was a really cool and interesting story about why they had to implement one themselves, or whether they're just full of rubbish and literally have no idea what they're doing
Asking people to code a sort in an interview can be very useful as it shows whether they can actually code or not.
I've had people write horrible code in interviews many times and that is a major indicator that I shouldn't hire them for a coding position.
"I need to repeat this sequence of operations an indeterminate number of times... if only there were some programming construct that could help me out here..."
So I reached back to my Apple II BASIC days and whipped out the trusty GOTO. The look on the interviewer's face was priceless.
It really doesn't get much worse than forgetting how to write a select statement.
One needs to evaluate people. I would prefer to evaluate people using a metric close to what is required in the job -- coding.
If people have issues that they can not be evaluated properly, then what I am supposed to do? Just hire anyone no matter how they do?
Of course coding isn't the only metric but it is one of a couple. If you write an algorithm that has indexing errors or no stopping condition or just does't work, it isn't a good thing. I do rely on coding on whiteboards or paper a lot more when it is someone new in their career and do not have many past accomplishments to point to.
I like to write my algorithms on paper first before writing code, but doing it on a whiteboard in 45 minutes while explaining my work and checking for edge cases can be a bit unreasonable.
I don't think the contention is about testing a programmer's ability, but the way their ability is tested. Personally I think pair programming is a better method of testing someone's ability to code AND their ability to collaborate with others.
What does BS stand for?