I will never forget the experience of leaving a company and being asked to come up with a job req for my position. I came up with a reasonable one, that got handed to a manager who immediately added a bunch of standard boilerplate. I took that version to his boss and explained why this seemingly innocuous boilerplate would result in telling capable people that they didn't want to work there.
That manager agreed, the req was changed, and I was left wondering how much of the problems they had had with hiring decent people over the years was due to their inability to write a decent job req.
I once worked for a company which specified that developers must always be on-call for support issues and be willing to travel. In reality, developers were never even 2nd tier support, and travel was rarely even offered as an option. Management couldn't understand why including such language might have dissuaded applications.
Hmm.. this viewpoint needs a bit of balancing:
- An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then the developer is at a disadvantage in this early stage of the relationship because it allows the employer to put out a ridiculous sounding job requirement yet still get a decent developer by playing the numbers game (interview lots of devs; hire one temporarily and fire them if they're no good.. then hire another etc...).
With that in mind, lets look at the points:
#1) We need some guy who should probably know all these things because we use them all.. somewhere.. in our organization. The more they know all these thing, the more useful they'll be to us from day 1.
#2) We need someone who has a pair. Either from experience or sheer will. Come in and show us that you're the one we need. If the big numbers scare you, then you're probably not our guy anyway. We also use a few old technologies that have served us very well - it would be fantastic if you already know them.
#3) You're not a unique or a beautiful little snowflake. You'll find out how we work when you get here. If you can't adapt, you'll leave - probably against your will.
#4) The last guy who did this job was awesome. He worked hard to help us become who we are now. We expect no less of you.
#5) We do things a certain way and it seems to be working for us. We expect you to respect that, considering we don't even know you yet. You'll have plenty of opportunity to help make this a more welcoming place if a) we hire you, and b) you don't forget all these pain points once you come on board, and are motivated to do more than just your job description.
Jobs are like girlfriends (or boyfriends) are like most relationships. They may or may not start out smoothly. You'll find out that they're single (existence of job ad), kinda cute ($, benefits), and maybe, but they might only be nice to their friends and a firewall to everyone else (job description / initial response etc..). They are all different, and it is up to you to find one to fall in-love with.
#3) You're not a unique or a beautiful little snowflake. You'll find out how we work when you get here. If you can't adapt, you'll leave - probably against your will.
This one is interesting. Now, I would never consider myself a "unique or beautiful little" anything, but I do strive for excellence and I think most good developers/DBAs/any other position that requires any creativity also do that. This does mean that the good ones are not cogs where you can easily substitute one of us for another. I would be reluctant to work for any company that wanted to treat me as a replaceable cog. While I have done it in the past and would do it again in the future if I had to, I think and hope I am long past the point where I would have to work for a company like that again.
As for the adaptation, I agree to a degree. Starting any new job involves adaptation. With that said, what kind of adaptation the company expect plays a large role in how interested I would be in the job. A company that expects me to adapt because they are on the bleeding edge of tech, or wants me to work with something that is both new to me and interesting will find me quite eager. One that expects me to adapt because they are using say SQL Server 6.5 on Windows NT will not find me so eager.
If a company is hiring commodity coders to create yet more basic CRUD apps, then the company holds all the cards and can be very picky. If a company is looking for truly good, experienced developers/DBAs/engineers that are capable of working independently and substantial new projects, then the company is no longer looking for a cog in the machine and they are more likely to find a good candidate by remembering that fact and acting accordingly.
> "An employer has money and needs a developer. A developer needs the money. If the employer has foresight, then the developer is at a disadvantage in this early stage of the relationship"
Frankly, if you approach hiring with this mindset you're only going to get a good developer through sheer luck. As evidenced from your justifications: you're searching for the cheapest cog.
If by cheapest you mean, a good cog for a good price, then yes, that is exactly what an employer wants. At the end of the day, everyone likes to feel like a winner.
While it would be nice for everyone to be great and welcoming from the outset, it isn't realistic to have that expectation. If we inspect the job ads out there, it is pretty obvious that many employers feel that they can get away with a crappy job ad but still get the cog of their needs with it. So this may not be sheer luck - there are probably more good developers than companies with great job descriptions.
But yes, I do agree that a company can increase its chances significantly by tailoring a job description to its intended audience a bit better (but perhaps they already are? ;)).
You can tell if someone is coming up to speed within the 60 to 90 days associated with most contract to hire jobs. What you can't tell is if they'll pass that 90 day mark, or if that is actually their peak.
True, but 3 or 4 wasted 90-day trials is a man-year's worth of wasted development time (not to mention the damage trail a string of unqualified programmers will leave through your codebase).
You also have to take into account the fact that the new team members always drain some time from the existing ones. They will always have some problems requiring assistance from more experienced folks, no amount of docs can prevent that. Mythical man-month and that.
If you look on Dice, Monster, HotJobs, or CareerBuilder these are the only jobs you'll ever see listed. Quite honestly I've forgotten what a "good" job description looks like.
One that I've always liked, supposedly written by Shackleton:
"Men wanted for hazardous journey. Low wages, bitter cold, long hours of complete darkness. Safe return doubtful. Honour and recognition in event of success."
I think it's impossible to write one, to be honest. Most jobs suck, and it's impossible to select words that would lead a person to infer a better than 50% chance of non-suckitude.
Rumor around the campfire is that practice relates to H1B applications. Before you ask to look outside the country, you need to demonstrate that you looked inside. And, as the story goes, you're not held to using the same requirements overseas that you do locally.
Ergo: list impossible requirements, tell the government you tried real hard, import a serf that meets your actual requirements.
(For the record the only problem I have with H1Bs, is that the program sends them home by default. If we need engineers, why isn't the program designed to keep them and protect them from employers that might try to take advantage of their status?)
The sounds like a very clever strategy. The kind most middle managers I've known couldn't come up with. My experience is that it's all template language, and the old skill keyword gets replaced with new one.
So instead of needing a Java dev with 10 years experience, they want a Ruby dev with 10 years experience. Just click ctrl-H in Word and replace all instances of Java.
After all, if a company wouldn't settle for a Java dev with less than 10 years experience, so why should they settle for a Ruby dev with less? Managers don't want to look like they are compromising standards.
I can't wait to get hired. The first thing I'll do once I get settled in to my new job is start a blog and start defaming bad job ads. It'll be my new hobby. And I'll never run out of bad job ads. I suppose if there's an actual blog somewhere, making fun of them, then they'll improve their ad writing.
This is designed to filter out people who will die of a heart attack during crunch week. Congestive heart failure in someone with a critical skill can derail a project; not to mention the negative effect on the morale of the rest of the team.
How small are you talking about? We have 2 Developers and 7 Systems Administrators. I would never dream of asking a developer to shift some servers, wire some racks etc. As a control freak sysadmin, I wouldn't want them too either :-)
You have a greater than 2:1 ratio of sys admins to devs? What is it that you do that requires so many sysadmins? My ASSumption is that your devs are writing such bad code that it takes an army to administer the servers the code lives on. But that's just me being an ass ;) Seriously what gives?
As to your point, we are a small shop too, 4 devs and 1 sysadmin. The developers (of which I am one too) partake in everything from racking servers to setting up databases to setting up production load-balanced Apache instances to writing actual code. I find it's better to have developers who know a little about how everything else works rather than code monkeys who just concentrate on their own little jungle of code and throw it over the wall like feces for others to handle.
We do dedicated/virtulal hosting, so we're not 'typical' sysadmins .
I still don't understand what makes it necessary for you to rack servers? If it's sheer quantity, then you should have enough cash to employ more staff. If it's very occasionally, then why can't the sysadmin handle that?
The only time our devs touch a server is when go to the datacentre to see how everything works.
Like the other guy said, it's easier with two people since they're pretty heavy. We only have about 10 of them, so it's not a constant activity for us.
I have to say though, your attitude towards developers is pretty condescending. As a developer and former homebuilt PC enthusiast I actually enjoy learning about the IT side of things. Likewise, our sysadmin keeps up a good conversation now and then about software development, and scripting languages in particular. The best development shops are those where the devs and admins work as a team and trust each other.
Most servers are easier to put in a rack with two persons. And if you do it only very occasionally, hiring a second admin just for that might be slightly wasteful.
I'm not sure which is more depressing: the experience of reading this article, or the fact that it's dead-on correct.
I, for one, can't wait until the shoe's back on the other foot where it belongs. (You know, like when developers have to put notices like "I am not accepting job offers at this time" on their blogs.)
That manager agreed, the req was changed, and I was left wondering how much of the problems they had had with hiring decent people over the years was due to their inability to write a decent job req.