Beware Programming Language Requirements On Job Postings
shorestreet.com
shorestreet.com
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.
Of course, we could argue that if a language takes 10 years to get to proficiency that there's probably something wrong (and in the case of C++ I would tend to agree).
No one disputes that C++ has a long road to mastery, but there are plenty of other languages for which that is true. So, C++ is not special in that way.
Fair enough. I found haskell easier than c++ to grok. It may have helped that I had a good grasp on type theory before I learned Haskell (worked through TAPL a few years ago). Subjectively, I found the various components of Haskell almost always fit together in very logical fashion with a very clean syntax, while C++ felt arbitrary, (with exceptions to every rule and exceptions to those exceptions and exceptions to those). I share your intent of not starting a language war. Just expressing my experience.
That said, I am a C++ expert, but contend that each of Lisp, Haskell, and Scala are far deeper languages, with more involved in their mastery than C++.
Company hiring is torn between the grand-corporate interest of having good long-term employees and the project/manager's pressing need to fill skill holes _last week_.
So, I continue to argue that asking precisely for language X may well exclude better applicants - ones smart enough to program in Y instead of X!
Let me put it like this:
The first time I needed a big parser, I wrote a C-style lexer out of habit... :-)
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.
Many people who consider themselves technically inclined (case in point, me) hate 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.
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.
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've been to interviews which were more or less well designed quizzes that could be administered by non technical people, with the answers evaluated by technical people later. That seemed better than the alternative. I do know one interviewer who always uses "what do you think are the three best books on software development?" You get some interesting answers to that one.
You might triple the amount of candidates you get for an interview, but chances are you're still 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.
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.
Paying employees to learn on the job is not a successful recipe for time-critical projects, no matter how bright the candidates are.
It's interesting to hear what people think of as "long-term".
Well known cliches like the 10x more effective programmer and the Microsoft/Google methods of recruiting add to the mysticism.
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.
I think that the trick is to have "just the right" keywords, and no more. The particular example that I give in the article has too many. So, fewer is better, in that case.
I like making you cringe.
Unfortunately, it is difficult to imagine a posting that honestly says "We just need people capable of abstract thought."