editione1.0.8
Updated August 24, 2022You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.
Joining a company full time is a big decision. Even in an age when engineers switch jobs frequently, a successful hire will be spending years of their life, at 40 or perhaps 60 hours a week, working and thinking about their work. It usually takes months or even years to ramp up and learn the context and technical details to be successful.
Technical software hires can also be in high demand, especially for the most talented engineers. The best candidates may have many options. They are not just deciding what company to work for; they are deciding what other opportunities they are giving up. If it’s not a good fit in terms of the work, the manager, the role, the mission, or values of the team, people are likely to move on quickly.
These considerations show how important it can be to focus on finding a strong fit for both sides.
A strong fit in hiring occurs where the candidate feels fulfilled with the job and role, and the company is deriving significant value from the candidate’s performance.
On the other hand, there is rarely anything like a “perfect” match. With enough shared purpose, the best candidates grow into roles and become a better fit over time. The real goal is to find a match good enough for the company and the candidate, and to subsequently invest in strengthening that relationship. From a company’s perspective, how strong a fit to seek when hiring is dependent on two key concerns:
Demand and scarcity for this role. Are engineers for this role hard to hire? This could be because the demand is high (think of fullstack engineers, who are in high demand at numerous companies), or because the skill set is scarce. Scarce skills usually mean highly specialized experience and could be anything highly specific—like genomic data, high-frequency trading, geospatial systems, specific hardware, or PhD-level academic training in specific machine learning problems. What are the opportunity costs for these candidates in joining your company—that is, what are they giving up by joining? In a lot of geographies and for certain kinds of engineers (such as Stanford-educated machine learning and fullstack engineers in San Francisco or New York), demand and opportunity costs are extremely high. In a tight market, without strong candidate-company fit, this hire may move on soon.
How mission-critical the role is. Will the performance of the person filling this role make or break the team or the company? If a role is going to be part of your company’s critical path or key competency, you might need a candidate who is “best in industry.” The importance of software engineering as a function can vary from company to company. And the importance of roles within engineering teams may also vary. For example, in “deep tech” industries, a company’s success may hinge on its ability to deliver the most superior technology. An autonomous vehicles startup may need “best in industry” computer vision engineers, but be more comfortable taking a risk on the software engineers building its website.
Of course, how strong a fit needs to be is also related to stage and depth of skills needed for the role. In early-stage startups, or for highly specialized positions that require exceptional talent, the fit is all the more important. For larger companies, or any company that can invest more time and capital in training, finding a fit that’s “good enough” may be easier.
Almost every leader in a company will say they care about hiring the right people. A poor fit can be very costly to your company and team. For instance, an employee who lacks the technical skills needed to meet expected outcomes for the role could slow down and frustrate your team, or introduce bad code into your codebase. A “toxic” employee could damage your team’s culture in ways that are really hard to reverse. You can work to minimize the cost of a poor fit by ensuring that you detect and rectify those situations quickly, but if you find that you are hiring poor fits repeatedly, it may be a sign that you need to slow down and iterate on your process.
No hiring process is perfect, and the costs of making the wrong hire do vary. In an early-stage company, a hire that doesn’t work out can be much more costly than at a later-stage company that has a bigger team and processes to deal with inadequate performance. Similarly, for key or senior hires, the cost of poor hiring decisions can be very large, with impact on an entire team.
Almost every company thinks of their hiring needs as urgent, but how quickly does the company need to move to meet those needs? While the repercussions of a poor fit can be very painful, it’s important to think about the opportunity cost of not hiring quickly enough. Part of this cost might be visible in the form of work that isn’t getting done due to lack of resources. But part of that opportunity cost might be less detectable. While it’s usually pretty obvious when you’ve made a bad hire, it’s not always clear when you’ve missed out on a candidate that could have fundamentally altered the trajectory of your company. In a hyper-growth startup, not hiring quickly could mean failure of the whole company, so riskier hires or more aggressive processes may make sense. In an earlier-stage startup, where exceptional hires are critical, or at an established company where people can transition roles internally, it is often wise to prioritize care and a high bar over speed.
Much conventional wisdom around recruiting centers on only hiring “the best” (or the “rockstars” or “A players” or “10x engineers”—terms many engineers dislike!). Under that model, companies should hold a high bar and reject candidates whenever they are in doubt.
In reality, this advice oversimplifies the complexity of hiring well. “The best” is hardly as precise a concept as we’d like to think it is. Technical software roles can be highly specialized in both hard and soft skills, and teams vary widely in values, expectations, and style of work. In spite of technology stacks and qualifications being listed succinctly as if they are menu items—“3+ years of Python” and “GraphQL and Node experience a plus”—an engineer with those specific skills might excel at a large enterprise company, but struggle to meet expectations at a small startup in a role that has a seemingly similar job description. Or they might excel at the startup but find the lower cash pay or the stress of uncertainty incompatible with their life—someone with “the best” experience may not be the best fit for your company.
There are recruiting advantages to specificity around what makes a great engineer. If you define “the best” the same way many other companies do (by traditional pedigrees like a four-year degree from a top school and time at a FAANG company), you’ll end up competing with a large number of companies for a small pool of mostly homogenous candidates. Will you be able to win those candidates over? Can you pay the top-of-market compensation that those candidates expect? Are they actually the candidates most likely to help your company succeed and to succeed in the role? What qualifications are actually essential for success?