Beware Programming Language Requirements On Job Postings(shorestreet.com)
shorestreet.com
Beware Programming Language Requirements On Job Postings
http://shorestreet.com/node/38
8 コメント
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).
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, 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.
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.
What languages do you have in mind?
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!
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.
"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.
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.
Of course, there can be no objective measure easily made, and I do not want to engage in language wars.
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++.
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++.
In addition to idioms, libraries and best practices, there are also paradigms to learn. Learning OOP/Functional/Whatever _properly_ takes time and practice.
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_.
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_.
Learning to program well in language X can actually be done using language Y, for some X's and Y's, especially when Y has the features of X.
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!
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!
I did Perl mostly alone, so it took years before I wrote idiomatic Perl.
Let me put it like this:
The first time I needed a big parser, I wrote a C-style lexer out of habit... :-)
Let me put it like this:
The first time I needed a big parser, I wrote a C-style lexer out of habit... :-)
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.
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 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.
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.
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.
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.
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.
> but if you are hiring for the long term (1-2+ years),
It's interesting to hear what people think of as "long-term".
It's interesting to hear what people think of as "long-term".
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.
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.
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.
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.
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.
Stupid job posting requirements are a sign of evil HR in an atherosclerotic or otherwise clueless company.
Please resist the temptation to describe corporate pathology by means of bad analogies with medical pathology. You're making me cringe.
I thought that atherosclerotic had passed from analogy to just flat-out insult.
I like making you cringe.
I like making you cringe.
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.
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."
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.
Obviously, I disagree. Such a filter will exclude precisely the wrong candidates. That is my argument in the article.
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.