If you’ve ever hired someone under pressure from someone above you, you know exactly what I’m talking about.

“We need an iOS developer! We need a Rails guru! We need one more Java developer and we’ll get the launch out on time!”

And you know exactly what the result of this is: you get a hired gun who might know the technology or skill you want, but doesn’t jell with the team. Or you switch technologies and that hire isn’t happy to work in the new stack. Or after a while, you don’t need as much of that skill any more and you end up with layoffs (or downsizing by attrition) that leaves everyone unhappy.

Despite these obvious results, it still happens all the time. You can see the effects everywhere: standard job requests have slots for “Skills required”, and recruiters use resume filters that look for specific acronyms.

Worst of all, candidates think they need to learn certain technologies to get hired (because, most of the time, they do). They focus on becoming an expert in a particular technology and then walk into interviews firmly set on working in that technology. You’ve no doubt seen these candidates before: they focus solely on the benefits of whatever technology they know. They subconsciously defend the technology and pooh-pooh others because they have so much sunk cost into the tech. It’s a vicious cycle. There’s almost no way to end an interview with me faster than saying that your career goal is to become an expert in a particular technology (even if we happen to use it).

The reality is none of this matters. Really strong engineers can learn a new technology in weeks (if not faster). We even had undergrad CS interns with no Rails/JS experience this past summer who became productive members of the team in just 2 weeks. Hiring for experience in a particular skill is really just judging a book by its cover, assessing a candidate by one of the most shallow criteria possible.

(Now, some might say that a candidate with Rails experience demonstrates a forward-looking, cutting-edge engineer. I do agree about that in part, but then you should consider Django engineers, too, right?)

What really matters? The two A’s: Attitude and Aptitude.

You want team players who believe in your company’s vision and culture. You want someone who will stay loyal to the team when the numbers aren’t growing as fast as you want. You want someone who will help their neighbor with their work, instead of worrying about getting all the credit. You want someone who will help further the company’s goals even if that means doing work they don’t like to do.

You want someone who can learn new things quickly. You want someone with strong fundamentals (those things that are really hard to teach). You want someone who can grasp abstract concepts quickly that aren’t always well explained in documentation. You want someone who can creatively see how different APIs can fit together to make a fantastic whole.

So hire for attitude and aptitude. And stop hiring for acronyms.

It’s a lot more work (more interviews) but it’s worth it. You’ll be hiring for The Future instead of hiring for Now.