What I’ve learned through the maelstrom of hiring engineers in today’s world

Throughout my time hiring engineers, I’ve learnt (and relearnt) a thing or two through a blend of mistakes and successes. What I can say with confidence is that it is a much more elegant puzzle than it appears on the surface.

You are not hiring good people to join you. You are hiring great people to change you for the better. The difference between these two things can be minute on the surface but gargantuan in impact.

I wanted to write a few of my thoughts on the matter to help anyone else dip their toes into the art (and science!) of hiring for the first time.

1. Don’t Hire What You Can’t Handle

Perhaps the most significant question to ask oneself before hiring any engineers is, can you handle them joining? Nothing blows up in your face more than an engineer who cannot be onboarded due to a chaotic environment.

How can you assess this? Well, as any good manager, you should always start with a conversation with those most impacted, the team. However, simply asking, “Can you handle another engineer on the team” may not generate the insights you truly need to answer this question.

Instead, you need to be asking more detailed questions, such as:

• “If a new engineer joined next week, what would they work on?”
• “Who would be this engineer’s mentor?”
• “What part of our architecture would they most struggle to understand?”
• “How long do you think it typically takes to onboard to our architecture?”
• “How would we decide if they should pass probation?”

You don’t need perfect answers to these, but if the team cannot answer them at all, then you may need to think twice before making a hire.

Outside of that initial conversation, you should be able to glean your team’s hiring readiness via its engineering health metrics. If you don’t have these explicitly defined, I’d recommend you do so, but regardless, there should be some pretty easy ones to observe. Some important ones are:

• % of toil in work: What percentage of your team’s time was spent performing maintenance instead of delivering value? If it’s above 50%, then hiring won’t impact you until you release pressure on the team to deal with the highest leverage pieces of technical debt.
• Cycle times: You can measure this several ways but the flow of your work says a lot about a team’s readiness to onboard a fresh mind. Large cycle times often mean huge merges and huge merges indicate a team that struggles to break down work. If you can’t break down big problems, how will you give new joiners a safe yet achievable arena for practice? Large cycle times can also mean systemic bottlenecks, which means longer feedback loops for new joiners to learn from.
• eNPS: You don’t necessarily have to perform an employee Net Promoter Score, but you do need to understand the sentiment of your engineers in working at your company. If it’s low, then you need to investigate whether new employees would actually fix this (a lack of trust between departments would typically only be worsened with more employees).

These are just a few but don’t start hiring until you have the data to prove you are ready. There are some other points to cover around having the right people operations (contracts, gear, etc.) in place to onboard, but they escape the scope of what I want to cover in this article.

2. Know What You’re Looking For

My goodness! The way people default to the word “Senior” when they don’t know what they are looking for can be very frustrating! When deciding to hire more engineers, you need to define a few things:

• What scope are you expecting them to operate at?: Should they be thinking about days, weeks, months, or years with their decisions and actions?
• What is your engineering department missing that they will add?: Sometimes you need an architect, sometimes you need a facilitator, and others you need an executor. These are different, but all could have “senior software engineer” written on their CVs. Make sure you’re clear about what they are adding to your company.
• How will they grow? Is this person looking to become a manager or principal engineer in a few years? Whilst this may be similar to the above, what someone is now and what they will be are not the same thing.
• What are the explicits?: Learning the balance between what can be learned and what is vital to have an understanding of from the get-go is critical to identifying engineer profiles. Perhaps it’s OK if they don’t know React Native if they’ve worked with React before. Perhaps you’re confident you can educate them about event-driven architectures on the job. You must be clear about what you want to trade off to widen your hiring funnel.

There are more than just these, but these are some of the most important for an engineer. However, above all, make sure you are aligned with the team about what you need.

3. Flow is King

If you’re trying to scale an engineering department, then understanding the way people move through your hiring funnel is imperative to your success. Flow can be summed up as the following:

• Cycle time (yes, I love cycle time!): How long does it take an individual to move from stage to stage once pulled into the funnel?
• Work in progress: The number of people in your hiring funnel (and at each stage) at any point in time.
• Throughput: The number of people exiting your funnel over a certain time range. You can segment that into hires and drop-outs/rejections.

These metrics are by far your best way to identify and action bottlenecks. Engineering candidates require various people to assess them, from internal talent acquisition staff to other engineers (this one requires extra diligence) to even co-founders. Understanding flow will allow you to have the following conversation:

