No Country for Young Engineers 4

Hire better

Hello and welcome back to the final piece of our series: No Country for Young Engineers. We used the previous pieces to:

1. Debunk the commonly cited benefits of mixed-seniority engineering teams.

2. Look at the diverging career outcomes and influence of engineers across their careers.

3. Examine the impact of AI on engineering output and outcomes.

To conclude the series, we will discuss some recommendations for hiring and retaining talent. Feel free to enjoy this piece on its own or catch up on the whole series.

No Country for Young Engineers 1

No Country for Young Engineers 2

No Country for Young Engineers 3

How should we hire?

This topic certainly deserves more attention than we can possibly address in a single post but we will set forth some general guidelines.

I will start with what I believe to be a rock-solid heuristic for building projects and hiring.

HIRE A MASTERBUILDER I sometimes say that this is my only heuristic because the masterbuilder—named after the skilled masons who built Europe’s medieval cathedrals—possesses all the phronesis needed to make your project happen. You want someone with deep domain experience and a proven track record of success in whatever you’re doing, whether it’s a home renovation, a wedding, an IT system, or a skyscraper. But masterbuilders aren’t always available or affordable…

Flyvbjerg, Bent; Gardner, Dan. How Big Things Get Done (p. 186). Crown. Kindle Edition.

I will echo the sentiments of the author. When you have an opportunity to hire a master builder do this first. The author’s caveats are appropriate, a master builder may not be available or affordable. To this, I will also add some additional difficulties:

You may not have enough expertise or domain knowledge in the role you are hiring for to identify and assess a master builder. This happens a lot when non-technical leaders are trying to establish, expand, or pivot an existing engineering team. On the one hand, this is the right instinct. On the other hand, this is dangerous territory. Without the ability to validate a master builder, you are forced to fall back on more questionable heuristics that are often poor substitutes for determining competency: Is this candidate likable? Do they present well? Do they project confidence? Is their CV impressive?

A corollary to not having enough expertise in identifying a master builder, or any role, is that you may be looking for mastery in the wrong thing. This happens a lot in software engineering when a laundry list of technologies or languages is the primary job description: “We are looking for 8 years of React, Lodash, Tanstack router, Express, Electron, and Node”, while there are sometimes exceptions where one key technology is necessary for the job e.g. “We need an expert on Microsoft SQL Server 2005 to optimize query plans for a database receiving 100k simultaneous read and write requests per second” a list like the first example, generally reflects a lack of expertise of the hirer otherwise they would say something like “We are looking for an experienced fullstack developer with a frontend focus who can build scaleable B2C web applications and APIs that serve millions of customers with an emphasis on scaleable solutions that are optimized for time to load.”

Yet another potential problem is that you have a master builder but they are focused on “building” and you need to fill other roles. This is a tricky problem as well but one we can mitigate with the heuristics below.

Hiring Heuristics

You should have three goals when hiring, everything else is extraneous:

1. Can this candidate provide positive value? Can they do the job? Are they a good investment? Are they a good risk?

2. Can we work with this person? Do we want to work with this person? Are there any negative externalities we need to avoid?

3. Can we give a good candidate experience?

Give a Good Candidate Experience

We’ll dive into heuristics to assess the first two items but I want to stress the importance of the third.

Your interview is your calling card, it’s a public facing engagement for your company and while you may feel you’re talking to one engineer— you’re actually talking to that one engineer at one point in time, a potential customer, and everyone they may talk to in the future.

Interviewing as a technical candidate is brutal. If there is a good interview process and your interviewers are genuine, engaged, and supportive that is something that gets talked about. And everyone has bad days and has the potential for more career growth and knows other people.

Even if it’s not a fit with the candidate you are acting as a representative of your company and acting as it’s public face. You never know under what circumstances you will encounter this candidate in the future so it makes sense to interview with empathy.

The one caveat here is don’t waste time. Find the balance between not dismissing a candidate before getting a chance to get a clear signal and not wasting everyone’s time once you have that clear signal. If you can tell a candidate has no chance, find a graceful way to reach a natural break point and move on, suffering through an interview going nowhere helps no one.

