Hiring Software Engineers
Building an engineering hiring process from role definition to debrief, and calibrating it.
Q: We’re a company growing rapidly. Our hiring process has been based on intuition so far. What do good hiring processes look like and how do we build them?
Hiring is the biggest pain point I hear most engineering managers, VP Engineerings and CTOs talk about. This is especially the case while we are still in one of the most heated tech hiring markets ever seen, and hiring managers expect this market to continue this year.
In this issue we cover:
The role definition. Why you should start with this, and why write it down.
The job description (JD). What goes into a good JD?
The interview process. Defining it, and why you should start with signals gathered.
Debriefs. How are hiring decisions made? What are common debrief approaches?
Calibration. How can you increase consistency and reduce bias in interviews?
Feedback loops. What to measure so you can improve the hiring process.
Resources to define a hiring process. An example interview process definition, scorecard template and a debrief summary.
Related newsletter issues:
Note: This article mentions tools relevant for interview processes. I have not been paid to mention the companies behind these tools. My newsletter is fully independent, does not accept sponsorships and I have no commercial affiliation with the vendors mentioned.
1. Defining the role
One of the biggest reasons why many companies struggle to hire is they miss the first step: accurately defining what role they want to hire for. If you’re a hiring manager, you might read this surprised, thinking: “What needs to be defined for a software engineering role? We just want to hire someone who can code and get the job done!” But you should explicitly define both “coding” and “getting the job done.”.
Start with the “what”. What will this person do? How do you describe their day-to-day work? Is it 100% coding? Surely it’s not. They’ll be deploying to production, monitoring the health of their systems and talking with others to make sure they build the right thing.
Will they drive the building of new features? Be responsible for uptime targets being met? Will they talk with customers and are they encouraged or expected to bring new ideas to the table? Will they be expected to take ownership of entire projects as autonomous engineers, or will they be handed well-defined JIRA tickets and their scope be limited to a low-autonomy “worker following instructions”?
Define the scope of the role. This is especially important for more senior roles. Outside of writing quality code, what else is this person expected to own? For example:
Will they work only within their team, or collaborate across several teams?
Will they only follow current engineering practices, or be expected to improve how the team works, bringing in new practices?
Will they plan, build, ship and maintain projects? Will they also own the product planning, or only the engineering? Will they be oncall for code which they ship? Will they follow up with customers to ensure things work as expected?
Are they expected to tackle more open-ended problems or well-defined ones?
Will they contribute to or own the technical roadmap for a project? For their team? For several teams?
Are they expected to mentor other engineers? Will they be getting mentorship themselves?
1, 3, and 6-month plan. What does success look like in the first, third and sixth month for a great hire? This is an area few hiring managers verbalize, even though it’s an approach that helps both the new hire and their manager, the most.
Take a senior engineer as an example; what would a great hire be doing in month six, after they have onboarded and know the organization well? Will they be owning a complex and impactful project, end-to-end? Will they have improved how the team iterates and ships to production with confidence? Will a great hire have onboarded and mentored several new joiners?
If you cannot answer the question of what success after six months looks like, dig deeper. When you can answer this, write it down.
Must-have vs nice-to-have expectations. What are skills and expertise that are non-negotiable to have on the job? These should be things for which there is no time or opportunity to learn, and skills which you’d reject anyone who does not have them.
For software engineers, the biggest non-negotiable skill is their ability to write code that works. For more senior engineers, it’s the know-how to write production-ready code. On top of this, for senior hires you might look for expertise in working at the scale of those problems which your organisation is currently tackling.
However, should having a degree be a must-have, above the ability to get things done? Should knowing a specific framework be a filter, when most engineers can pick up a framework within a matter of days? Would your codebase being written in Java disqualify candidates who aren’t so proficient with this language, but could pick it up quickly because they already work with similar languages?
The more must-have requirements your job advert has, the fewer people will apply. If you add expectations to must-have which can quickly be learned on the job, you risk doing the recruitment process a disservice.
Challenge yourself to turn must-haves into nice-to-haves. For example, instead of stating, “Must have 3 years of experience working with Java”, consider making it “Must have worked on production codebases before” with a “Nice to have experience with Java, Go or other OO programming languages on the backend.”
Learning on the job. Which skills will people learn in this role? Learning includes skills they’ll have to pick up to be successful, but ones you’ll help them acquire. Be clear about these areas; they’re ones you need to invest in and they can also be a selling point for candidates.
Budget. What is the salary range for this position, the bonus budget and the equity - assuming it’s included? What is the very top of your budget, and what is your “default” offer? What is the process for going above budget for candidates with competing, higher offers?
The market is very hot, and you’re doing yourself a favor by making it clear what your actual ranges are, instead of making up the budget as you go. If in doubt, leave more space to increase offers. If you frequently have to extend offers above budget, this might indicate you need to move your compensation bands upwards.
Career levels. What do the levels “above” and “below” this role look like? For example, when you are hiring for a senior engineer. If you have a career framework, this is an easy question to answer, and it will also help in making offers for people who should be leveled below or above this role. If you don’t yet have a career framework, now might be the time to start putting one together!
Write all of the above down. Until the role description is in your head, everyone in the interview loop will interpet expectations differently. Put it in writing and circulate it among the relevant people. Gather feedback and iterate on it until you’re happy with this writeup.
2. The job description
With the role defined in writing, putting together a job description (JD) which represents the actual role is so much easier. I’ve found many job descriptions that include far too many requirements, or ones that mislead as to the nature of the job, were written before the role itself is clear to the author of the JD.
Should you copy other job descriptions, even within the company? Copying past job descriptions is something many hiring managers do, especially at larger companies. There’s an assumption that if it worked for one team, it should work for another.
I’m strongly against copying the contents of any job description, although using its structure can be a good idea. The contents of the JD should come with your role definition; if they are different from all the other JDs at your company, so be it!
Here are sections I suggest to include in job descriptions:
The opportunity. Why should anyone reading this job advert care? What problem are you solving? What is the mission for your team and company?
The work. What will the successful candidate do, day to day? For this, you can use the “what” and the “scope” parts of the role definition.
The roadmap. List what this person will do in their first, third and sixth month. If you have this as part of the role definition, you can use this information directly.
Experience you’re looking for. List the “must-have” and “nice to have” skills and experiences.
The tech stack. It’s always nice to summarize what technology you’re currently using.
The team. Who will this new hire work with? Especially for more senior hires, consider listing the key people like the product manager, their report, team members and other relevant people.
The interview process. Consider summarizing the interview process, so people know what to expect.
The compensation range. If you can, share this. Especially for smaller companies, people will assume the compensation range is well below that of well-known firms. Listing the range will result in more people applying, as they know what to expect. And if you still don’t get many applications, then you know your range is too low to be attractive!
Benefits. List these, ideally at the end of the listing. No one will apply purely for benefits, but a healthy benefits package is a good sign for many candidates.
Find job descriptions that resonate with you, and don’t be shy to copy their structure. For inspiration, here are a few job descriptions, and their structure:
A short, sweet, and to-the-point JD from Wave Money.
Our mission
How you’ll help us achieve it
Requirements (these are very short!)
About engineering at Wave
Key details (including salary range)
Our team
How to apply
A JD with lots of details about the team at Waybridge.
The problem we’re solving
Experience we’re looking for
Technology stack
The day to day
The team
Fitting in
The interview process
A JD with lots of details shared from Fonoa (I’m an investor)
Engineering at Fonoa
Our products
Our API docs
Our tech stack
What you will be doing
You would be a great fit if…
Why Fonoa?
Compensation (including a salary range)
Our culture
Our perks
Our ways of working
Other reasons
Our take on equal opportunities
Our hiring process
Use inclusive language in the job description. Even small things like referring to groups of people as “guys” can rub people the wrong way. I cover more on this in the issue Hiring a diverse engineering team.