The art of hiring software people

A friend of mine recently asked for advice about hiring, suggesting that I had a "pretty successful record" of hiring. I suppose that he's partially correct, but he isn't familiar with the times I crashed and burned back in the day. I haven't really thought about it deliberately, not in recent years at least, because early in my career I treated it more like a technological problem where I just had to match the right keywords and like magic have an awesome team.

Mercifully, this year I only had to hire two people, but the search was pretty long. Being able to use the pool of an entire nation as a remote organization sure helped, but in some ways it also made it harder because you attract more noise that way. By sheer coincidence, I hired two people out of the Commonwealth of Pennsylvania, so not local to me or the mothership.

My last hire fail was a few jobs ago. It was a remote person who ended up having the mistaken impression that being remote meant you didn't have to collaborate with the team. He lasted two days before he quit voluntarily. My biggest mistake ever was a in the midst of a consulting contract many years ago, where I had to put together a small team for a three-month project. I hired a guy who would bill 10 hours a day, but his output volume was terrible. It was technically correct, but we weren't going to deliver anything useful on the budget we had, and I let that go for weeks. Lesson learned.

So what's the real "secret?" I would narrow it down to a few simple things:

• Do the gap analysis. What can't your team do that you need it to do? Now plus it a bit. If you need someone with deep experience in a certain framework, look for that person, but with extras. The soft skills are the best extras, and peripheral tech skills help too. It's OK to aim high here.
• Always ask in the phone screen about their learning process. You'll sniff out the fakers quickly this way. Anyone who can't describe how they learn a new thing isn't evolving. Learning is the first stage in problem solving, and if they can't convince you that they're good at that, run the other way.
• Understand their mentoring relationships. If you're hiring a newbie, find out how they have taken advantage of people willing to teach them. If you're hiring an expert, find out how they make people around them better. What you really don't want is the person who goes heads-down and just churns through assignments without interaction.
• Value business and customer empathy. I know that the stereotypes of technical people imply all kinds of nerdy constructs that lack social skills, but that's nonsense. The best software people want the "why" in what they do, and want to connect to it. This makes for better outcomes every time.
• Be thorough in the technical assessment process. Most medium to larger companies have a process for this, but if it's small or a startup, you'll have to design that process. Don't do the bullshit brainteaser dotcom nonsense, because you're not a psychologist qualified to see "how people think" in a way that usefully improves outcomes.
• Above all, the most important advice ever given to me was, "Don't settle." If I look honestly at my bad hires, this is where I really failed. Look, I realize the market favors the workers, but you need to work harder to sell your team to the people who will really improve it.

I don't think that any of those points are unusual, controversial or difficult to arrive at. The environment that you work in definitely makes a difference though. Companies that are not software companies (well, a lot of the time they are and they don't realize it) tend to look at people as interchangeable cogs, which of course they're not. At a company that nerds hard, you don't have the pressure of simply filling seats.

This is my art, yours may vary. Be patient, don't cut off your ear.

(Disclaimer: These are my opinions, and not any kind of official platform of any employer, past or present.)