Hacker News new | ask | show | jobs
by ulf 5540 days ago
This is a very big problem: the constant focus on tools and specific technologies instead of looking at the people and their abilities.

A great developer will always be able to pick up a new language/framework/paradigm quickly. So if you plan to have a longer relationship with your hire, you can by all means afford not to check every bullet point regarding technologies. By strictly requiring explicit experience in the fields you are working in, the only thing you really accomplish is to drastically reduce the number of possible applicants.

For example, since Django is still a lot less common than Rails, if you need a Django developer and specifically require Django experience, you will not have an awful lot of candidates. If you broaden your search to anyone with experience with a web framework, you are almost guaranteed to attract some more good candidates. Once you screen those, you pick the best. Best case: he/she was already familiar with Django, congrats to you. Worst case: the dev was not familiar with Django, but still a better fit than ALL the candidates with Django experience. Sounds like win-win for me...

1 comments

I think us developers all tend to know this. But for some reason most employers still don't get this. Almost all job listings look for candidates with specific experience in technology X, rather than just all around smart and able people. When I am job hunting these types of employers are an immediate turn off for me, but they are by far the majority. I wish we could succeed in convincing employers to look at the bigger picture.
While I agree that you probably miss out on finding a lot of great candidates, there is a significant advantage in finding someone that already knows your chosen platform.

Already knowing the OS and Tools allows a new hire to focus on understanding the business domain quickly. For some companies, that's far more important than raw technical ability.

The "quickly" argument is a strawman, if you plan on having a working relationship that lasts longer than 3 months or so. If you just need someone to upgrade your current Rails 2.3.8 project to 3.0.6 and then move along, by all means get someone with Rails experience.

But if you intend to employ that person longer, the specific experience is of diminishing importance.

That's why I usually try to describe myself as a bard of programming. Pick a language. Pick a framework. I know enough to get started, and I know where to find answers to my questions.
This might be another incarnation of the "Nobody ever gets fired for using IBM" phenomenon. HR are more likely aiming at avoiding errors, and not necessarily hiring the best people possible, if those come at a risk. So you can always say "but he had x years experience with Rails" if the hire doesn't pan out.