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.
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.
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
This. The more specific the req the more easily you can say "no one in the country is qualified to fill it" and get an H1-B.
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.
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.
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.
You know, in the six months you've waited to find "the right one" you could've trained a promising applicant and been on your way? Now your six months behind and still waiting for the one. That, to me, means you didn't actually need day one results.
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.
Ok. I am confused. You don't have the time to have someone on staff, helping with 50-70% of the job, but you do have time to search for 8-10+ months with no one filling the job?
Did I read that correctly?
Ok, I give up, why you?
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.
Couldn't you have hired somebody at the lower rate you were looking for 6 months ago and trained them to be proficient by now?
You say you don't have the time to train them... but for the last 6 months, you've been short staffed, having to do the work that this new hire is supposed to be doing, and searching for and interviewing candidates? With all the time you've invested over the last 6 months in looking for the "perfect candidate" and the extra money you are paying to actually bring them on board, you likely could've just hired someone who is mostly qualified (at the lower rate) and then spend the time you would've spent reading resumes and interviewing candidates to actually train this person...then you have them at a lower rate, and they can help with some aspects of their job while they are being trained.
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.
this is not the process to get an h1b candidate. this process is to process a green card. it's a labor certification process.. for the sake of "labor protection", the employer has to say to the government..look i didn't find any citizen or permanent resident for this job.
--- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme,
"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?
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?).
Pssst, wanna buy a bridge? Those absurdly specific job listings are to justify H-1B's. Promotions are promotions, and no one sees them as favoritism unless favoritism was the basis for the promotion. Absurdly specific reqs would be seen as favortism, if one favored Bob, when everybody knows Charlie does a better job and has all the necessary skills.
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.
Glut of Software Engineers? Where the hell are you pulling that from? Maybe Google has a glut of software engineers applying to them because they are a massive company in the industry, but your average or even above average software shop is starving for software engineers hence why they pay on average 60k+ to college grads and 150k to 200k to someone experienced. That is simple economics, because if there was a glut, then they wouldn't be able to command those kind of wages.
It's not about Bob vs Charlie, it's when you want to promote Bob but corporate/government policy demands you have a public listing and review external applicants. That happens very often in big companies, but in reality the person who is already employed there, experienced in the exact subject matter and in line for the promotion will with 95%+ probability get it. Often there's only one internal candidate because everyone knows if that person wants the job, they'll get it. Same thing if you have to hand off a purchasing decision, if people have already decided on a solution they'll write a very detailed requirements document that only one product could possibly fill. It's simply so that if people don't have the authority to make the decision they'll try disqualifying all other options.
Live today, because you never know what tomorrow brings
No, I have seen overly specific job posting that only had local applicants and went to local people. They are written that way because they are written by idiot HR people based on loosely answered questions from an idiot PHB.
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
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?
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.
The only people who take jobs where they're doing exactly what they've always done are people who have been kicked out of doing exactly what they've always done.
More competent staff have a constant interest in learning new things and if you're not willing to offer that in the job you're not going to get competent staff who can take your IT forward.
Your philosophy sounds like an awesome way to ensure your company remains consistently mediocre in terms of IT at best, or on the path to obsolescence at worst. Certainly though you're never going to have an IT department that can compete with companies that are forward thinking and looking to constantly improve though.
Hiring people who don't know everything about the job is the best thing you can do, it's far better to have someone who is a highly competent fast learner with a genuine fascination with what they're doing because it's new to them than it is someone who is bored of it but "does it because it pays" and has shit productivity because they frankly don't care about the job, just as you don't care about their needs either.
You're right that jobs are about getting work done and tasks completed, it's unfortunate that you're entirely unaware of the needs of people required to optimise this. Maybe you're staying afloat, maybe you're struggling, maybe you're even doing well right now, but I guarantee you that your attitude is sacrificing you profit potential, and I guarantee you you're only one of those little upstart's startups away from having the rug pulled right out from under your business.
"I couldn't understand him", says the xenophobic manager.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC