Fog Creek Software
Discussion Board

Hiring specific skills - self fulfilling prophecy?

Taking a tangent from the other thread about the poster who had experience with 3D programming and statistical heuristic search engine algorithms and C++ but didn't get hired because they were looking for people with EJB, MQSeries etc.

When they focus so intensely on experience with specific languages and platforms, those who hire based on a "match the buzzwords" technique are effectively eliminating a large chunk of the top talent that otherwise would be available to them. By doing that, they decrease the chance that the person they hire is of the type who is willing and able to something new when it becomes necessary to do so.

Thus the typical result is that the person they hired isn't willing or able to learn new technologies when the time comes.  That result convinces HR and/or management that specific skills are required before hiring.  So they focus even more intently on hiring specific skills the next time.  And the cycle continues.

T. Norman
Monday, March 15, 2004

It ties in with the general uselessness of "certifications," which most working engineers are aware of, but which look so important to hiring managers.

So instead of hiring a top professional, they hire a moron who's "Java certified" or whatever. Yes, I've seen this in practice.

Monday, March 15, 2004

T. Norman, you're giving HR too much credit.  HR doesn't think.  They simply follow directions and rules.

The skills set approach is so that people in HR don't look stupid for sending people to the surly tech people who don't fit.  They are simply avoiding negative feedback.  If the send someone who fits the skills then they can blame the other guy.

Same goes for Tech Recruiters.

Monday, March 15, 2004

Hi T. Norman,

While I am sure someone can come up with a list of top ten reasons why employers tend to hire people who have very specific technical skills, I will only mention one reason here. This bit of advice (i.e. only hire for your current needs) can be found in just about every IT project management book that was ever written. Generally speaking, you will find this particular piece of advice under topic headings that have titles such as "Staffing your Project" or "Potential Project Risks".

The reality is most employers don't have the luxury of thinking long-term on anything nowadays.

One Programmer's Opinion
Tuesday, March 16, 2004

To be honest, I don't think that hiring specific skill sets is that far out of whack with the hiring practices in other fields of engineering.  At the places I've worked, I've seen plenty of mechanical and electrical engineering positions that require a niche skill set or experience with a particular design tool.  When it's an employers market, they can afford to be selective.

On the other hand, the software field continually proliferates new languages and tools. So if we want to blame anyone for niche hiring, blame ourselves.

Tuesday, March 16, 2004

"When it's an employers market, they can afford to be selective."

They should be selective.  However, they *think* they can afford to be selective on a tools/language basis, although selectivity on that basis frequently results in not hiring the right person for the job.

T. Norman
Tuesday, March 16, 2004

It's everywhere really.  There's a programming job in academia I'm perfectly suited for.  Right experience level, right skills, even a background doing research in their branch of the sciences.  Except for their *requirement* of an MS degree in CS or math, which means I'll probably never get through HR.  Damn, people -- you've effectively refused to hire anyone who Gets Things Done and has confidence in their ability to write software.  Seeing as common sense and salary surveys demonstrate *less* demand for MSCS than BSCS, we don't waste time and money.

Of course, I suppose I don't care to work for anyone who can't identify or refuses to hire good people.  Still frustrating...

Tuesday, March 16, 2004

How would you determine if a prospective employee was the sort who could learn a new technology quickly enough to do some minor work in it?

For example, I'm pretty good at learning enough about some new technology (VB programming, or HTML editing) to get something fairly straightforward working quickly.  I don't need to have mastered the subject before feeling comfortable enough creating something.  For instance, the first two VB programs I wrote are still being sold by my company today. (Of course, since I've had to maintain them for 8 years, I wish I'd written them a bit better :-).

Of course you don't want someone who THINKS they're a master after reading a "Master XYZ in 24 hours" book. 

If I were looking for somone like that, how might I spot them or "test" that skill?

Mr. Analogy
Wednesday, March 17, 2004

Well, you can always have TECHNICAL interviews.  Like joel says - get them to write code.

I had 6 interiews when going for my internship this year.  Three of them asked my technical questions.  Guess where both of my job offers came from.  So maybe I'm biased.  But still, it seems to me to be the only reasonable way

Thursday, March 18, 2004

*  Recent Topics

*  Fog Creek Home