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?"
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.
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.
Usually when it is a very specific requirement it is an Open Request that matches very well to a target candidate. Depending upon laws, contracting or sub contracting regulations, there is a requirement for an open job offer, and it can't be just given to the person that was targetted for the hire.
My sense is that a lot of the super-specific postings are written that way because the folks doing the hiring already have someone in mind. So they can say, "Candidate X may have an MS from MIT, but they only know Excel 2010 while my coffee buddy Ron is proficient in Excel 2013!"
ScienceSeeker.org
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) A lot of times, job listings to the public are a required formality when there's already an internal candidate wanted for the position. In this situation, the job description will be written to fit that specific internal candidate's skills as precisely as possible.
2) Job descriptions are crap anyway. If you think you can do the job, apply. If the company doesn't give you an interview because they asked for 5 years C# experience and you only have 4 years, you don't want to work for them anyway. That kind of hellish determination to strictly follow paperwork never leads to a fun work situation.
Comment of the year
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.
Because jobs aren't given out by reasonable, intelligent people who understand the challenges of the task at hand in any field. They are doled out by corporate HR goons, who only know how to keyword search resumes from a list of software products that the company uses (without having the slightest idea what any of them do). Employers don't have to worry about "making it difficult for themselves" when there's a massive glut of qualified applicants for every job opening; they just have to come up with arbitrary BS reasons why 95% of applicants aren't qualified.
I am not sure, but there has been some evidence that job seekers target almost impossibly specific requirements to make sure nobody can actually fill the job. That way they can claim that the workforce currently in the US is not enough or good enough so they can ask congress for more H-1B visas to be put inplace to get cheaper work forces.
I've had headhunters contact me with jobs. When I say that I don't meet the list of requirements in the job spec, they tell me that nobody else out there does either, but I'm close enough.
I am on the other end, I have been looking for a senior infrastructure engineer for about 6 months. We have very specific requirements that the engineer must experience with. vBlock, EMC, VMWare, Brocade, Cisco MDS, Commvault, Avamar, data center migrations, and Azure and/or Amazon glacier and a few other specifics that would be nice. Any single one of those we will let slide but not more than one.
In my opinion, IT departments have been cut so thin, I need someone with the experience on the stuff we have right now that can pick up and start going. We don't have time to get the person up to speed. Sure, in 12 months when we are going in a different direction with something new I'm sure he.she will be able to adapt as almost all of us have over the years and pick it up but that does not help me now.
I said I've been looking for 6 months, we've had many people interview but the qualified ones wanted more then we wanted to pay. That was an issue I had to deal with HR and our CFO but that has been resolved and now we are asking the going rate.
To sum it up.
Our specific requirement are because we don't have the luxury of molding someone into our environment, we need someone at a senior level to step in and take charge with plans, processes, and hands on work with very little oversight. In the junior and admin positions things may be different.
If you can reduce the number of candidates you need to evaluate and interview, you are saving plain money. More effective to have them do the filtering in a distributed manner.
Of course, you might miss the perfect candidate that way as well. But, you cannot really put a price to that.
What you should take from a list of specific requirements is that they don't know how to write a good help wanted ad. Contact em (a dev, not HR), be up front that you don't have what they're listing, but that you have experience in the skills behind the tools and that you learn quickly.
As others have said, one reason is to tailor the requirements to a specific internal or external candidate. Another is HR people who don't know the technology or the jobs and rely on system and/or internal documentation. They then punch the info into the requirements. They also punch them into the resume screening software. Now you know why it is so hard to get an interview.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
HR departments would rather keep positions vacant for long periods of time than to settle for young whippersnappers who think they can learn anything in a week just because they know a bunch of other riff-raff they've never heard of. If they were more efficient, they might be out of a job.
Spent All My Mod Points
This is pretty well documented. In America if you want to hire someone for a tech job on a work Visa by law you have to "prove" there is no American capable of doing the job. The easiest way to do this is to have very, very specific requirements. There are law firms that teach companies how to do this without breaking the law, and the gov't is pretty much complicit in this (thanks to 30 years of non stop attacks on perceived 'Bureaucracies' brought on by people that don't like the DMV). Compounding this you have schools in India and China that exist to rubber stamp people with any qualification needed.
It mostly works because the vast majority of tech workers aren't MIT graduate rock stars but rank and file workers. There's nothing wrong with that, but it means you're easily interchangeable. But us tech workers also have big, big egos, so we're convinced that Unions and lobbying to protect your interests is for losers who just couldn't hack it (and if they lose their jobs and end up a Walmart they blame themselves anyway...).
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Because job training is a thing of the past.
They are testing your lying skills
Table-ized A.I.
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.
In many cases, it's because they don't want to pay to train you. And that includes paying for your time to get up to speed. There's a lot of time spent already understanding the deployment and development environment. If the company is working with a specific set of technology, then bringing someone in that has used related technology is often not good enough. There are specific design patterns that you use with different technologies, and specific ways of applying them for that technology. And they might not have people internally that have time to help you figure out the best way to do things, or maintain the garbage you build on your own because you don't have experience with these things. Love it or hate it, it's the way things go sometimes. And if you hate it, don't apply to these places. Of course, there are plenty of companies that see this stuff and think that's the way to do it - but don't need it. So, now you have an industry following "best practices" that don't apply to them... do you want to work at these companies?
Posting as Anonymous on purpose.
We typically put out VERY specific requirements for positions when we have a particular person in mind. We can't just hire that person (fair hiring practices etc.) but we can target the position description so that we get a smaller candidate pool that happens to include the person we had in mind. We usually still end up needing to sift through 40-50 resumes and end up interviewing 4-6 people (over the phone or on-site) and, through this process we have found other people in addition to the person we were targeting... but we don't have to weed through hundreds of people just to get to the one we really wanted....
because he works harder and can write a paragraph in English with substantially fewer grammar and syntax errors.
Things are so complex these days that even a small subarea is its own big world.
A past requirement of "being good with computers in general" might today be an equally large job than of fully mastering some modern API.
(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.
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.
XML is like violence. If it doesn't solve the problem, use more.
1. To get more H1-Bs in
2. To accomplish a specific, often short-term goal
3. Empire building (hiring a lot of specialists under you makes you more important somehow)
4. Limit the number of applicants
5. Increase the odds of a good match for the company
I think the first one is obvious even if it's not universally applicable. The second speaks to a larger trend of short-term goals and contracts. The third is one I experienced only recently and it turned out the actual skill and capability of the individual isn't relevant once hired. If this manager has eight people under him, he's more important in some eyes than someone who only has two or three. Limiting applicants is the job of HR drones so when a job description is created, the IT people don't want good candidates weeded out because of a failed keyword matching process. It's not a perfect answer but it helps. The sad reality is that large numbers of unqualified people will apply for jobs they aren't suited for or simply aren't capable of performing. Being specific does act to limit that to some degree. (It's hard to keep assholes, cert chasers and pretenders out) And the fifth is admittedly redundant. Genuinely qualified applicants should still be able to get through the filters...hopefully.
One thing I suspect of many job descriptions is that some of the requirements aren't really requirements at all. But if they go with too small of a minimal list, it seriously makes it hard to screen and filter. Turns out there's a lot of unemployed people out there -- more than government figures would like to admit.
I have hired dozens of software engineers over the years. Most of the time I get approved to hire a new staff member because i) the project is late or ii) somebody critical has just left and the project is at risk of being late or iii) its a new project that I have to quickly staff or it will be late.
I usually assume that it will take 4 to 12 weeks to find an appropriately qualified engineer, then 2 weeks for said engineer to give notice at his/her current job and then 2 months to ramp up on our existing product stack. During these 14 to 22 weeks, this new resource is either not providing any benefit to the project or is actually slowing the project down (ie during interview phase and during ramp up phase). This is always bad news and no VP ever wants to hear that velocity in his/her pet project cannot be improved for at least 14 weeks. Now imagine that I have to add another 1 to 2 months of slowed velocity while this new engineer upgrades his or her skillset (or occasionally downgrades to an earlier version). Ugh.
That is why there is a huge preference for people that know the exact tool chain and software stack that the project is already running. Time.
However, I (and most managers) personally don't care if you have some specific sub release of SomeLanguage++ 5 (for example). But you ought to have coded SomeLanguage++ professionally and well within the last few years on some significant project where you can point to some kind of value that you added. Your 2 months of SomeLanguage++ 3 experience from 2001 is not interesting to me.
At large companies, the HR department may very well screen on precise versions of a software stack. Solution: use google to figure out what is significant about that release (if anything) and how it differs from your knowledge about the stack and then add that specific version of that software to your resume. The dev manager isn't going to care that you only used PHP 5.4.3 and not PHP 5.3.25.
Even better solution (assuming its not the gov't or some massive corp): Find out who the hiring manager is and somehow get introduced to them. The devil you know. I totally prefer to hire people I have met that are known to people in my network. Why? Because I trust my network. I do not trust the Internet.
Either way, the manager will want you to be able to prove in the interview that:
a)You are a good person who is reliable, easy to work with, dependable and can hit the ground running and get me out of the hole that some sales guy dug for me
b) You have specific knowledge about the technologies that you claim to know
c) You have work experience to back up your claims
d) You have the skills and capabilities to succeed as an engineer in my organization
e) Ideally that you can do more than what is minimally required for the job
I specifically recommend that you do not complain about the job posting in the interview. ;) Actually, don't complain about anything in the interview.
I remember last time I was looking for work that one of the big requirements was "Must have valid work permit to work in the United States". They were quite serious about this requirement. If you were a citizen, then you obviously didn't have a work permit and so therefore you did not meet the qualifications of the job requirement.
If you are not allowed to question your government then the government has answered your question.
The job market is very tight, so employers are spoiled for choice. They will seek employees who can hit the ground running immediately. In this environment, they see even a week's learning curve as a waste, and would rather hire someone ordinary who can be immediately productive rather than someone great who might take a little longer. Watch out for this changing as the economy recovers, and jobs again become an employee's market.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
Again, sounds like temporal reverse engineering. Giant tug of war over people from the future stealing from people in the past, and people in the past stealing from people in the future.
I am John Hurt.
We've got ourselves a thinker.....
Argh. The laws of science be a harsh mistress.
I live in a country with nothing similar, yet we still have jobs listing 10 different products as requirements. It appears to be because they want someone who already has experience with the technologies they're already using.
... then the company already knows who they will hire.
People in IT tend not to understand that how the rest of the world operates is vastly different.
We rightfully or wrongly think we should just learn on the job. That we have the skills in terms of general programming and people should just hire us and we will learn whatever specifics are needed.
The rest of the world simply does not work this way. They operate on a you go to school/learn a trade and then you do that specific job... and you should be able to do it. As a result, when you have people trying to hire for a technical position, the HR person will tend to put in the requirements as they know.
Now some HR people are getting about this. Some hiring managers are getting smarter and putting in more general requirements. Some HR people are getting smarter in terms of not screening so much for key words... but the general problem is the same.
The rest of the world operates very specifically. ...
A brain surgeon doesn't just get hired as a heart surgeon.
A divorce lawyer doesn't just get hired into a corporate law position.
A bus driver doesn't just get hired as a truck driver.
An electrician doesn't just get hired as a plumber.
A fork lift operator doesn't just get hired as a crane operator
And if you take yourself out of the tech bubble for even just a second, you would see how the rest of the world works. The amount of training someone else gets before they touch a new piece of equipment or even a process.
Again, I'm not saying how we do things is right or wrong. There are pros and cons to everything. But just understand the rest of the world operates much more like the very specific certifications that you complain about.
Keeps up with the times, $150k is a pretty average rate for an IT contractor.
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.")
When reading U.S.-centric comments on a board operated in the U.S., you need to read "or applicable foreign counterparts" at appropriate places: "The more specific the req the more easily you can say 'no one in the country is qualified to fill it' and get whatever a given country calls its non-immigrant technical work visa."
Sometimes it is as others have noted: Because you are promoting an internal candidate. So ya, the requirements are tailored to that person. This isn't a pure evil "Oh we want to keep anyone else out," kind of thing but that we already have a guy who is trained and qualified on the stuff we use. So if we are to consider anyone else, they would need to be as well. There is no reason we'd want to hire someone that we didn't know, and that wasn't proficient with our systems when we already have someone who is. However, we'll let people apply, on the off chance there is a more qualified candidate.
The other is as you say, needing someone that can hit the ground running because we don't have a ton of skills overlap. We have few IT people and a lot of systems, so we can't all be good at everything. I'm sure there are some arrogant Slashdoters who've never worked in an enterprise that think they can be all things to all people, but you quickly discover that isn't the case. So when we hire someone, we need, or at least strongly desire, certain skills.
Like our last UNIX guy we hired. They had to be good with Linux, since we've been moving all the UNIX stuff to RHEL. However we still had some old Solaris SPARC shit around back then (gone now thankfully). It was running important things, and we couldn't just turn it off. So we really wanted someone who knew Solaris. Not "Oh I know UNIX and I can learn the differences of versions, given time," but someone who could dig right in when one of those POS's went down and needed to be fixed RIGHT NAO!!! So we wanted, and got, an older guy who had a wide range of UNIX experience, including Solaris, rather than someone who was all Linux, all the time.
While learning is great and is required at any IT position, when you have a small team and are looking for a senior position, you don't have the luxury of bringing someone on who doesn't know the technology you use but wants to learn, since they may well be the guy in charge, and needing to support it all right away.
When we hire a student (I work at a university engineering college), we are looking for brains and ability to learn. Minimal experience is no problem, they can learn and indeed we expect that's part of the reason they want the job. When we hire a UNIX lead, that guy had better have some experience on the stuff we use because he'd going to need to be able to do it from day one.
What you're missing is that in the IT industry, specific models of hardware and specific versions of software isn't specific at all. So that's actually a very wide swath. Models have sub-models and configurations and versions, software versions have subversions and minor versions and releases and bulids too. But that's not what I mean.
The techniques by which a given professional uses those tools, how they put things together, their general attitudes towards the big-5 orientations, that's where your flexibility is.
The reasons that job requirements list the components, and not the techniques, are:
a. techniques are very difficult to read, write, understand, and accurately describe. Doing so would be incredibly confusing and never quite right.
b. most components simply aren't compatible with most other components. So much so that any professional with enough experience to have an opinion also winds up having a preferences. He simple doesn't want to fight with other components.
c. within any specific component, there exists a sub-world of amazing things that particular component can do that nothing else can. If you find the right expert, specializing only in that component, there are some wow things.
Because they are risk averse. Because they don't understand skill transferability. Because they fail to value broad experience. Because hr departments are mostly clueless about tech jobs.
Lol I wish I had known you at that time. Solaris shipped with code I wrote fifteen years ago, though I primarily used Red Hat. You might have been replacing my old code with my new code. I sure would have been interested in hearing about the position.
We usually still end up needing to sift through 40-50 resumes and end up interviewing 4-6 people (over the phone or on-site) ...
Read this to my wife, who responded: "Thank you for wasting my time."
You may have hundreds or thousands of people who wasted a minute reading the ad. You have 40-50 (possibly out-of-work) people who wasted maybe 10 minutes and a buck or two sending you a resume, or an hour composing a cover letter. You have a half-dozen who spent hours, and maybe auto expenses, coming to and attending your interview, and experienced hours of stress responding to your people's questions. You wasted maybe a day of their time in the midst of a job hunt. All when you had a candidate you were happy with.
Did you EVER hire anybody except the one you'd started with? Or did you just get a warm fuzzy feeling from having found some possible alternates in case he drives into an overpass pillar during some night's commute?
But thank you for your honesty. Job hunters really need to understand the viewpoint from the other side of the desk. It will help them accept the repeated rejections that result from such "fair hiring" practices.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
they want to pay an entry-level salary for someone with 3 years experience in a product which has only been on the market for 2 years.
Then they're probably trying to poach from that product's producer. But if someone has three years of combined experience including the product and its immediate predecessor from the same company or its licensor, he could probably word an honest resume to appear to qualify: "15 years experience including Microsoft SQL Server and Sybase".
Many of them haven't a clue and ask such intelligent questions during the interviews as: "What is your favorite color?"
Someone who likes a color integral to a company's present or near-future branding is more likely to remain comfortable with the brand.
And when you were a child, your parents probably told you there was a Tooth Fairy. The difference is that what your parents told you is a harmless childhood myth.
So my dentist wasn't gay?
"I have a work permit right here." (produces certified copy of Indiana birth certificate) "It's so valid I could run for President on it in a couple years if I wanted."
I thought employers who presented a bona fide reason why they could not find an American were more likely to be considered for inclusion in the quota.
Because hr personal has no analytic skills. They don't know how to distill information that's given to them. They are told what a department works on and they just dump that into a requirement without understanding that these change rapidly even though they stay in the same category of skills. They don't know how to identify categories. If they had analytic skills, they wouldn't be in hr.
Any guest worker system is indistinguishable from indentured servitude.
I'm currently in the process of hiring someone for a startup. Long story short I got the requirements document that was partially written by an in-house recruiter who basically thought "you're building a Java back-end, so here are all the buzzwords this entails."
So I got a document that said that it required Java, Swing, JAX-RPC, AJAX, XML-RPC, Java Server Faces, Struts, Hibernate, ESB, and about a half-dozen other vaguely related technologies.
*sigh*
Given that I'm the hiring manager I asked if we could revise the list. And I narrowed it down to:
Required: Java experience.
Nice to have: Server-side development experience, experience with Eclipse, experience with JDBC, experience with JSON.
'Cause we're not using any of the other crap that was in the recruiter-supplied bullet list.
(P.S.: We don't have funding now so don't contact me privately about this job. Not quite yet...)
I dunno you would think that if you apply for a job that clearly states you must speak fluent mandarin, then perhaps at some point the job includes having to speak mandarin, no? Applying if you don't have the skills is just wasting everyone's time.
Seven puppies were harmed during the making of this post.
Why suppose there's something underhanded going on? It boils down to ignorance. The managers don't really understand the job and certainly can't articulate it, so they list the things they *can* understand... like the model numbers on the hardware, the programs the last guy used, and so on.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
What country? I know that in Canada this is the case. But in Canada contractors even through tech head hunters work as real contractors (i.e. the equivalent of 1099 employees in the U.S... they have to incorporate). They normally work as a secondary contractor (sub contractor) to the head hunters who act as the primary contractor. So they charge by the hour and $75/hour for a senior programmer or senior analyst is not unusual depending on the market. But I know in the U.S. tech recruiters/head hunters will also often hire people as employees and hire them out for specific contracts. Working as an employee of these companies you often do not get as much. And it all depends on the market. What one gets in New York City is way higher than what one gets in Saint Louis, say.
Also what perspective are you looking at this from? The company hiring the contractor or the contractor. The middlemen tech head hunter pimp companies take a big cut normally. So a end user company hiring the contractor could be paying $100/hour or more, and the contractor might only be getting $65 or $75/hour (again, depending on market).
-- I ignore anonymous replies to my comments and postings.
I look at job descriptions from all over the world, and it's the same everywhere. For short-term contracting gigs, it usually makes sense. For a permanent employee, it doesn't. Smarter would be to simply describe the tasks of the position, and let the candidates figure out for themselves if they can hack it. Problem is, this basically means that HR can't even pretend to contribute anything meaningful to the process. Ergo, it won't happen.
NHA
New Zealand.
From the perspective of the person doing the work.
It largely comes down to the fact HR departments have too much power. They're glorified secretaries and really, they don't know how to find people. They know how to post job adverts and make up silly rules. But in a good company that won't matter. If you're a reasonable match then you should get an interview. That's always been the case for me. Most jobs I've applied and have received an offer that I accepted or turned down have said the person should have a degree - I don't. I've never been forced out of a job and, had bad feedback or whatever. I have friends still from all my previous jobs because I'm good at what I do and when companies don't allow the HR drones to rule the roost, I can show that and I get somewhere.
My current job's spec listed nothing I've done before. On the face of it, I would be one of the worst people to interview. But they came to me and asked, I accepted, got the job and also had one of the best pay rises last year for my performance.
But there are some jobs I haven't got for stupid reasons (and of course for good reasons sometimes) and I've seen a lot of other companies suffer trying to find someone because they want something so specific that it's just not really going to happen. I can only assume, if their HR department isn't incompetent, it's a scam to import some low paid immigrant who only cares about being able to travel somewhere else and will accept the poor wage.
So what you are saying is that $US120K is typical. Since the exchange rate right now is $NZ1 = $US0.81
-- I ignore anonymous replies to my comments and postings.
Axiom I: Generalist IT skills (CS, systems analysis) do not evolve that quickly, but specific ones do
Lemma I: Most IT employers don't don't plan to be around in 10 years - I don't mean they actively plan to go out of business, they probably all dream of living forever or something, but they don't have - and probably can't have - a specific plan for how technology will be supporting their business model at that point.
Axiom II: Younger folks are less interested in the idea of a single-or-few employer career these days, and more willing to leave at short notice
Corollary: Most IT employers don't want to employ someone who has the potential to be a useful employee, but only after they have invested time training them in the requisite skills - they want someone who can start now, finish this 12-month project, and maybe hang on to them afterwards if the relationship pans out ok.
It's an arms race between employer and employee, with diminishing returns. If you are lucky, you will find people on both sides of this relationship who see this for the evil that it is, and move beyond it.
HR people who write these things often have _NO IDEA_ WHAT THEY ARE WRITING.
Your resume is examined first by a totally nontechnical HR person. To them, the job position requires that you have 10 years of experience in Blurg and 5 in Blarg. They see 1000 resumes a week and therefore must filter them quickly by selecting checkboxes. There is no room whatsoever for fuzzy logic here. Either you list the skills and pass to the next round, or you don’t list the skills, and your resume gets thrown in the can. The technical people writing the job descriptions are often marginally technical themselves, so they don’t necessarily know if the combo of skills they compiled by committee is even reasonable.
And I don’t know a way around this. You simply cannot have all the technical people filtering the resumes. They have other work to do. I think at Google, the technical people get involved at a lower level of the process, and I get the impression it’s a burden.
And rather than reinvent the wheel they're looking for someone who has done it before.
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...
If you're working on a very specific project, you need someone with a specific skillset.
I worked for a decade in linux kernel development for embedded telecom systems. The linux kernel has 12 million lines of code...you want someone who has experience with it, at least enough that they know where to start looking when they run into an issue.
My current company is looking for people with experience with a particular open-source project, because it takes months to get up to speed and we're on an aggressive schedule.
No, $NZ180k is typical, which is around $US145k
Indeed you're right. I'm not sure what I was thinking.
I compared it to SOMETHING years ago and saw it was roughly equal. Maybe a QNX distribution, not Linux, or some tiny Linux.
Most of the time, innovation is a luxury in IT. While it is nice to have someone that can change things for the better, the primary requirement is to run the shop. This is why requirement are very specific.
Companies, depending on the position, toss as much description out there in hopes of a perfect fit. They realize that they will have chose from a group of people.
yep...agree...
wanted to add that there are plenty of examples of **non-HR** people being as out of touch as HR
Just look at Penny Arcade's ad for a "Web/Software Developer & Sys Admin: http://www.linkedin.com/jobs2/view/9887522?trk=feed-cmpy-fol-jobt&goback=.bzo_*1_*1_*1_*1_*1_*1_*1_penny*5arcade*5inc*3
a sample:
the whole thing reads like that
I definitely agree HR sucks, not just in tech but across the board...when I hear "HR" I automatically think office-drone functionary who has no concept of the actual business work the company does.
However, I think if we aim only at HR we might miss the target...in the Tech Industry I see a greater inability to relate to other humans at all levels...kinda sociopathic...
Thank you Dave Raggett
Sure they usually ask for some pretty pin pointed skills but as long as you can describe / explain why for instance, working with an HP 5400zl series, is the same as working with the, Cisco 5000 series ( just an example ), you're generally okay. Just be able to say well I don't know X but I know Y and Z and they are like X so I could quickly learn and adapt. That is more so what they want to hear then I know X and only X. I've applied to several jobs where they have the requirement of X but I like to point i know all these other skill that really are the same or very similar and it 99% of the time works.
When I first went into the job market, my career center at my university strongly urged me never to apply to a job where I didn't meet every skill set. Ten years down the line, never having gotten a job that way, I realize now that you just need to have some of their requirements, and apply to them.
God spoke to me
I was hired based on a specific set of qualifications:
- Support experience with a specific corporate website; Perhaps 12 people worldwide could claim to have that experience, and 4 of them do not speak English. I know them all.
- Support experience with three different software applications, all distributed by my employer. Perhaps 30 people worldwide would be able to claim some experience, but half of them at least would not have the depth of experience requested.
- Experience using several specific corporate applications, systems, and databases. Perhaps 6 people worldwide would have that combination of experience worldwide, all of them in the company, and all but one were, at the time, employed on the team I was hired on to.
I was a contractor at the time, and had been doing the job for 6+ years. The corporation decided to convert to full-timers, and the job description was not changed. HR required the hiring team to write the functional and experience requirements specific to the job, and they laid it on. We waited through the internal posting period, and were able to get through that with no other internal candidates being able to offer useful qualifications that justified hiring. When I was hired, now 7+ years ago, it took 6 months for me to be able to work without supervision. I deal with many systems and processes - currently I manage 34 different passwords I use at least weekly, some of which expire every 14 days, and with about 4 different minimum requirements for complexity. Not one of them is written down anywhere, but I use single-character hints to keep them straight, knowing that on one system a hint of 'O' would mean something than on another system. And no, I currently do not use an 'O' for any password.
Crafting those requirements saved the company perhaps 6-9 months training marginally qualified candidates, and preserved a lot of institutional knowledge. Most of this is very difficult to document, though I have my own knowledge base now that is perhaps 60% complete. Much of it goes out of date every 9-12 months due to software upgrades, system decommissons, blahblahblah. We are hiring another team member, and looking forward to training them up for at least 6 months.
I also see a lot of H1-B applications posted, and most I am at a loss to explain what the special skill is that cannot be found domestically. Many pay in the $80-130k range, require Masters degrees, but not specific experience with particular systems or applications beyond MSSQL, Oracle, and Microstrategy, which I suspect are either to retain a current contractor or qualify a specific candidate. All of these applications are actually for sponsored positions with the usual offshore IT contractors You all know their names.
Sometimes, an specially-crafted description is to favor a candidate. Sorry, but you were never in the running. Some, though, seem intended to result in no qualified domestic candidates, and somehow an offshore candidate will have these skills etc. And if you are merely an external candidate, you will never know about the H1-B. No one will ever give you the legal notice. You will never have a chance to make your case.
H1-B is horribly broken. There is already talk of jamming through federal immigration reform by executive order on the premise that most illegals actually entered legally - overstays being the primary problem. Ignoring the logical response, to find and deport them as required by law, many will be presented as crucial to our economy, being key employees, and deportation disrupting corporate operations needlessly. NEEDLESSLY. A lie, but tell the big lie and they believe you.
If we care at all about our nation's economic future, we need to compel an audit of the H1-B and related programs, and enforcement of the current laws, rather than abandoning them due to neglect.
But I'm an extremist.
deleting the extra space after periods so i can stay relevant, yeah.
I recently hired a security analyst at my company. I had the opposite problem; almost everyone I interviewed worked at larger companies, and only had narrow experience with specific software products. I was looking for (and eventually found) someone who was more of a generalist "hacker" type. I don't really care if you've used X antivirus and Y SIEM for ten years because that's what your boss purchased, I care how you solve problems.
I've seen this numerous times and it's usually one of the following cases at work.
1. Sometimes managers have a specific candidate in mind for a job but the rules of the business require that they use a job posting system to announce any openings. So, the opening is tailored to a the person that the manager wanted to hire from the beginning. Very few people will meet those exact specifications and in the end, they'll be able to hire the person the manager wanted from the beginning.
2. Because they know that no one will meet the requirements so they can hire a H1B worker and drive down the cost of tech labor.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
A brain surgeon doesn't just get hired as a heart surgeon.
A brain surgeon also doesn't get hired as "10 years of experience doing brain surgery with brand X scalpels and brand Y CT scanning equipment".
They're expected to train as part of the job, and they're given a certain amount of time and money to keep current.
Hiring managers are usually idiots. They are almost always non-technical people. What does upper management do with good, team players... company men that understand what needs to get done, but have no useful skills? Management. Dude can't even program his VCR... also he still has a VCR... and he's quizzing me on how I'd write a Select statement?
Take this analogy:
What if, as a condition of financially supporting your decision to get married / begin a family (with a boatload of money you couldn't pass up), your parents required that you post an ad to Craigslist and evaluate all reasonable potential spouses who replied? Despite you already having met the person you already want to marry?
I imagine you'd be pretty specific about what you were looking for too.
Not trying to trivialize the situation, just trying to illustrate that it's almost as complicated as dating. There's a lot of things about a candidate that can't be captured in simple qualifications or experience. And staying with a known quantity is way easier than searching for something that may even be better, but highly uncertain.
Many of these comments place H1B's as a target of their wrath. I have never experienced this to be the case, but I also don't like to go around blaming immigrants for problems I created for myself. I have seen (and benefited from!) a job posting being specifically opened for me, exactly, to fulfill some corporate requirements.
I think the people that bash H1B's and internal posts are on to something. These super specific requirements are to reject someone (Americans & external applications described above.) I disagree that this tends to be on the basis of citizenship, but I'm sure that does happen. What I saw was super specific requirements used for was a way to reject someone you didn't really want to work with, because they were basically unpleasant, but probably technically competent. I imagine that this actually classification fits into a large portion of the slashdot community, with the negativity I read in the majority of comments on pretty much every post. At the places I worked as an employee, it was a lot "easier" (in terms of not getting sued, and rejecting someone) to possibly allow them to interview if they seemed technical competent, and then reject them based on an unrealistic, wish-list of skills, as opposed to rejecting them because they kept complaining, or for some other (politically incorrect/illegal/lawsuit-prone) reason.
It is very, very, VERY difficult to fire someone in the United States. Even in "right to work" states, employers have a lot of fear about lawsuits and other employment related issues. I took the independent contractor route, and it is BY FAR easier for me to score clients than it any of the multi-phase, tons of telephone, and in-person, interviews required to be an employee. Wouldn't you want to be extra careful on the hiring side, if the firing side is going to be difficult? As a contractor, if someone doesn't like me, I'm gone in an instant! Between this, and being able to ramp-up / ramp-down my time, it's a way more flexible agreement than permanent employment, and I find marketing myself as a contractor to be much more pleasant than the four or five times I marketed myself as a technical employee.
I hope you find this useful, entertaining, and not too offensive.
-Brian J. Stinar-
This has led to a mindset where the whole of IT has been defined in terms of "projects" with inputs and outputs and companies want to "buy talent instead of careers" meaning that the company wants your work but not you as a person.
This has then led to companies running most things on "temporary staff" like consultants and contractors.
The effect this has had on IT is that knowledge about the infrastructure, systems, their quirks and how everything works together is not retained in the company and IT operations down to the little details are defined by non-IT people who think in terms of "procedures" "inputs" and "outputs".
So when you see something like "System administrator wanted, has to know XYZ operating system version 10,04 LTR, and the systems HPBS and VLSN" you can be sure that this requirement was written by a non-it person who thinks in terms of "inputs" to a problem.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
I'm glad the company weeded you out though. Does a company really need someone with as little horse sense as you?
Anyone who is able to work in the US could apply for a job like that. That includes citizens.
http://lkml.org/lkml/2005/8/20/95
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.
I was wondering that too, but if you're an organization behind a Linux distro, you probably don't have to maintain all upstream code directly.
Escher was the first MC and Giger invented the HR department.
Because they ask the manager what they want and the manager who's also a moron simply cuts and pastes what their software and hardware inventory are. The HR moron passes it along without a single worry or care because let's face facts, as your company throws thousands of employees into the street the last people to go, if they ever go at all are the HR people.
I have come across that small/mid-sized companies usually look for a drop-in replacement of the leaving employee. Sometimes they even ask leaving guy to write the list of capabilities and technologies. Since the technologies and tasks are changing with time and from project to project, resulting job description defines noone but the leaving guy. Once, the company I had worked for, advertised a software engineer who was capable of programming dotNet and VHDL at the same time. In Turkey, a usual hardware developer position includes hardware design + firmware development + PCB design. (P.S. with my limited knowledge from Turkey and Europe)
In IT, development, there are often a lot of different ways to achieve a thing. Version control is one of them, for most basic needs most version control systems offer the same features. Subsversion, mercurial and git? I can use any of them and have all common needs met. So why demand specific knowledge of a specific solution?
Because of shit for brains developers. They are ALWAYS on the lookout for the magic tool that means they don't have to do their job anymore and insist solution X is the only solution until a new flavor of the day comes along.
Here is a warning sign, if your a web developer and the job/project uses more then two programming languages, RUN! It means the developers are hammering in their flavors of the day creating a mass of code in different languages, 9 times out of 10 completely depended on a specific config and version that nobody wants to bother with anymore because their experiment failed and now they want to experiment some more.
I recently did an interview where more and more requirements kept cropping up and more and more languages with the backend being written in javascript, php and python. Ooh yes, I would LOVE to become responsible for fixing that mess. NOT!
Interviewing is like dating, its main goal is NOT to find true love but to ditch the crazies before they found out where you life (but I will get you my pretty oh, yes and then we will be happy FOREVER) anyway, if a job seems to suck during the recruitment process consider yourself warned and move on (but I will never let you escape!)
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
That's nothing... The H/R department at my company lists experience with our internally developed business application as a requirement for outside hires. For real.
There are two types -- ones that get paid by the company doing the hiring, and those that you have to pay if you get the job.
In the first case, you'd stand a pretty good chance of getting the job -- they select a few few (maybe 3-4) people who they consider to be qualified for the job, and then pass it up to the company. Of course, they get paid 20-40% of the annual salary to do so, but it's basically the equivalent of the company outsourcing their HR department. (and they're not a company that's got a requirement that they post the jobs publicly, or the job's been open for too long with no good hits)
In the second case, they have absolutely no problem with wasting your time, because they're not wasting theirs, either ... they can just throw a bunch of people at the company until one sticks, and then they get their money. All for the cost of a person making a few phone calls and maybe restructuring your resume. For a couple of days work (for all of the people they process), they get a nice fat check ... but *you* have to pay them for it. (maybe a month or two of salary).
If you get a call from a headhunter, ask them what company the job is with ... if they're in the second group, they'll never tell you, as you can make the end-run around them and not have to pay them. The first one is often the gatekeeper to the job, and so you can't go around them ... but if you can, you might be able to talk the company into a signing bonus (that they'd have otherwise had to pay to the headhunter).
In the worst case I heard of, the headhunter started pressuring someone to take certification classes to make them more 'attractive' to employers. The way I heard the story, I wouldn't be surprised if they were getting kickbacks from the training company.
Build it, and they will come^Hplain.
These employers are looking for help with a specific problem. They want to pay less than they would to a consultant so they hire an 'employee' with exactly the skill set needed. Beware that when you take this job you will be considered, like the hardware and software, to be disposable. When you are obsolete they will not retrain you, heck they didn't bother training you to begin with, but instead they'll just pink slip you and hire a younger, cheaper model with different bells and whistles.
IT job ads are very specific because the kind of job makes it possible.
When a recruiter is looking for candidates for a hi-school music teacher, exactly what specific skills and certifications could they list? Must have at least 3 years of experience playing Beethoven's Piano Sonata No. 14 in C-sharp minor on a August Forster UP 114 piano?
Think about it. If there were really desperate shortages of IT workers, IT employers would not have the luxury of such insanely specific job requirements.
The non-stop shortage shouting is just done as an excuse to get more offshore workers, to further glut the field, and to thereby lower wages.
HR not understanding tech is like business executives not understand tech, and the answer is the same: you hire someone to sit in the middle as an adapter and translate. It sounds like you were, in fact, being the "business analyst" guy for HR, but you were translating into the wrong language. You were translating from high-detail tech -> low-detail tech, instead of high-detail tech -> HR speak. If you could have filled in all the HR metadata yourself, you no doubt would have chosen the correct ones. The signature of the problem is HR asking "is C++ hardware?". That tells you they're doing a second translation step.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
Both arguments I see are correct. I've personally seen it used to justify an H1-B and I have no doubt the internal promotion after a "public advertisement" arguments are both correct.
Next time I see such a specific placement ad, I may just call up the HR department and ask them whether or not I should bother submitting for a job as it seems they already have someone in mind.
But for the most folks there is a disconnect between HR/Management folks who are hiring and the IT personnel they are looking to hire.
You are handling it in a fashion most don't. You acknowledge that you don't understand the specifics and are looking to evaluate them (if I understand what you are saying) based on their competence and confidence in fulfilling the task you need.
In the other ads you are seeing they have already consulted with "an expert" of whatever value, perhaps an existing employee, and given a list of requirements with perhaps many acronyms. Sometimes it's so egregious that they have mentioned a product with an acronym they have developed internally, so no one would have experience, or asked for more years of experience than the actual software product or system has existed. But the disconnect between the knowledgeable and the one's hiring allows for this interesting dance.
Most of the professionals I know in the IT field tend to focus on soft skills. If you know 60-70% of what is needed and have a proven track record of getting the job done you are more valuable than someone who sought out certs and qualifications with no real experience in the needed cross discipline thinking or in getting things done, whatever it takes. It's tough to evaluate the core strengths that allows a person to learn whatever is needed in a timely manner and complete the engineering or administrative task. It can be easy to get stuck or side tracked, but the one who can find a way through is the one you want.
Good luck in finding the one you are after!!!
"Don't fear death... fear not living..." -me
Agree, but hate seeing companies and employers being so short-sighted.
Seems in one generation, since the dotcom's, the idea of investing in someone, training them, mutual risk for long term mutual gain, is fading away.
Uh, Linux geek since 1999.
Agreed. Does seem often to be the case lately.
Uh, Linux geek since 1999.
Went for a job interview a few years back and they wanted someone with "10 years experience with Solaris 11." I pointed out to the HR screening guy that Solaris 11 wasn't released till 2010 or so, and that asking for anyone with that experience was unlikely to get any honest responses. His reply was astonishing - he said "well, I guess you don't meet the qualifications, this interview is over." Lazy HR folks are not doing their companies any favors.
Organization? You must be joking..
You're like a cook in a restaurant.
Casteism
They want candidates who are self confident enough to ignore all the bull in the posting and just go to get jobs they want.
Quick poll. How many of us have seen job listings with SW/HW experience requirements longer that that SW/HW has been in existence?
There's lots of reasons other than the H1B thing, all of them stupid.
* Tech d'jour. A lot of startups are actually under pressure to list all the latest greatest often fad technologies just to impress investors. This has been my biggest problem lately. I've got years of dedicated study to a core language that I can just stomp the competition with most of the time but oops... I don't have 3 years experience in that framework that came out 2 years ago that takes a few days to pick up.
* Lousy hiring strategy - It's kind of like what I used to observe on dating sites where people would list these absurd shopping lists of must-have requirements. The limits they put on eligible partners, or in the case of hiring, qualified employee hiring pools is absurd. Sure you might find the guy that has all of the things on your list but how freaking long does it take to pick up a newer or older version of something you already know. It's a misplaced focus on overly precise requirements over general quality of the candidate. Some people would rather have the mediocre guy with their exact bullet list than somebody smart enough to pick up near-anything you want quickly. Sadly, I met my wife by getting into a fight with her on Craigslist but this hasn't helped me out with any jobs yet.
* Incompetent leads running the show. We've all met them. They don't want to learn anything after college that they don't have to. Why they stayed in tech, I have no idea but they're out there and sometimes it's just easier to scoot them up to management where they still feel like they have to have their own tech limitations lowering the bar so they can understand what you're doing. Even if it's not really their job to be nosing around in the specifics.
* Lazy HR. Some people will always see it as a resume pile culling process, even when the skills they're looking for are rare or hard to come by in certain combinations. The more reasons they can get to toss somebody in the 'nope' pile, the fewer people they ultimately have to talk to/deal with.
* Lazy teams not policing the HR ad copy. The HR people don't know anything about versions. If it's a clueless hiring manager that's to blame the blame should also fall on the tech people who didn't stop them and tell them that getting overly explicit wouldn't be necessary.