How to Find Crappy Programmers
codeanthem.com
codeanthem.com
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.
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.
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.
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? ;)).
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.
Completely one-sided? Because that's what the rest of the post makes it sound like...
This only works for positions with no ramp up time, i.e. the crappy ones no qualified developer would want anyway.
In my experience, code reviews don't take too much time, make code quality more consistent, increase knowledge-share, and lower defect rates.
The fact that he left should tell you something.
"Men wanted for hazardous journey. Low wages, bitter cold, long hours of complete darkness. Safe return doubtful. Honour and recognition in event of success."
A couple of years ago there were a flurry of postings for developers with at least 10 years' experience in RoR.
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?)
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.
As a developer should I really be lifting or moving equipments if needed? This line will surely scare good applicants away.
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.
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.
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.
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.)