What would be a polite way to say "I didn't hire you because you have no idea how to program?" I mean I've interviewed people who we didn't hire for that reason... You can't say that though because its mean... Instead you get "your skills didn't align with our needs."
As a CS student who's still not very confident in his skills and without enough experience to recognize his own weak spots, I would say that "you understand X's language well, but you need to improve your knowledge of algorithms and data structures" or "you have a good theoretical understanding X and Y Computer Science concepts but you need to work on side projects to gain programming experience" or "you have shallow understanding of a lot of languages/technologies but I advice you to concentrate on X or Y until you become good at them instead of jumping between L/T".
I know that very few employers would take the risk to be so frank but I personally wish they were. It would be helpful to the candidates who actually care about improving their knowledge and skills while potentially offending those who are trying to fake it.
A debate can only happen if you continue to entertain their followups with responses. If someone is silly enough to claim they know how to program (or some other critical skill) when their interview demonstrated that they could not, you can simply stop answering their email. It's sufficient to have given them one explanation for why they're not getting the job; that's more than most potential employers offer.
Point being: It's not going to be constructive. Telling someone who thinks they know how to program they can't isn't going to help them and will only seem mean. Because those types can't see they have no idea what they are doing.
On the other hand, it's rare to get someone as far as an interview and have to tell them "you don't know how to program". More common answers would be something specific, like "we need someone with more experience doing collaborative Open Source development", or "we need someone with more skill navigating a complex and unfamiliar codebase and making changes without having to have the entire system architecture in their head". Those are useful and constructive bits of feedback.
"3. Within reason, always respond to requests for more information."
Many communication "rules" require the ability to moderate one's interpretation of the rule. I don't think this is any different. It's a good thing to give candidates feedback and if they're confused, the feedback did no good so you should be willing to help them understand. But if they're just unwilling to see the world or themselves for what they are, it's out of your hands and you should leave it well enough alone.
That is hard to avoid, because people are called in to interviews based on how they look on paper. Some blatantly incompetent people write themselves up to look good on paper. They have relevant education, skills, plausible-looking experience and so on.
Following up on some references before calling people in for an interview isn't a bad idea.
Man, I have seen some blatantly incompetent ones. You'd give them a white board and ask them to show a linked list with boxes and arrows. They just couldn't do it.
One case I remember couldn't demonstrate pseudo code for a circular buffer operation based on an array with a head and tail index.
While linked lists are fundamental, depending on the language(s) people have used and how people were taught they may actually not be something people have used. Anyone using mostly high-level interpreted languages (e.g. Python) or something like PHP may not have ever used them, and if they're somewhat self-taught then they may not have encountered them in their reading.
Hash tables might be a better filter, because IMHO you're a lot more likely to find those in real use these days than linked lists.
Your comment is on the mark. But in that particular question they were asked something like, show a singly linked insertion on a white board using some box-and-arrow notation. They were not asked to write it in C or whatever. They couldn't visually whiteboard the concept at all.
(The job area was embedded development, involving C and C++, so asking for C code related to linked lists would have been fair game!)
Our HR tells us who to interview. We'd like that to change, and asked for change, begged even, but thats the way it is. Not everyone works in startups.
(These werr people who couldn't program FizzBuzz)
Plus anyone can just make shit up on their resume.
the questions you asked or the way you asked them were answered in a way that made it appear to you that that person couldn't program. not saying that was the case, but just want to add that line of thinking too.
