Ask Slashdot: Why Are Tech Job Requirements So Specific? 465
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?"
Re:To hire specific people (Score:5, Interesting)
Re:To hire specific people (Score:2, Interesting)
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.
This does happen, as employers themselves have told me.
However, I think it's more common that they're just idiots. I work in a large tech company, and applied for internal reqs (no labor department requirements. And many job listings are as restrictive as OP describes. Months later, they still had not been filled.
Another slant... (Score:5, Interesting)
We post specific 'requirements' fully aware that no applicant will meet every single one (well, it happened once when someone applied for a position after having left our group a few months prior). For us, it's more about describing what the job will entail and attracting people who wouldn't mind working with the stated technologies.
We had once upon a time not bothered listing the technologies we already knew a candidate would not have experience with, but we were inundated with applicants that made clear they were unable/unwilling to work with things they were not already familiar with.
Now we list things knowing full well applicants won't have experience, but we still get applicants and almost always they might be a bit concerned they lack the 'requirements' but they always had the will to entertain learning new things and usually seemed to have the ability to actually become proficient.
I of course have seen the more common thing, some 'public' job offer that was tailor made for a specific guy, but I know first hand some of these things are crafted with total awareness the requirements are not going to be met.
The opposite, "unicorn", problem in UX job listing (Score:4, Interesting)
Funny, in the UX world, the opposite is a well known issue. That is, most "UX" job listings will say that the requirements include coding (not just front-end stuff like CSS and HTML, but you should have built your own kernel from scratch just for the love of it, and please include your github), a full range of user research experience (and show you process), proficiency is three prototyping tools (and this better look polished, though... prototypes), and mastery of Creative Suite (and show your elegant, gorgeous interfaces).
In reality, nobody does al this. And if they did, how would they fit in to your team and workflow? I suspect most recruiters and hiring managers, especially in startups, don't really know what "UX" is. And especially in startups, they think it means, "I have this wizard idea – you just have to build it." (This often correlates with the "I don't need to learn about users; I took this class in B School so I know the market.")
Re:To hire specific people (Score:3, 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?).
It may be to hire specific people, but it might also be to get someone that can immediately do the job without a whole lot of re-training
and requesting new or different equipment or new software. Perhaps this comes right back to hiring specific people.
Not every employer is willing tu pit up with the 6month retooling and retraining period that bringing in someone new withe their own pet tool set and their own hardware demands. Many know the job can be don with the tools at hand, and the systems can be maintained without yet another gratuitous re-write because the new guy thinks the old guy was a total idiot for using language A when any fool can see the job absolutely needs to be re-written in language B, and that rewrite can be finished in about 9 months. But only if the new guy gets this particular equipment, and is given 3 months to re-document the entire system, starting with a needs assessment and interviewing every person in the company.
In short the IT profession (at just about any level you care to define it) is often a bunch of prima-donnas. And finding someone who can take over a job and successfully manage it just as the guy who died, without a bunch of demands is often the most cost effective way to achieve results.
Jobs aren't created to make perfect little playpens for budding upstarts with their own ideas. Jobs are created to get specific work done and tasks completed.
You got your own little pet methods and tool set, open your own business. Don't use my business for your little drama in three parts.