Earlier this week, I explored the frustrating process a startup, WidgetCo, went through as it searched for an engineer who could work on its Ruby on Rails platform. After tepid results, the company's leaders switched gears to look for a skilled engineer who could be trained in the necessary technologies. Here's what happened once they relaunched their search.

Finding a 'Trainable' Engineer

Once it removed the "Ruby on Rails" filter from its job requirements, WidgetCo quickly discovered that its network of advisors and friends came up with more candidates. Some were .NET engineers or Java engineers who had the kind of interface experience WidgetCo needed. Others were Ruby on Rails engineers who just didn't know the front-end technologies. They didn't have someone to hire yet, but they at least had a talent pool to work with. WidgetCo would have to teach whoever it hired some of the technologies. The successful candidate would have to have one characteristic that wasn't in the job description: They'd have to be trainable.

Problem One: How to Train

Fortunately, there were training options. WidgetCo was willing to sponsor the new hire through a Ruby on Rails class at a local technology group. The company's tech lead was also a pretty good teacher, patient and effective at showing others how to accomplish things. He could help, too. There's also nothing like on-the-job training. WidgetCo had a feature branch/pull request model in place and was already doing code reviews. Providing feedback is a natural part of that process.

Problem Two: Was the Candidate Trainable?

How do we know that a candidate is trainable? With just a resume and maybe a phone screen, how can we be sure that a candidate is a good fit? Additionally, how do we know that he or she can be trained within our budget and style? Someone who can only learn in a semester-long structured class wouldn't be a good fit for WidgetCo. The company just didn't have that kind of time or money. However, trainable candidates leave clues in their resumes. Some characteristics WidgetCo looked for:

• Experience with many technologies: For example, if a candidate knows only Java, learning a new language (Ruby) might be difficult. If a candidate knows Java, C++ and Python, learning another language would probably be easier. In engineering, it's a truism that the first language is hard, the second language is hard, and they get a lot easier to pick up after that.
• Experience with similar technologies: WidgetCo uses Rails, which is a Web framework. Experience with another Web framework, like Django or even ASP.NET MVC, should mean candidates had concepts they could apply to the company's particular technology.
• Lack of ego: Learning is a lot harder when there's a big ego involved, so WidgetCo looked for signs of ego, like a need for inflated job titles. Frequent references to rewrites and restructuring of systems can also be signs of ego. They can indicate people who manipulate the system into something they understand, rather than taking the time to learn the system. One or two rewrites is normal, but many rewrites are a sign of something else — and possibly an inability to learn new systems. (This characteristic usually comes out more in interviews than in a resume.)
• Ability to work with different types of systems: The more different patterns a candidate has seen, the more likely it is that a company's patterns will be recognizable, or at least similar to something they've observed. Exposure to many different kinds of systems — across industries or different areas of technology — is another indicator of the ability to learn.
• Knows at least one of your technologies: Learning goes a lot faster when some part of the system is known. It gives the engineer a solid foundation to work from, rather than floundering in an environment in which everything is an unknown.
• Personal projects: Candidates who spend their free time working on personal projects are people who teach themselves after hours. They're comfortable tackling problems in an unstructured environment, which is what a startup like WidgetCo will provide, at least in terms of training.
• References learning opportunities: A candidate who talks about taking classes outside work or discusses going to Meetups or technology demonstration sessions is one who seeks to learn. They're likely to have applied for the job specifically because it offers to teach them a new set of skills. That makes for an eager learner.
• Gut instinct: This characteristic applies mostly during interviews and phone screens. The existing team has to believe that the candidate is trainable. Listen to your gut — can you work with this person and can you teach him what you know?

We Can Work With This

Armed with this new thinking, WidgetCo conducted another round of resume reviews, phone screens and interviews. Ultimately, they found their engineer. He definitely wasn't the kind of person they'd originally pictured. He didn't know Ruby on Rails at all, and he'd never worked in an Agile environment. He was a Java engineer, and he'd spent the past five years building interfaces for a large insurance company. However, he met all the must-have requirements: He could build high-volume data interfaces, he could work directly with clients and engineers at client sites, and he had written an open-source data-integrity checking tool that was quite popular. It was safe to say he knew a thing or two about data analysis. Finally, he seemed trainable. In interviews he said, "I don't know" when he didn't have an answer, and he asked intelligent questions. Between two rounds of interviews he dabbled with Ruby on Rails and came back with some code that, although definitely Java-like, was at least syntactically Ruby. He also asked for and accepted feedback on it. This was as close to the perfect candidate as WidgetCo was going to get any time soon. And that's how the startup and the engineer met. In my next post, I'll talk about the retraining process itself, and we'll reveal the end of the story.