tl;dr: know which principles matter to your team, and pursue them ruthlessly in engineering candidates.

You’ve probably heard this before: Hire good people and get out of their way.  Problem is: hiring is hard because “good“ is so subjective.

If you put principles at the center of your hiring process, “good” becomes less subjective.  It breaks down like this:

• People provide value in many ways
• The value someone provides is based on a number of principles
• The goal of interviewing is to determine if a person represents the right principles for your team

Focusing more on principles has helped me change habits.  Over the last ten years, I stopped:

• Weighing too much of my evaluation on one question
• Asking gotcha or weed-out questions
• Using the same exact questions for every candidate
• Avoiding time spent on intangibles

And, as a result, I:

• Had more fluidity in my questions, tailoring them to the candidate
• Asked more open ended questions with a goal in mind
• Spent more time on intangibles that mattered to my team and company

This post is meant to be a conversation starter about how to approach principles in hiring.  I’d like you to consider how they apply to your hiring process — to your team — so you can make hiring enjoyable and successful.

Data is not enough

To understand how people provide value, we often start with data. When we evaluate resumes and candidates, there are the usual suspects:

• What school someone is from, what degree or GPA
• How well they answer a pre-formed set of questions
• What companies they worked for
• How many years of experience they have

These are all important, but it is possible for someone to look and sound great and still not be a great fit.  When this happens, it’s possible to see:

• Role confusion: you learn over the first six weeks that a candidate is not as experienced as you thought. Maybe they are struggling with projects someone in their role should be able to handle, or maybe they take too long. Worst case, they just can’t get the work done when you needed someone who could. Now you have a problem.
• Poor mutual fit: this is reflected by motivation and morale. When a candidate’s motivations and principles don’t line up with the team they joined, you can have unnecessary conflict or a lack of motivation in the team as well as in your new hire. This is hard to fix.
• Turnover: when you have a mixture of bad mutual fit and improper skills for the role, you will end up with turnover — either for your team or for the company.  The best case is you find another team that fits the hire while the worst case is you have to let someone go.  Either one is very expensive to yourself, your team and the individual.
• Declined offers: the thing about being shallow in your hiring is that intelligent candidates know it’s happening. Your company is judged based on the kind of interviews you do and what questions you ask. If you seem mechanical in delivery or process, it’s easy to spot, and it’s easy to pass on it.

Why does this happen? Because raw data does not tell you enough about someone’s principles. For example, you can’t tell if someone has a life-long passion for building things based on what school they went to or how they answer your FizzBuzz interview question.

Aside from being soft on principles, question-based or score-based regimens can actually promote “maybes”.  For example — if you had a 4-point scale, what do you do with a 3 out of 4?  What about a 2.5 out of 4?  Or do you only hire 4′s?  How do scores map to solid decisions?

Mapping data onto principles

Data is important, just not enough. You can give data more purpose and value by mapping it to principles.

Consider the SAT. When someone takes the SAT, their score matters, but by itself it is not the best indicator of potential or success.  When schools evaluate potential students, they aren’t just looking at SAT scores — extra-curricular activities and demonstrated leadership matter as well.  Why?  Because universities don’t just want smart people — they want successful people.

The SAT maps to fundamentals.  Using the college example, consider these mappings:

• SAT score: is this person smart enough to learn (the SAT)?
• Extra-curricular activities: does this person have the ability to manage their time?
• Leadership in the community: does this person have good emotional intelligence?
• Course selection and diversity: does this person have a passion for learning?

The SAT is just one piece of the puzzle for a college to determine if someone is smart enough to learn.  Likewise, for engineers, there are many data points.  Here is how they might map to principles:

• Past experience, personal projects, open source contributions, portfolio, hobbies, github activity: Does this engineer have a passion for building things?
• Blogs, conference talks, books written, references: Does this engineer understand things well enough to teach them?
• Specific projects, real-life examples, mistakes made, attack vector exercises: Does this engineer think about security day-to-day, or do they just read about it?
• Syntax, code questions, sample code: Is this engineer as good at [language/framework/area] as they claim they are?  Do they have what we need?

Mapping data onto principles clarifies why data is important.  This leads to clearer, more confident hiring decisions — people adhere to principles or they don’t.  If they don’t support the principles you value, you don’t hire them.

Subsequently, discussions in round-ups or debriefs should be focused on whether or not an engineer meets the right principles, not how well they answered a particular question.

Customizing for the role

Once you’ve covered some of the engineering basics it makes sense to focus on a particular area.  Depending on your team, this could mean distributed computing, front-end optimization or application security — or something else.

One of my favorite questions is around front-end optimization.  I’d ask, “What are your best practices for front-end engineering?”

• Simple enough, but what do I really want to know?
• What they can build, but also how they build things.
• Does this engineer build things the right way?
• Has this engineer actively improved the way they build things?
• Does this engineer follow standards?
• Does this engineer suffer from not-in-house (NIH) syndrome?

Those types of answers are hard to measure and not found with your typical algorithm or FizzBuzz questions.  If you don’t get to answering these, you’ll never quite be sure about someone — or as sure as you’d like to be.

For me, the best thing about this question is that it’s simple and flexible.  I can always remember this question, there’s no right answer, and it’s open ended enough to let me take it wherever I need to.  I can dig deeper on technical details or dig deeper on direct experience — whatever I need to do in order to get at the engineer’s principles.

What kinds of domain-specific questions would matter to your team?  How would you like an engineer to build things?  How would you get that out of your short time with them?

Final word

If all else fails, try to understand:

• What kind of person are they?  Would you want to work with them? How do they handle feedback?  Are they a good person?  How do they work with a team?
• What can they build?  Do they build teams, products, libraries, utilities or cultures? What do they _love_ to build? Do they do it in their free time?  Could they build your product?
• How do they build? What are their engineering philosophies?  What are their best practices?  Did they help define them?  Do they actively improve these over time?
• How do they approach metrics?

If you understand these about your team, you can intentionally look for candidates whose principles line up with yours.  When that happens, you have a situation where your candidate is more likely to be successful. I’ve seen this work time and again, and it leads to stronger performance, better culture and higher retention.

You’ll notice some trends here:

• These aren’t simple questions to answer.  You need all sorts of data and directed questions in order to form an answer.  There is no silver bullet question.
• They are very hard to quantify.  Intangibles and other things that matter usually are hard to define or measure.
• It’s not something you apply a point scale to.  People practice a principle or they don’t — there is no ‘try’ or ‘sort of’.

And that’s why interviewing is an art.  Your data and questions are all signals, but in the end, what allows you to really make sense out of it is what your principles are and how well the person you’re talking to practices them.

Remember: It’s hard to hire good people and get out of their way if your definition of good is flawed.  Know which principles matter to your team, and pursue them ruthlessly.