Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: Why Are Tech Job Requirements So Specific?

Posted by timothy on from the based-this-one-on-my-nephew's-resume dept.

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?"

17 of 465 comments (clear)

  1. To hire specific people by tepples · · Score: 5, Informative

    I'm under the impression that the more specific a tech job requirement is, the more likely it was written to target one person, such as a specific foreign citizen on an H-1B visa. That or the company just wants to be a cheapskate, wanting the new hire to be productive from day two instead of taking two weeks to train him or her.

    1. Re:To hire specific people by Lodlaiden · · Score: 5, Interesting

      The "To hire specific people" may be spot on. Sometimes an employer will write a job posting as a way of promoting an internal employee, though they have to post it as an open req for staff, so it doesn't look like favoritism(sp?).

      --
      Suborbital [spaceflight] is the special olympics of spaceflight. - Rei
    2. Re:To hire specific people by Anonymous Coward · · Score: 5, Informative

      Your impression is correct. My immigration law professor talked about this during our visa lectures. The company will find an H-1B candidate they want then the corporate attorney writes a job app matching that person. Bingo, no one matches the description and you can then hire your H-1B.

    3. Re:To hire specific people by bsolar · · Score: 5, Insightful

      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.

    4. Re: To hire specific people by pev · · Score: 5, Insightful

      "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?

    5. Re:To hire specific people by Zomalaja · · Score: 5, Funny

      Hello, I am the CEO of a giant company. Regarding your comment, can you explain the term "good faith" ? I have never heard this term before. Thanks.

    6. Re: To hire specific people by Anonymous Coward · · Score: 5, Informative

      In at least one case it was to promote an existing employee. Me.

      My boss quit. His boss agreed I should take over, but corp. policy requires a job posting published for 5 days. The two of us sat down w/ my resume and wrote a description very unlikely to be matched by anyone else. 5 days later HR let my promotion go through and the posting disappeared.

    7. Re:To hire specific people by dgatwood · · Score: 5, Insightful

      1. Lazy HR screeners ...

      2. They may be hiring someone they've already picked out from inside the company. ...

      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:

      • Job listings contain a list of keywords based on what skills the ideal drop-in candidate would possess. The hiring managers know that they probably won't actually find someone who perfectly matches these skills who wants that particular job, but they list the skills on the off chance that they will.
      • Resumés are pulled from a database based on keyword matching and based on which jobs you've expressed an interest in. If you don't have enough keywords, no human will ever see your resumé.

      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.

    8. Re:To hire specific people by bmo · · Score: 5, Insightful

      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

    9. Re:To hire specific people by Dr_Barnowl · · Score: 5, Insightful

      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.

  2. It makes sense and it doesn't by Anonymous Coward · · Score: 5, Insightful

    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.

  3. Answer: HR departments by whoever57 · · Score: 5, Insightful

    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!
    1. Re:Answer: HR departments by SJester · · Score: 5, Insightful

      This is completely true. I worked for a headhunter for a while. I was the tech guy who would interview prospects and translate their skills into bullet points for people who need to read bullet points. Meanwhile I had a relative who was a hiring manager at a large firm, so I got to see what happened when the job reqs were sent from IT to HR, what happened when HR put out those reqs, and what happened when I would try to explain to them that Skill X is equivalent to or superseded by Skill Y, and that for example the lack of familiarity with Q was not a showstopper. HR is not populated by techs. These are people who are really good at filing and filling out forms, at shuffling paper, and at bearing up under my contempt for them. But I digress... A position would open up for a developer who was familiar with C++ and experienced with databases and had worked on, IDK, an IBM mainframe. HR would get the req and send it back up with a "Is C++ hardware or software? What model of databases? And is it ok if I should say "familiar with IBM" ?" Eventually the req goes out with "Must have three years of experience with C++, SQL Server, and System/370." This is a small, off-the-cuff and fictional example but it was repeated endlessly.

  4. There are a _LOT_ of candidates out there now by Anonymous Coward · · Score: 5, Informative

    The problem is, there are a lot of candidates out there now. A LOT. So we get real specific with what we want, because we still end up getting between five to ten applicants that have those things and thirty to forty who have almost all of them. If we were vague, we would receive probably between 100 and 200 applicants per job. And we're in an area that is NOT tech haveny. We're in the middle of the deep south.

    I remember a friend from google telling me they receive , on the average year, around 195,000 candidates, 30% of which make it to an interview phase. That number doubles every year and a half. By being way more specific , they are slicing that number in half. Or more. Instead of ALL the google employees having to interview 50000 (which doesn't count second or third or onsites that also occur), they're trying to do far less.

    Employers are facing a glut of software engineers/IT/etc. We're just knocking the numbers down to reasonable levels with these extra requirements. It'd probably be in your interest to go ahead and apply if you're close to all.. but rest assured, if you see an advert for a job that contains a lot of requirements, they will probably get 5 - 10 applicants that meet those around here.. and 300 - 400 in a more tech heavy area like the bay area.

  5. If you have 1 Apache admin, they better know Apach by raymorris · · Score: 5, Insightful

    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.

  6. Finding Talent Is Hard by CrankyFool · · Score: 5, Insightful

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

  7. Re:If you have 1 Apache admin, they better know Ap by Chirs · · Score: 5, Informative

    My own job is programming Moodle, an LMS with over a million lines of code. That's roughly equal to an entire Linux distribution.

    What are you smoking? Just the linux *kernel* is roughly 12 million lines of code. Firefox is 10 million lines of code. The GNOME desktop framework is 8 million lines of code. The GNU compiler is 6 million lines of code. Chromium is 7 million lines of code.

    That's just a smattering of the packages that can be found in a linux distribution...