Learning a programming language is easy. Learning to program <i>well</i> in a language takes a long time, and includes becoming familiar with its idioms, available libraries, best practices, and appealing but potentially dangerous features.<p>We tend to weed out, in Perl coding tests, people who are just transliterating C code to Perl, which is fairly common. In a group coding environment, no one wants to get stuck having to clean up someone else's ridiculously complicated code to do something the language lets them do in three or four lines.
What I don't understand is why so many companies that have these kinds of problems hire people who <i>don't</i> understand anything technical to "screen" their applicants.<p>Technical competence and ability to speak on the telephone are not even remotely related. Written talent trumps speaking talent when it comes to the digital domain. Does ability to hear trump ability to read? That's probably debatable, but I imagine that the talent of most people who know how to read and listen surpasses the talent of people who are paid to talk.<p>Many people who consider themselves technically inclined (case in point, me) <i>hate</i> the telephone. Yet "telephone interviews" are a huge part of many companies' hiring regimes. And usually these telephone interviews are conducted by people with specialized training in sales, marketing or HR, people trained to do nothing more than speak aloud the words and acronyms off of a printed sheet of paper or screen, to inflect their voices with all the right intonations. Yet when faced with actual questions about specifics by a technical person, they stammer and don't know what to say.<p>It's usually at this point in the interview when I wonder why company X is paying this person to call me to be interviewed when I'm not getting paid anything for my time.<p>This problem is similar to what the OP argues for, I think. It's not that there's a specific holy grail of language or language-requirements that a company seeks, but simply somebody who knows what they're talking about. There can be a clash when a particularly "savvy" talker of BS encounters somebody who actually knows what she's talking about.
I suspect the author may not have ever had the task of filling a specific developer position on a project with specific skills. Putting out woolly descriptions like he suggests will flood your inbox with hopefuls, wannabes and chancers. You've then got a mountain of work to get through to filter out all the garbage. I suspect in a flat job market like we have at present, the task would be that much worse.<p>You might triple the amount of candidates you get for an interview, but chances are you're <i>still</i> going to go with the one that has the best cultural, technical (read:language/environment) and business experience fit for the job. Which can be done by explicitly stating this in the job ad in the first place, saving everyone a lot of bother.<p>The only reason to frame an ad in less-than-specific terms is if you're looking to fill long-term positions, like graduate jobs, jobs where the whole team will be learning a new technology together or research-like jobs.<p>Paying employees to learn on the job is not a successful recipe for time-critical projects, no matter how bright the candidates are.
There is also a flip side to "must know X language" which are job posts that is in search of applicants who must have 2+ years of Scrum and Pair Programming experience. I've found that this is especially common within Ruby on Rails job posts. Eventually I will get around to trying to practice those techniques on my own, but I don't see how not having those skills disqualifies me from being a potential candidate. I've also been flat out rejected as an applicant for not having experience working on a public facing website, but oh well. I will just have to get around to build a massive public facing website on my own too.
I don't know why technical interviews/recruiting are such a fascinating subject. I think it is related to the fact that they are such an imperfect mechanism for finding employees/partners.<p>Well known cliches like the 10x more effective programmer and the Microsoft/Google methods of recruiting add to the mysticism.<p>This particular article has some good tips though I'm not sure how practical it is. Modern recruiting uses extensive keyword searching. Unless your goal is to weed out some of that, this kind of job posting may not get too many hits.
A good programmer can program. It's as simple as that.<p>Unfortunately, it is difficult to imagine a posting that honestly says "We just need people capable of abstract thought."
Unless the job is highly specific, it may not be a bad idea to leave the languages in the posting. The problem with many job searches is the abundance, not lack, of candidates, and languages serve as a useful first-pass filter on both candidates and jobs.