U
D

Conversation

the

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

This is the firstĀ in a series of articles on Hiring Engineers by Jocelyn Goldfein, Angel, Advisor. Formerly: Engineer @ Facebook, VMware, Startups, Trilogy.
ByĀ Jocelyn Goldfein, Angel and Advisor

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:

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?



About the guest blogger Jocelyn Goldfein: Jocelyn invests money and time in making high tech startups successful. She gets to work with teams and products she believes in, every day. She’s spent her career building software during high-growth years at VMware and Facebook (and a couple startups). Her and her teams have built middleware, distributed systems, big data powered ranking systems, operating systems, web and mobile apps and developer tools. Learn more about her investing activities on AngelList.

Editor

Editor

The Switch Editorial Team.

Straight to your inbox.

The best content on the future faces of tech and startups.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

SHARE THIS STORY

NEW COHORT STARTS JANUARY 2024

Join the Angel Sessions

Develop strategic relationships, build skills, and increase your deal flow through our global angel group and investing course.

RELATED ARTICLES
[yarpp]