Slashdot Mirror
Ask Slashdot: Why Are Tech Job Requirements So Specific?
First time accepted submitter hurwak-feg writes "I am in the market for a new IT (software development or systems administration) job for the first time and several years and noticed that many postings have very specific requirements (i.e. specific models of hardware, specific software versions). I don't understand this. I like working with people that have experience with technologies that I don't because what they are familiar with might be a better solution for a problem than what I am familiar with. Am I missing something or are employers making it more difficult for themselves and job seekers by rejecting otherwise qualified candidates that don't meet a very specific mold. Is there a good reason for being extremely specific in job requirements that I am just not seeing?"
A lot of jobs require domain knowledge, meaning that they aren't all that hard, but require a few complex tasks to be repeated over and over. Employers are able to train someone faster if they've been doing similar work.
On the other hand, you're a lot better off as an employer with a smart person with no experience in the field than you are with an idiot who's been doing the same job for years. That understanding hasn't seemed to trickle up toward management just yet. Maybe closer to the point, a manager can't tell a qualified candidate from a blowhard, or an unqualified one from someone who's simply insecure. So they settle for domain knowledge and hope for the best.
You might do better looking at startups. They aren't all ramen and 15-hour workdays, and the environment's usually more conducive to good technical work.
There are lots of reports of this problem. HR departments screen resumes and in order to screen down to a manageable number, they specify (and match for) very specfic requirements.
Unfortunately, HR departments don't understand the hiring managers' actual requirements, leading to job posting that (for example) specify "x years of experience with Y language" when the language has not existed for x years.
The real "Libtards" are the Libertarians!
The other reason is that many companies are not interested in training people anymore: they want someone already trained to put to the task immediately without additional costs.
There is a good reason and a bad reason.
Where I work, there is very little overlap in skills between the IT people. One person is responsible for the old IBM database, for example. It's not a relational (sql) database, so nothing I know from MySQL applies. When we replace the IBM database guy, we're going to need someone else who knows that exact system. In fact, because there are so few people remaining who know the system, we are engaging in an 18 month project to rewrite everything for MS SQL shortly before the person retires.
My own job is programming Moodle, an LMS with over a million lines of code. That's roughly equal to an entire Linux distribution. Hiring someone with no Moodle experience would be roughly similar to hiring a Linux programmer with no Linux experience.
On the other hand, I once spoke to someone who wanted to hire a "PHP guru". I tried to explain there's no such thing. What he SHOULD have been looking for would be a web PROGRAMMER who knows PHP well. In many cases, skill in the field is far more important than above-average proficiency with a particular tool, but management sometimes doesn't understand that. If the person doing the hiring isn't particularly skilled in the job they are hiring for, they just don't know what is most important. For example, I would argue that for web programming, the WEB part is super important - good programmers who aren't web programmers aren't in the habit of thinking about security at every step, or scalability, nor are they necessarily skilled at stateless programming. A manager who isn't a very web programmer herself wouldn't know that though, so the best they can do sometimes is to look for someone experienced with the tools the company uses.
(Context: I'm a hiring manager; my team builds big distributed software systems. Our choice of language is Scala, but the team chose to use Scala before anyone on it actually knew Scala, and we don't have strong preference for Scala for software developers we hire -- in fact, we don't look for specific language knowledge at all, but rather strong fundamentals (OOP, distributed systems, etc)).
Assuming you're not looking at a company that's gaming the system (others have talked about the whole "I want to hire/promote someone specifically but I have to post a position so I'll post a position only my preferred candidate will satisfy" scenario), the other problem -- and I think this is a bigger issue -- is that most people are just bad at ferreting out talent as part of the interview process, and therefore opt for asking about very specific skills, because testing for very specific skills is actually much easier than testing for talent, for experience, for understanding of the system. Add to that, of course, that if/when your HR group is responsible for job descriptions, quite often they can't conceive of a more flexible, open-ended description because they can't effectively measure for that when filtering resumes.
The unfortunate thing, of course, is that in the end the specific knowledge is probably not even what you're looking for -- certainly, it's not what we're looking for because what we want is the ability to solve very hard, complex, problems -- and these are the sorts of problems that are also hard to ask about in an interview, because any problem you can make significant headway on in 45 minutes is simpler than what we deal with. This really comes down to the fact that interviews are a test, a simulation of a reality (the person actually working with you), and people sometimes opt to build the interview (and the pre-interview process, like the job description) in a way that makes it easier to conduct that simulation, rather than in a way that makes it more representative of the actual thing for which you're testing. It's that "looking for your keys under the streetlamp because that's where the light is, even though you lost your keys in the dark alley" problem.
"you silly female HR idiots."
Have you been in storage since the 50's or are you intentionally saying that to ensure that no one takes you seriously?
That might happen sometimes, but everywhere I've worked, neither is the case, yet these sorts of job descriptions are still common. In my experience:
The person hired usually has at least some of those keywords in his/her resumé, thus getting the person past the initial sanity check. The person also has things in his/her resumé that catch the attention of the hiring manager who screens it next. However, the person's actual qualifications are almost never an exact match. In reality, the person hired might match 30% of the stated criteria, but they might also end up matching the requirements for some other job within the same team, and somebody else on that team might have the requisite skills to take on some of the posted job's responsibilities.
For example, consider somebody applying for an OS kernel test engineer job. The ideal candidate would have experience in writing kernel extensions, would have experience writing test harness code with a particular test harness, etc. However, the person hired might have the test harness skills, but little kernel engineering skills. That person might, however, have strong skills at writing (English), which might free up part of another kernel engineer's time that would otherwise be spent writing documentation comments in the headers. Then, that kernel engineer would have more time to help out writing the kernel-side hooks that the test engineer would need to use.
Or consider somebody applying for a documentation position. The person who left might have experience with server technologies and networking, so an ideal drop-in candidate would have those skills. However, two other documentation engineers might have the networking and server chops between them, so if they found somebody who could cover some of the technologies that those two existing people were currently covering, that person would also be an ideal candidate.
Unfortunately, there's no good way to express such a complex (and potentially ever-changing) set of requirements. Thus, my general recommendation is this: If you think you'd be good at the job, apply. If you only meet some of the criteria, apply anyway. You might or might not get the job, depending on whether somebody else is a better match, but generally speaking, in my experience, the most important criterion is not what you know, but rather how easily you learn new things. With the exception of highly senior positions, everything else is at least to some degree optional.
Obviously, different companies hire differently, so YMMV, but this is usually a good general rule.
Check out my sci-fi/humor trilogy at PatriotsBooks.
After reading your post, there is not enough of money you could pay me to get me to work for you, qualified or not. None. Zero. Zilch. Nada.
If you had my dream job, and it was a perfect match for me, I wouldn't take it. Because I would spend my entire paycheck on therapy.
Not. Worth. It.
If you want a robot, build one, jerk.
--
BMO
It's because HR know jack about the field they are recruiting from. They therefore ask for specifics, which means that the people hiring spew out a list of the skills that the current incumbent in the target job has (or a similar job).
And it wouldn't wash with them if you just put down "Must be able to think logically, and learn new stuff quickly", which as far as I know are the only real requirements for programming jobs. They'd have to work out how to assess that, instead of counting bullet points on a CV.
Sometimes I wonder if the dearth of decent programmers that seems to be a fact of life in the current hiring environment is purely down to the HR department filtering all the decent candidates out. Our jobs go out internal to our organization first (we're the largest employer in Europe, so that's not TOO bad), so I guess all the applicants I get have been double-filtered.
And of course, there is no budget for slack. If someone capable of doing the job leaves, why, you should be able to fill his position with someone just as capable almost immediately! Workers are fungible little peons! There is no acknowledgement that you can't replace experience, much of it specific to the work.
The real solution is to have a pro-active policy of hiring inexperienced people, training them up, and promoting their loyalty, but no-one wants to do this, because the standard industry remuneration policies don't promote loyalty, so any kind of investment in people is seen as a waste because the only way that people get a decent raise is by jumping ship to another employer. It's a vicious cycle - you can't hire people to train them because you can't keep them. So the end result is that the only way you forge new capability is by destroying entire development teams and recreating them from scratch, losing man-decades of experience and productive working relationships in the process.