Hiring, it is said, is the most difficult thing one can do as a manager. Managers who are good at hiring can’t tell you how they do it, and the literature is filled with tales of the horror that befalls managers who do it badly.
I don’t know exactly why it should be so hard to determine whether a candidate will fit well in your team and become a net addition, but it clearly is, and the more senior the person is the harder it gets. There is every possibility that the person who seems so easygoing and willing to learn in an interview, will turn out to be difficult and set in their ways once they get on the job. It is also nigh on impossible to evaluate someone’s skill as an engineer from a test or a transcript or a few code samples. This is especially true in an open-source context, where the definition of “skill” includes everything from “Writes the right code cleanly and quickly” to “Is able to convince unknown and probably cantankerous peers in the community that this patch should get in.” These two abilities, in particular, rarely appear in the same person, at least not when they walk in my door.
(If you are among those who believe that in open source the best ideas always win, I have another conversation to have with you, but for now you can read this post).
You would be right to ask me at this point why I think I’m so smart — what legendary track record do I have in hiring that allows me to pontificate on it? It’s a worthwhile question. I feel like I’ve built a few solid teams over the years, and I’ve taken them through some godawful wrenching changes — “We’re discontinuing your product because we acquired a startup with a competing product, so you all have to learn a new language and work on something completely different in a new community” — multiple times with a very low attrition rate. But I can’t claim any special ability to evaluate people in an interview and I doubt my ability to select the right person is any better than anyone else’s. Certainly, I have hired some great people, but… well, this is public, so I shouldn’t be any more specific than to say I have made a few mistakes too.
I do have one secret, however, and it is summed up in some very bad advice from a song from the ’50s musical Guys And Dolls: “Marry The Man Today.” The song holds that women are better off marrying an imperfect man and then reforming him into what they want him to be, than holding out for the perfect mate to come along. My mother, who had some experience with this theory (sorry Dad), told me early on “This is very very bad advice! Do not follow it!” She is right, of course — in the context of a marriage, it’s a terrible idea, a recipe for unhappiness or worse. In the context of a well functioning team, though, with a strong and healthy culture, it’s not necessarily wrong, especially if you are in the position we all find ourselves in now of having to recruit inexperienced folks straight out of college.
What does this mean in practice? It means I tend to interview people, especially young people, on non-technical criteria. Do they speak clearly and thoughtfully? Do they appear to be self aware, perhaps with a refreshing trace of irony? Did they take the time to find out who I am, what I do, what Red Hat does? If I’m lucky enough to find someone who meets these criteria, I will usually hire them, whether they have any experience in the area I’m hiring for or not. I can teach them to code, and I have a whole team with a whole culture that will teach them how to work the way we work, but I probably can’t teach them to give a crap.
So, instead of spending your time interviewing hundreds of candidates, spend your time building an organization with a culture that will make them into what you need. Hire the developer today, I say, and train them subsequently.