Almost every job description you see for a software developer has some sort of language qualifier. “Looking for an experienced C# developer”, “Software Engineer (Java)”, “PHP Guru Wanted”, “Ruby Developer”. This is wrong. If you want a good software developer, you shouldn’t care about the language they’ve used in the past. A good developer will be able to deliver value regardless of the language they’ve used before.
If you ask any programmer what the traits of a good software developer are, you’ll probably get a list similar to the following:
- Lots of constructive and varied experience
- Sees the value in automated testing
- Has a good grasp of architecture and systems planning
- Positive attitude
- Self-motivated learner
- Able to identify personal ability
- Motivated to keep improving
Nowhere on that list does it say “excellent with .NET delegates” or “able to use generics”. There’s no one language-specific feature that makes a software developer good at their job. So why are we so focused on hiring based on language experience?
Any value in language experience?
Granted, there is a certain amount style and pattern that you pick up when you’ve used a language. I’ve easily got my 10,000 hours in C# and I’m fairly familiar with the specific language features that makes my code more readable and allows me to write cleaner code. But when I move to other languages that are new to me, I don’t immediately lose my 10 years of experience.
I have learned new languages on my own for personal projects, and sure, it’s probably not the same quality of code that someone with experience in Qt might write. But when I come across something that just doesn’t feel right (a “code smell”), I know to look for another solution or do a bit more research. The ability to notice and react to those code smells is something you pick up with experience, and stays with you between jobs, projects, and languages.
Language syntax, knowing what a class definition looks like, how to access a database - these are all things that can easily be learned, and for the most part you can learn them for free online. Knowing that code duplication is bad, using automated tests to ensure software quality, breaking project components into separate layers; these are all skills that come with any software development experience, not a specific language. You need to focus on experience-based skills, not on skills that any high school student could pick up after a day on the internet.
So how do you hire a hacker?
You hire them based on project experience, and based on passion. If you’re looking for a good software developer, you want someone who is motivated to keep themselves up to date; someone who would be coding in their spare time if they didn’t have a development job. Someone who’s been in the trenches and knows what bad code looks like. Someone who can look at a codebase and identify at least three things they’d fix to improve quality, development time, and/or performance.
You also want someone who can tell you, “I haven’t used much Java”. The programmer who is able to comfortably identify personal ability and identify weaknesses in their own skillset will also be the first to tell you about weaknesses in your own software or solutions. This kind of programmer will avoid rushing headlong into a problem with the only tool they have, instead analyzing the problem and offering multiple acceptable solutions.
Hire for fit, not code completion
At the company I’m with, our very first interview is a culture interview. We decide if you’ll be able to fit into our environment and be productive with the team we currenly have before we even consider your technical ability. We still have whiteboarding problems, but we ask people to write pseudocode, not C#. Because in the end it doesn’t really matter where you put your brackets or if you type “package” instead of “namespace”, the only thing that matters is your experience, your problem solving ability, and that you care.
Any experience programmer should be able to pick up a new language within a few weeks, and be productive in your codebase within a month. So stop getting hung up on specifics and instead write your want ads and structure your interview around identifying passionate, motivated, and experienced developers.
-- This blog post was originally published on Chad’s personal blog on January 15, 2013. --