Hire Known Quantities

Direct referrals from your existing engineers, particularly your master builders are invaluable. Whenever possible this is your most consistent, lowest risk hiring strategy. Someone on your team has direct experience working with this person and found them both competent enough and pleasant enough to work with that they want to do it again.

This is a tremendous strategy for building strong, close-knit engineering teams and provides an organic path to growth. As each new hire can carry tales of their own positive experience joining your team to their network leading to yet more direct referrals creating a virtuous flywheel.

That said, there are still pitfalls to this approach. Humans are complicated and can definitely be swayed by perverse incentives. Juicy referral bonuses can lead to contact trawling and create an incentive to just throw any known warm body in the mix. Monoculture and a cliquishness can be a problem. As can nostalgia-tinged memories of time in other trenches.

It’s always important to establish the difference between a fellow senior engineer with deep work experience and some other connection e.g. a friend, relative, arms-length work colleague, school chum, tennis partner, etc.

Significant credence should be given to first-hand experience working with a candidate as it’s the single best form of signal you can get on a candidate. That said, it’s still preferable to get a culture, role, and technical fit even if it’s relatively light, simply because it does represent a good check on the single, strong data point and is an opportunity to get buy-in from other team members.

Hire Veterans

If you cannot hire entirely known quantities, hiring veterans is your next best option.

As the previous posts in our series laid out in great detail, juniors are an unknown quantity and make for a poor investment due to high variance in outcomes and a long period of unprofitable return on investment before they reach a point where they can have a positive impact.

Seniors, on the other hand have a track record, they are to some extent a known quantity. Somebody, usually multiple somebodies, somewhere saw value in having them around and keeping them. You should have some sense of the things they can build even if attribution can be a slippery thing in software. This is not the candidate’s first rodeo either so you can expect them to ramp up in a much shorter timeframe than a junior even if their prior experience is not a cookie-cutter fit for their new role.

You won’t know exactly what you’re getting but you’re not buying a bunch of lottery tickets and hoping for the best either. Your range of outcomes should be narrower and your upside more asymmetric especially if you have resources available to assess the candidate pool. Sometimes you will miss completely and there will be a total whiff on the hiring and you get someone who isn’t worth what you paid, but you’re probably looking at 80 cents on the dollar rather than a wash and while you’re probably not getting a rocket ship if you can offer this candidate a positive work environment they may well exceed their previous limit.

Trial > Interview

No matter how experienced a candidate is, how much first-hand experience your team has with this candidate, how well they did in your interview— you will always be taking a large risk when hiring a candidate into a specific organization, team, and role. There are very few sure things in hiring.

The best way to mitigate this risk is to make hiring a reversible decision. A “try it before you buy it” mentality is ideal whenever you can hire software engineers. This reduces your risk asymmetrically, eliminating an employee is expensive, time-consuming, and can have negative externalities on your team.

This trial can take many forms. If you are working with contractors and find one you like you can sometimes hire, for a fee, the engineer away the contracting company. This is great because the resource is already ramped up and doing the job and you have been able to thoroughly evaluate their output and ability. The downside is finding that diamond in the rough contractor can be an epic quest, you are limited to the contractor’s engineering pool, and it may be expensive and difficult to pry them away from their current employer, especially if that employer realizes their value.

If the candidate is currently between jobs and there is minimal friction to onboarding— one of the reasons remote is great— you can simply hire the candidate on a succession of progressively longer increments: one week, one-month, three-month, six-month basis while you spend some time onboarding each candidate the ability to see the individual doing the job is the best possible signal you can get.

While this approach does incur some cost so you must still train and integrate a succession of engineers which can create a some churn in your environment it does free your engineers from a lot of low risk, low urgency tasks and encourages building onboarding documentation, automation, and processes to minimize the time spent onboarding new hires. It also arguably is a similar to cost to the additional candidate search and interviewing costs you would otherwise incur, with the concomitant benefit of getting some tangible output at the end of the trial however it goes.

It can even be worth it to structure your incentives to support trial hires. Offering the trial employee some sort of bonus on top of the pay for the position to compensate them for their risk is reasonable with that bonus transforming into equity or options if you choose to bring them on full-time so there is no perceived loss.

