

Beware Programming Language Requirements On Job Postings - robin_bb
http://shorestreet.com/node/38

======
dreish
Learning a programming language is easy. Learning to program _well_ in a
language takes a long time, and includes becoming familiar with its idioms,
available libraries, best practices, and appealing but potentially dangerous
features.

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.

~~~
UncleOxidant
I think this is especially true for C++ - it takes a decade to become
proficient with C++. And at the end of that decade you should realize that
there's still a lot you don't know.

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).

~~~
robin_bb
No, UncleOxidant, it is definitely not "especially true for C++". There are
plenty of powerful languages out there, many with more subtleties than C++,
and longer roads to mastery.

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.

~~~
shrughes
What languages do you have in mind?

~~~
plinkplonk
Haskell probably has a long road to _mastery_. That said I think it might
still be shorter than that for C++. it _is_ hard to think of a language that
takes longer than c++ to master. Interesting!

~~~
robin_bb
I disagree. Haskell is more difficult to master. There's far more to it than
C++. I am highly proficient in both languages, it so happens.

~~~
plinkplonk
"I disagree. Haskell is more difficult to master"

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.

------
indiejade
What I don't understand is why so many companies that have these kinds of
problems hire people who _don't_ understand anything technical to "screen"
their applicants.

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.

~~~
mattmcknight
I suppose another question would be- how many technical people want to spend
all day screening applicants?

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.

------
brc
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.

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.

~~~
kevinpet
I think your disagreement may just be a difference of emphasis. You wouldn't
use those criteria to hire a consultant to come in and do an enhancement to an
existing app, but if you are hiring for the long term (1-2+ years), these
rules make more sense.

~~~
torr
> but if you are hiring for the long term (1-2+ years),

It's interesting to hear what people think of as "long-term".

------
palehose
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.

------
kailoa
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.

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.

~~~
robin_bb
kailoa makes a good point: removing keywords from the job posting risks not
appearing in a potential employee's search.

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.

------
stcredzero
Stupid job posting requirements are a sign of evil HR in an atherosclerotic or
otherwise clueless company.

~~~
blahblahblah
Please resist the temptation to describe corporate pathology by means of bad
analogies with medical pathology. You're making me cringe.

~~~
stcredzero
I thought that atherosclerotic had passed from analogy to just flat-out
insult.

I like making you cringe.

~~~
blahblahblah
My point is that such a statement is absolute nonsense; it conveys no
information at all. You might as well have been discussing the
"jabberwockyness" of a company. What would it even mean for a company have
atherosclerosis? In what sense could a company be said to be stenotic? What
elements of the company would correspond to the various components of arterial
plaque? What about a company could be said to correspond to a transient
ischemic attack? How could you identify a company whose 'plaque' is
characterized by the presence of lipid-rich necrotic core vs. one that has
juxtaluminal hemorrhage or one that is calcified? Can you mitigate the
symptoms of an atherosclerotic company via administration of rt-PA or via
endarterectomy? No obvious analogues for these features of atherosclerosis
exist in the context of a company. The analogy is not just a leaky
abstraction; it's a broken one.

------
pookleblinky
A good programmer can program. It's as simple as that.

Unfortunately, it is difficult to imagine a posting that honestly says "We
just need people capable of abstract thought."

------
jcl
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.

~~~
robin_bb
Obviously, I disagree. Such a filter will exclude precisely the wrong
candidates. That is my argument in the article.

