When I hire team members I look for the following attributes in this order:

1. Attitude
2. Aptitude
3. Technical Ability

It’s an approach I learned from @RalphKasuba (he’s not active on twitter) many years ago and it has served me well. Recently I gained even more respect for the approach to putting technical skills last, so let’s start there.

Technical Skills

These are the keywords hiring systems look for on resumes. They are the hard skills a person has learned over their career so far. The heavy emphasis on these things when selecting for initial interviews is one of the many reasons I think that resumes are poor hiring tools. Do I really care either way that you worked with embedded systems ten years ago? Or that you don’t have production experience with a brand new, cutting edge technology that has only really been popular for the past couple years?

Think about it this way: the average tenure at a company I worked at recently was almost seven years. That’s a great tenure. Given the cost of turnover, we’re saving the company a lot of money.

As of 2019, AWS alone has launched a completely new set of products over the last seven years that has revolutionized how we build technical solutions. ECS, ECR, DynamoDb, CloudWatch, Kinesis, Fargate, Lambda, and EKS just to name a few. That means over half our work force couldn’t possibly have experience with those tools. If you look at development frameworks, testing tools, and new UI/UX approaches in addition to those platform evolutions, the way products are built today is much different than it was just seven years ago. Your organization’s ability to evolve its technical products and keep technical debt down depends NOT on your engineers current or past skills, but rather on how well they LEARN new skills.

If you are hiring people with the skills you need today, but ignore their ability to learn and their eagerness to do so, you are locking yourself into a fate of having legacy solutions that will only get more expensive to maintain and difficult to hire for.

Aptitude

Think of aptitude like a ceiling. It’s a subjective measurement of someone’s potential. You can get a feel for this by asking a candidate about times they had to learn something new in order to solve a problem. Ask them what blogs they read, or what books they have read recently. Ask what about the last programming language they picked up, what have they done with it, and what are their observations about how it’s different than others they already knew.

Someone who does not enjoy learning has low aptitude. Aptitude isn’t likely to change. It’s highly unlikely that the adult person you are hiring who doesn’t display an ability or desire to learn is going to suddenly start doing so while working with you. They may be perfectly competent at doing what they already know how to do for you, but they won’t be able to help you evolve past that. It can be very tempting to hire people like this because they may be experts with things you desperately need help with right now.

If you feel forced to hire someone like this, you may want to consider bringing on a consultant for short term help instead. Pairing an expert consultant up with a high aptitude, but less experienced full time employee can be a good compromise. I’ve also seen situations where some companies who have to maintain very legacy systems will bring people on with low aptitude but have those critical skills. That need in itself is a clear reason to avoid repeating that pattern with new employees and the systems they build.

Attitude

Finally, the most important marker of all. Attitude, like Aptitude, is a core characteristic of a person. Are they a “can do,” solution oriented person? It’s easy to think of a hundred reasons why something won’t work, are they they type of person that finds the one way it can? Do they display a willingness to experiment or are they dogmatic? Do they suffer from self-imposed helplessness?

How do they respond when their ideas are being questioned? I’ve disagreed with candidates during an interview and backed it up with incorrect information just to see how they respond. Someone who gets angry or uses personal insults will be a big drag on the team. They won’t be good partners during a code review because their teammates will be afraid of them. On the other hand, if they just roll over and don’t push back at all they may be overly passive and won’t help the team avoid making a mistake. I’ve seen this happen a few times. It’s incredibly frustrating to hear a teammate say “I knew this was going to happen.” Why pay for the expertise if the teammate won’t use it? Note: I also know that creating a safe space on the team so that people feel comfortable sharing things is just as important. This is a two way street, but in this post I’m emphasizing the need for an attitude that pushes people to want to share.

By the time you are interviewing this person, their view on humanity and the world is established. Those things drive their underlying attitude. It may take a couple of interviews to really get a feel for it, but that time is worth it. Bad attitudes are like a virus - they spread. Cynicism and negativity will infect teammates over time.

Conclusion

Take care not to filter someone out of consideration for a job before you really know that person. Their technical skill and experience are considerations, but minor ones compared to attitude and aptitude. The thing to look for in a resume is not keywords, it’s the person’s story, and honestly most resume’s don’t do that well. Your job as a hiring manager is to discover a candidate’s story. Until we get a better tool than a resume, spend more time in phone screens and look at attitude and aptitude before you get too worried about technical skills.

I’d love to hear about your hiring formulas and what has worked well for you in the comments or on twitter.