While less ideal, having a six-month or one year cliff for a candidate to bring them onboard or let them go can work similarly and the ability to just let a candidate go in a low-risk, no-fault, low-cost manner is a real advantage as firing full-time employees can be involved, risky, and difficult. Of course, if you know after a month the candidate won’t work out, you have a lot of time to run out the clock.

If possible, even bringing the candidate in for a week, a few days, or even a day to work with the team is often preferable to a traditional interview. Just remember, if they do real work, pay them. You’ll learn more about a candidate having them pair program and work with you than you will from asking them how to invert a binary tree and do a bubble sort.

Interview for the Real World

A trial is not always an option, you may not be able to do a flexible, long-term trial for a variety of reasons. If you can’t trial the candidate the best advice is to make the interview as much like a trial as possible. The closer the interview can resemble the work the better. Focus on directly applicable skills for the role, job-function related thinking, and team fit.

Don’t

• Don’t ask engineers to invert a binary tree or tell you the Big(O) complexity of a double linked list traversal.

• Don’t give working professionals take home projects or homework.

• Don’t ask gotchas or factoids.

• Don’t waste people’s time.

Do

• Screen effectively: While this may seem somewhat counter to advice previously given you don’t want to have an inefficient process where the key decision makers or experts interview last. Some companies have junior engineers screen before inviting the candidate into a more thorough set of interviews. Something like a one hour phone screen before a six hour onsite for instance. This is a terrible formula since juniors are going to be prone to both Type I and Type II errors. They are going to miss talented candidates (Type II) and they are going to let through a lot of false positive candidates (Type I). This is a formula for losing more valuable time from your seniors and key stakeholders since every false positive means four hours of expensive resource time wasted rather than the one hour it would just take your senior resource to screen.

• Make the interviewing environment as realistic as possible

  • Realistic coding environment: My preference is to ask candidates to have their own coding environment prepared and share their screen. This way you get to see how they naturally work, what editors, plugins, and tools they use, and likely how they would be coding if they came to work for you. You also get important signal from these things. If they don’t have a project setup for your coding exercise, don’t use their chosen coding environment well, etc. those are important signals. Also, this takes pressure off the candidate. Why add the stress of building in an unfamiliar environment or fighting against some web sandbox environment? That’s not what you want to measure.

  • Realistic problems: If you can’t give the candidate real work to do, give them work that resembles real work. This may involve solving a real issue, building a feature your team previously built, or putting together an architecture to address a real problem your business had in the past. A great feature of this approach is if you are proud of the work your team does and have interesting problems to solve this can be a great way to advertise your workplace as one that has interesting and unique challenges.

• Establish a reasonable social fit: There are so many ways to get this one wrong.

  • Interviewing is, to some extent, professional dating. It can be quite stressful especially if you don’t do it a lot. If candidates are wooden, monotone, nervous, they may well just not interview well. Don’t disqualify them for that. Also, in many cases, they are leaving their current employer for a reason, if their current position is fulfilling why are they moving?

  • Look for red flags, if they grandstand, blame others, for their problems, or are evasive or difficult to communicate with.

  • Remember, you’re looking for a software engineer who can do the work and work with your team. That’s it— not an evangelist for your mission, a best friend, or golf partner. Once you’ve established that baseline you don’t need more.

Also, don’t waste your team’s time and the candidates. At most, a screen, and a day of interviewing for candidates you are serious about hiring, you shouldn’t be investing in a full day of interviewing in earnest unless you think there is a better than 50% chance you’ll hire the candidate.

Default to Remote-first

At a very basic level, hiring remote workers, massively increases your candidate pool. You are looking at a global pool rather than any single metro area with a concomitant boost to the quality of candidates you can select for in that pool. This is true even if you are in a tech heavy metro area like San Francisco or Seattle.

Remote work is also by far the most valuable perk you can offer to your employees. You are offering your workers essentially between 1-4 hours a day some fraction of which is returned to you as additional work hours and availability. No other perk even comes close.

