Steax wrote: ImagingGeek wrote:
After all, if you cannot code, how could you ever know how to plan/link modules, ID bugs, etc*.
*And if someone magically had these skills without knowing how to code, IMO, it would often be worth training that individual to code. Even among trained individuals, these sorts of "higher functioning skills" are rare and hard to develop.
They can. I've seen them do it. They can talk endlessly about how they worked with software X, how new technology Y is so important, how they can use Z techniques to track down bugs (and file them, and manage them straight from version control), and so forth.
I think you've mis-understood what I was trying to say. Anyone can use buzzwords, or put on a front of intelligence when faced with a general question. But if you put forward a specific verbal example, its doubtful a non-coder will be able to bluster their way through. I have a few standard questions for screening (again, matlab, not real programming); none are particuarily hard, but they do require that the interviewee know the general syntax & workflow used within matlab; you're not going to bluster past those types of questions with buzzwords and claims of past experience.
EDIT: I removed & re-inserted this bit 2-3 times, but what the hell - it sounds rude, but its not intended to be rude. Please don't take it as an insult/attack/etc. If you're interview process can be usurped by someone who knows some buzzwords, than you have a serious flaw in your interview methodologies and/or interviewer(s). A properly designed/implemented interview should have no trouble excluding these individuals. There are a lot of resources out there to help in the design/implementation of interviews - they also cover the pitfalls of poor methods like in-interview tasking (testing), etc.
Steax wrote: They'll happily start a coding test, but then start freezing as they start to write, and make excuses for it, even if it's a really, really easy thing (as in "print out 1 to 10" easy). Sometimes they'll flood you with buzzwords and tool names and website references in an attempt to make it appear they know how to solve the problem.
But, again, this could merely be due to pressure - in-interview tasks are notoriously poor tools (I'd direct people, again, to the book I posted in my first post, it covers this issue in some detail). You end up testing for the ability to deal with pressure, not for the skill(s) in question.
Steax wrote:More often than not, these people are actually "good" people, in that they're better than those who can neither talk nor code. They're usually more willing to learn. But not every company can afford to hire people like this, especially when better people are behind them in line.
If there are better people in-line, then hire them. But if the choice comes down someone who can code, but lack the "higher level" capacities, verses someone with clearly demonstrated "higher abilities" and a questionable ability to code, I'd take the latter. Learning a programming language/syntax/etc will occur much faster than learning the higher-level stuff; assuming the inability to code was real, and not merely an artefact of a poorly designed in-interview test. I hire people at two levels - for a academic/science lab which I run (in a uni), and for a biotech startup in which I am a partner. We are faced with the exact same issue - a world filled with people whom have a mediocre skill base, and little/no higher-level capacities. Nearly every failed employee I've seen were the ones who had skill base but no higher-functioning capacities. At the end of the day, if someone is smart enough to do the high-level stuff, they'll be able to figure out the low-level stuff - assuming they didn't know it in advance.