Let’s say you have an opening on your technology team: An urgent need for engineer that will expand your application written on top of the Spring Framework in Java. You use Puppet for deployment, and Jenkins for managing your builds. So naturally, you craft a job description that says “must know Spring, Jenkins, and Puppet.”
You look hard for a perfect dev for the job and find one. She’s been writing code in Java for the last 10 years; and Spring was at the core of a big project in the past. She has experience with Puppet. You proceed with the hire — and the new dev flies through the assignment and all is well.
Six months later though, you realize that your current Spring-based stack isn’t scalable; that you must switch over to Hadoop and HBase. That your front-end needs to be redone in Ruby on Rails or you won’t be able to evolve it to keep up with your competitors. So you switch.
But that dev you hired is struggling in the new environment. She’s really uncomfortable with Hadoop, and a few months in, still asks others for help with basic tasks.
You made a bad hire.
What? She was perfectly qualified for the task at hand! She did awesome in the beginning!
Exactly… in the beginning. She was doomed to fail from day one, because you hired for specific skill, as opposed to for the ability to pick up new skills.
In this day and age, there’s only one thing that’s certain: technologies of tomorrow will be radically different and dramatically better than what we use today: Postgres will outshine MySQL; NoSQL databases will trump relational in many scenarios. Hiring a full-time narrow specialist – someone who’s worked on exactly one technology stack throughout their development career – is a recipe for disaster if you expect your environment to change, either form a business or a technology standpoint.
So I invite you to hire for demonstrated ability to learn, versus specific skill in a technology-area-du-jour that you happen to have in your stack.
Wait… what are you saying? If I have a Ruby on Rails app, I should hire someone who’s done Django and PHP and C++ but no Rails over someone who’s been doing Rails their entire career?
Yes. This is exactly what we did at Wetpaint: most of the developers we hired had no or little experience in Rails.
Yet we are a Rails-based site with 100 million monthly page views and a significant codebase. We hired folks who’s experience has shown that they can pick up new technologies quickly. So they picked up Rails quickly; and then when we needed to do Hadoop, they picked that up too. And responsive design. And machine learning. I have little doubt that we’ll do great with the fancy new technology X that surfaces next year and revolutionizes the industry – because high velocity of learning is a core competency of the team.
How do you interview for the ability to learn?
—Look for radically different technology stacks, roles, company sizes on the resume.
—Ask the candidate about how they learn; those that have picked up a lot of new things in the past will be able to describe a thoughtful approach to learning and give an example of something they learned recently.
—Inquire about interests outside of work. A good sign is broad, diverse interests: those that enjoy learning get good at it over time.
This article was originally published as a guest post on Geekwire; it is republished here for the readers of this blog.