“Hey, this candidate spent seven days waiting for their expertise interview. Why?”

“We had four other candidates doing this interview ahead of them and we’re two engineers down this week.”

Those two insights alone will allow you to decide whether you reduce the arrival rate of candidates to your hiring pipeline or increase engineering resources so you can increase WiP. Most ATSs (Applicant Tracking System) have some form of data visualisation but make sure you shop around to find one that can get you the data you need.

Finally, you should look to tag candidates so you can make deeper insights about the differing flow of different kinds of candidates (remote/hybrid, seniority, employment background). Just make sure you’re adhering to good data privacy standards when analysing candidate data.

4. Understand the Levers

Flow is great, but if you don’t know which levers you can pull to action insights, then you only have part of the picture. Different parts of your funnel have different levers:

If the arrival rate isn’t great, your outreach needs to improve. That can be as on the nose as messaging more people on LinkedIn, but it can also be getting your department’s renown out in the open.

Blogs, podcasts, and conferences are all parts of the puzzle here. Engineers want to work on interesting challenges, and if you have them, then you should be shouting about them!

If you need to improve flow in the middle, then you should look at your interview formats. Is a take-home dev test really needed? Not only does it often breed bad sentiment in candidates, but there are other ways you can validate the same things in a timeboxed session. Maybe it’s pair programming, or maybe you ask them to review a broken codebase, but you should feel comfortable playing around with this.

The point is you need to experiment, and you need to measure the outcomes of what you’re experimenting with!

5. Align on Excellence

Asymmetry of evaluation is one of the most dangerous things for hiring new engineers into a department. Few things will disenfranchise a new engineer more than seeing another new joiner of the same seniority performing at a much lower level.

Anyone interviewing should be aligned on what excellence looks like for that interview. Now that can be a scorecard, or it can be a simple statement such as “Can you see them working autonomously on this team within X months,” but you must have a clear litmus test that interviewers will be accountable to before passing candidates.

What’s more, as a hiring manager, you need to own the process. That means effective quality control of who is moving through. At first, this is arduous, but it will get easier with time. Take a sample of three candidates who have moved through to the same round in a certain time range. Assess the delta of their evaluation by each interviewer. If it is too large, speak to the interviewers to understand their perception of excellence. This isn’t about blame; it’s about learning.

6. You Are Being Interviewed Too

Do not think for one second that because you get to be the person with the scorecard that this isn’t a two-way street. Great engineers are a hot commodity, and you won’t be the only one they are talking to. As much as they are selling themselves, you are selling a culture/mission/vision right back at them.

This all starts with your mood. In all honesty, if you are not in a good headspace to interview for the love of all that is holy, DO NOT attend the interview. Find someone else to do it. A poor mood stinks like a medieval latrine, and candidates will pick up on it instantly. From the very moment, you start talking to candidates, you must actively listen to them as humans.

Who are they, where do they want to go, and what do they need to get there? Be confident about your work and the challenges you’ve taken on as an engineering department. What is your architecture, and why is it thrilling to work on? How do you innovate, collaborate and succeed as a department? You should be able to answer any of these in an interview at the drop of a hat.

But it’s not just good enough that you can do this. The engineers you work with have to do it too. Interviewing needs to be opt-in, incentivised, and celebrated. Not being able to do enough interviews isn’t a good enough excuse for shoe-horning in people who cannot sell the role to some extent.

Make sure you are aligned with anyone interviewing about what is needed to be able to interview well.

7. Transparency, Transparency, Transparency!

As mentioned, hiring is a two-way street. My mentioning “selling” above may lead you to question the title of this section. However, as any good salesman knows, the best sales are the ones where you tell the truth.

Pretty much everything I’ve said above is useless if the candidate engineer and the interviewer aren’t aligned on what this role is all about. Be aware of when you’re hiding things until later in the process as a surprise. You’d be amazed how often this implicitly happens.

Does your role really provide opportunities to management? Do you actually have the investment for them to be a tech lead in a year? Is this really a full-stack role?

Lacking transparency will only lead you to a mismatched hire, and there are few greater wastes of resources than that.

To Conclude…

These principles have been invaluable to my decision making and learnings about hiring. There will be others, and some may even change, but simply being clear about what is and isn’t working when hiring engineers is the first step to scaling an engineering department of people who will change the world!

Reflections on Hiring as an Engineering Manager was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.