While some jobs, may have legitimate reasons to be onsite, software engineers work by its nature is heavily focused on interactions mediated by a computer. Even when speaking to individuals literally seated right next to me I’ve often found it preferable to have the conversation over Slack. This allows me to share code, avoid interrupting their flow or my own, add to a searchable record, and easily incorporate additional participants. By virtue of our profession, software engineers are exceptionally comfortable typing, conversing online, and having virtual meetings and screen shares.

You can invest some of the money you save on office space and amenities into focused time for your team to get together face to face at high leverage moments: team bonding, system design, and high-level planning.

The only real reason to not have a remote work environment for a software engineering is if you currently have an onsite or hybrid environment in which case adding remote employees creates a real imbalance and envy. While the correct solution here is to make your team remote, if you don’t want to do that, adding individual employees who are remote can create difficulties.

Pay the Market

This should be obvious but you have a valuable and appreciating asset don’t lose it because you won’t pay a market rate. It’s also important to remember that your current resource is more valuable to you than a new resource. Your current employee has already been trained and they have institutional and tribal knowledge that will inevitably be lost when they leave.

There’s a lot of innovation going on in different compensation models right now for engineers between flat salaries, wide bands, narrow bands, and everything in between. But again, the simple heuristic is to pay people the market. If someone comes to you with another offer, match it, unless that would have strong negative externalities in regards to the rest of the team. Index pay to inflation and avoid complicated payment structures.

Make the Perks the Work

Pizza parties, beer nights, ping pong tables, company outings— don’t waste your time on this bullshit. Your culture is not mandatory happy hours or Myers-Briggs assessments. Your culture is the work environment and the products you build and deliver. If you cannot enhance your core culture via the perk it probably isn’t worth the investment.

Give people perks they actually care about:

• Good equipment

  • Computers: No brainer. Literally you may be saving tens to hundreds of hours a year with beefier machines and better displays. And this is a top item in terms of employee satisfaction for engineers who will spend most of their time using said computer.

  • Peripherals / Office / Home office equipment: Employees who miss significant work due to health problems: carpal tunnel, bad backs, headaches, fatigue, weight gain are all way more expensive than ergonomic keyboards, mice, chairs, and standing desks. Not to mention good audio and video setups improve the quality of zoom meetings significantly.

  • Software Licenses: If it’s not your business’ core competency consider a paid product. This includes things like Slack, Zoom, scheduling tools, project management software, knowledge bases. In some cases licenses for enterprise platforms can be quite expensive but invest heavily in the things you use heavily. If you don’t use it heavily, perhaps a free product is the right way to go but causing your team countless hours of frustration and lost productivity because you won’t spring for Slack is not a savings.

• Valuable Experiences

  • Time off: This is the most valuable perk you can give next to remote work. Follow a generous holiday schedule and give people an expansive list of holidays. If you do “unlimited” PTO and make sure it’s really that.

  • Team face time: Especially with remote teams invest in time for them to enhance their bonds and focus on specific aspects of the work that benefit from being able to colocate such as white-boarding and planning. While this may include things like team lunches and after work drinks, the teamwork should be the focus. Also, note the emphasis on “team”. Larger company or organization shindigs are usually a total waste of time for everyone except the executives’ whose egos are being stoked.

Conclusion: Fail Fast

Life is short,

and craft long,

opportunity fleeting,

experimentations perilous,

and judgment difficult.

Hippocrates (in translation)

There is no science to hiring. The largest, most technically savvy organizations get it wrong all the time despite a weighted talent pool, rigorous processes, analytics, and massive amounts of time and money to invest in the process.

The best you can hope to do is try to identify promising potential hires quickly with a minimum of pain and effort. Let them go as soon as possible if you determine they are not a good investment. Make decisions that maximize retention, employee satisfaction, and personal growth once you identify the employees you want to keep.

I hope you enjoyed, this piece and found some valuable insights into hiring and retaining talent. If you enjoyed this post or others in this series please share.

Have a different take, questions, or want to add your perspective?

Need help hiring or are in need of a master builder?

I enjoyed writing this series. Come back next week when we’ll turn our attention to a new topic. Stay tuned!