When hiring new engineers, treating candidates equally only works if everyone has the same opportunities and experiences.
A few years ago, I was interviewing at a big tech company. I was a self-taught developer who thrived when solving complex problems and learning new technologies. I had five years of experience, from supporting fast-paced movie productions to building new products. I was confident this next job would be a challenge, but I was ready for something new. This is what I wanted the interviewer to know. But instead, she badgered me until I cried.
What went wrong? When she walked into the room, my résumé was waiting on the table. She said, ‘I’m not going to look at that. Let’s do a problem.’ Her outlook was that if I treat everyone equally, I will find the best candidate. But that only works if everyone has the same opportunities and experiences. Even though I had worked on many successful projects, I didn’t share the same formal education as others in my position, and I had to ask clarifying questions about terminology. She was dismayed, even though that would have eliminated anyone with English as a second or third language.
The flaw in her mindset was the disconnect between what she was interviewing for and what was best for the company – a diverse set of backgrounds and experiences. To help managers learn from my experience, I’m sharing techniques for getting the hiring process right, from writing the job description to planning your new engineer’s first six months. This will help you treat everyone with equity, instead of equally.
Writing the job description
When writing the job description, you should think deeply about what skills and experience would help accomplish your company’s goals. Do you have a large backlog of bugs and need someone who can quickly execute? Do you have a large stack of project requests and need someone to take responsibility for the research, design, and build? Or do you need someone with process experience that can help to improve your velocity?
None of those needs relate to experience with specific technologies because those are the most straightforward skills to learn. I would rather someone search, ‘how to add to a list in Java’ than alienate stakeholders because they lack communication skills. By looking for the skills instead of the education, you will be hiring flexible, motivated engineers who can solve today’s and tomorrow’s problems. Industry knowledge is often an underappreciated skill that can make up for missing technical expertise. As an engineer, it’s essential to not only build technically correct software, but build correctly for the users.
Building a pool of applicants
When building your pool of applicants, it can be challenging to reach engineers from underrepresented communities that can’t picture themselves at your company. A great hack is to partner with existing organizations and groups like /dev/color, Techqueria, Tech by Choice, Diversify Tech, and Out in Tech who already have the communities and will help you connect. You can connect with their audiences through sponsoring their events, providing scholarships, creating content, and even setting up 1:1 meetings. Nurturing relationships that do not result in an immediate hire just means you are investing in future employees. If you don’t think you’ll need engineers a year or two from now, you have a different problem.
Testing candidates
Now that you have your pool, how do you narrow it down? A flexible process is key. You want to encourage your applicants to show their best selves in a way that works for them, instead of setting them up for elimination. There are many ways a candidate can demonstrate their technical skills, not just whiteboarding an algorithm question that is irrelevant for their daily workload. This kind of testing excludes people who prefer to work alone to focus, and those with other obligations who don’t have time for a project. Most folks won’t realize they can ask for another option, so why not offer it upfront?
Here are some ideas for more inclusive ways of testing:
- Ask them to walk you through a recent project, including their role and the technical challenges. What would they change if they could rewrite it? How did it solve a business need?
- Provide a simple take-home test that takes only one to two hours to complete. Make sure it’s something that would match an average work task.
- Ask them to review some of their own code that they have publicly available.
- Try debugging some of your code together (don’t pretend you don’t have code with bugs in it).
- Ask them to present a system design for a large-scale problem, either on the whiteboard or through a short presentation.
Onboarding engineers
Hiring is just the beginning. Now, you have to set your engineer up for success. Ideally, you have thorough onboarding documentation, a clear project roadmap, and quarterly goals. Just kidding, almost no one has this. But there are a few practical things that you can do instead.
First, assign them an onboarding buddy. This person needs to be a volunteer with the time to answer any question promptly, from how the code review process works to how they should expense headphones. If the engineer is rebuffed from asking questions early on, it can sour their whole impression of the job and the team.
The second step is setting clear workload expectations. This doesn’t mean you need well-written tickets and architectural design ready to go. Instead, you need to set clear parameters on where and how they can get involved in the most impactful work. Is there a list of high-priority bugs? Is there a client that needs to be interviewed? Is there a project manager for these tasks, or should they be reaching out directly to stakeholders? If they are identifying problems themselves, is there a design review process, either formally or informally? Are there any deadlines or demos they need to be prepared for? Engineers want to solve problems and find answers; you just need to point them in the right direction.
Reflections
It’s easy to say that an engineer didn’t meet expectations and let them go. If they are from an underrepresented group, that can add to your implicit bias that people like them just can’t hack it. As a manager, you need to be actively removing the barriers to entry, sharing the unspoken company and team rules, and setting clear expectations for success. Not everyone has had the same experiences, but with the right support and empathy, they can thrive, and bring invaluable new perspectives and solutions to the team.
