How To Hire Engineers: Step 0, What To Look For

Welcome to the second in my series on hiring software engineers! This post describes the zero’th step in hiring: figuring out what you’re looking for in the first place.

How to Hire Engineers:

• Step 0: What to Look For (this article!)
• Step 1: Sourcing
• Step 2: Filtering
• Step 3: Screening
• Step 4: Assessing & Deciding
• Step 5: Closing

I might as well confess this up front: unlike most “what to look for” posts, I’m not going to tell you what to look for. I don’t know you, your company, your product, or your team. But I’ll let you in on a few things I wish someone had told me before I started.

I see two frequent mistakes from hiring managers when defining their needs. Either they get too skills-centric (“I need an iOS engineer and a junior python guy”) or too superlative-centric (“We only hire ninja rockstar 10X badasses!”)

The first one is (usually) just wrong, and has been debunked by many others before me. The basic point is this: technology changes fast. Your product and technology choices are guaranteed to change in response to user needs and the moving target of the technology ecosystem. You’d much rather have a competent full-stack engineer who can pick up python than someone whose skill at python defines their resume.

The other end of the spectrum tosses the baby with the bathwater: “Forget python, just hire rockstars!” runs the battlecry.

I want to challenge you to do better than that. Yes, you should hire for overall quality, not technology buzzwords. But what does “best” mean in the first place? The implication is that “great engineer-ness” is a single quality that can be measured, and we can make hires when the value crosses a magical threshold…. the hiring bar!

That’s a dangerous fallacy, because “being a great engineer” comes from a multitude of traits that can’t be collapsed.

Here are just a few of the qualities I’ve seen in extraordinarily successful engineers:

• coding speed and fluency
• ability to solve difficult problems
• motivation and passion
• work ethic
• teamwork and communication skills
• creativity and skepticism
• breadth of knowledge
• depth of knowledge in a valuable discipline
• ability to “finish”
• quick to learn new skills or absorb new information
• introspective, self-motivated to constantly improve
• perseverance, scrappy in the face of setbacks, doesn’t “get blocked”
• systems design ability
• API design ability
• product and UI design ability
• empathy for users
• experience shipping a 1.0
• religious about testing
• takes pains to write readable and maintainable code
• passionate about tooling & work environment
• methodical and analytical: can diagnose the most mysterious bugs or find the source of performance bottlenecks
• ego-less, will work on whatever needs doing
• leadership, can articulate a vision and bring other engineers along with it

The problem with collapsing them all into one rubric of “being a great engineer” is that they aren’t particularly correlated with one another. Great engineers frequently possess more than their fair share of these traits, but that’s not correlation, that’s survivorship bias. Finding one or two of these qualities is not going to predict the rest.

For that matter, no two great engineers have the exact same mix of traits. Some are bold and some are careful. Some “clutch” engineers produce huge volumes of code in a hurry to make your deadline, others work at their own pace but what they produce is bullet-proof, or solves a problem few other engineers could tackle. These engineers are all great and they are not the same as one another.

If you say you want to hire “the best” without specifying what that means to you, then you are leaving it up to the imaginations of every recruiter and interviewer, at which point you’re exercising no quality control at all. In fact, most actually great engineers will know that you don’t know what “best” means, and avoid you like the plague.

One of my guilty secrets is that I love complexity, even though I know it’s wrong. In my ideal (but complicated) world, “best” would be defined by hiring managers thinking through that laundry list of traits, deciding how much they value strength in each area (must have, valuable but optional, don’t care), designing a sequence of interviews to assess each quality, and then defining “best” as the maximum total area under the curve with no showstoppers.

Depending on my values system, someone who just meets my minimum standards for coding speed but with brilliant problem solving skills and testing religion might be a better hire than a faster coder with zero empathy for users, even if generally I consider coding speed a rather important signifier of a strong engineer.

See what I mean about complexity? If you can make this work for yourself and your interview team, you have my blessings (and I’d love to hear the implementation details.)

However, for normal human beings, too many instructions are just as useless as too few, so most good hiring managers end up picking 2–3 traits that really matter, and perhaps a showstopper to avoid. Joel Spolsky famously chose “smart and gets things done.” At Facebook, it was roughly: coding fluency + systems design, don’t hire jerks.

There are real shortcomings to simplification: if you focus on the same few things with every hire, your team will become more and more alike. Overlapping strengths is fine (who wouldn’t want every engineer to be a highly fluent coder? Maybe scrappiness is a core company value that every hire must share!) but you’ll quickly develop shortages of other traits that matter.

For example, at Facebook, we started noticing that engineers with great product instincts were in constant demand. Just one of these engineers was a massive accelerant to a new effort, and product teams were constantly tussling over the few we had. We wondered, why so few? The answer was sort of obvious in hindsight: we were not recruiting or hiring for this trait — so we added it to the set of interview questions and started hiring more engineers whose excellence in this area outweighed a more average performance on systems design.

A second and more subtle shortcoming of simplifying your hiring criteria is that if you don’t assess all of a candidate’s relevant strengths, even if you offer her a job, she may feel under-appreciated and you may fail to make a great hire.

Perhaps the most contrarian thing I have to say about your hiring criteria is this: don’t get wedded to it. Focusing on a few traits is a helpful shortcut in hiring, but in the real world of making software, you don’t get to simplify. You actually do need many or most of the traits from that big laundry list in order to build great software and a great company.

Maybe your founding team includes a great product visionary, so coding productivity or work ethic are the most important traits for your first few hires. Once you’ve assembled several engineers like that, you’ll want to complement them with one or more engineers who are strong systems thinkers and scrupulous testers… or perhaps a great partner for your brilliant but difficult designer.

You won’t want that next hire to be unproductive. But maybe you’re OK hiring someone who takes five days instead of four to complete a project, if he brings something else to the table that unlocks the potential of your team and increases the collective output.

If you elevate your “hiring bar” to religious status, and represent, say, coding speed, not as a means to the end of shipping great software, but instead as the gold standard of What It Means To Be A Rockstar, you’re going to have a lot of trouble hiring for anything else. Your existing team (who have all been selected for coding speed) will view this as “lowering the bar” and the consequences could be severe — anything from griping and loss of morale, to blocking or undercutting new hires, to quitting.

In fact, even if you never needed to hire another engineer, getting religious about your hiring criteria is a mistake, because it implies that the traits you select for at hiring time are the only contributions that define success as a software engineer at your company. If your team only values speed and not good design or careful testing, watch out, because you’re going to pile up technical debt and bugs. Of course, your team needs to value speed too, otherwise you’ll have a hard time punching above your fighting weight.

Narrowing your hiring criteria to a handful of traits is a reasonable shortcut at hiring time, but never lose sight of the fact that a great team is composed of engineers who complement one another. Don’t be afraid of breaking the mold in between each hire. In the end, great managers value, develop, and employ different strengths according to the potential of each member of your team.

Your job is to know what your team needs — and make sure the whole recruiting and interviewing team is on the same page about finding it.

So… what do you look for?