I’ve been fortunate to work with people who know and understand the value of diverse teams. For them, pushing forward diversity & inclusion wasn’t a question. Still, they didn’t always know how they could make a difference. There’s plenty of great resources about the value of diversity, especially in the Agile and DevOps spaces. And there’s a growing number of people talking about how to achieve these goals. As hiring managers, we have the opportunity to make a direct impact. Let’s explore a few ways you can make a big difference quickly and easily.
Diversity
A diverse team unified behind a compelling vision is a powerful force. When we think about diversity, we need to consider all of the ways we can diversify our teams:
- Experience Level
- Kinds of Experience
- Education Background
- Race
- Gender
- Sexuality
- Neurology
- Psychology
- Culture
Any given candidate will overlap a few of these dimensions. Understanding how our hiring processes affect our candidates with varying backgrounds is the first step in making a difference. To do that, you need to talk with people about their experiences in interviews. What activities bring out anxiety or confidence? Which elements of the job description bring out hesitation or excitement? What blind-sided them?
The more we let ourselves feel what they feel, the more effective we become. Don’t just recognize what the candidate might feel. Feel it. Relate it to your own experiences. When we do this, we grow our ability to lead with empathy.
Their Best Self
Our goal is to give as many candidates as possible the chance to show their best selves. We know that making a bad hire is incredibly expensive. That’s why we’ve put up so many roadblocks to landing the job. Screening, minimum experience, homework, behavioral interviews, whiteboard exercises, and all the rest are there to protect us from a bad hire. What’s less understood is that failing to hire a great candidate is also very costly!
For the sake of illustrating the point, let’s assume the position is expected to generate $800k in value each year, costs $200k to employ, and $60k to hire. We’re expecting the first-year gain to be $540k. Every day that role is unfilled is costing us a little under $1.5k. That might not sound like a huge number, but consider if the position went unfilled for a year and what that half-million could’ve done for our employees, investors, and customers. The cost of delay is just the tip of the iceberg.
Missing a great hire adds a multiplier. When we talk about great hires, we are talking about people who will consistently exceed our expectations. They are somewhere within the top 25% on the performance bell curve. In software, Steve Jobs believed the difference between an average developer and the best was between 50:1 and 100:1. But for our illustration, let’s stick to something closer to normal, the 2:1 great hire. Using our same assumptions above, now we are talking about $1.4M per year in gains.
The average cost of a bad hire is between 30% of their first-year earnings and $240k. That’s a massive range! For our thought experiment, let’s go big. Cutting to the chase: We could make four bad hires and still be ahead if we make one great hire! It’s like holding the Ace and King of hearts, and the flop has two of our suit and no pairs. Raise! Re-raise! All-in! Let’s go! It’s even better, however. Assuming a normal distribution, more candidates are in the average and above-average group than in the below-average grouping.
Yes, a bad hire is expensive but not nearly as expensive as missing great employees. If we aren’t giving our candidates the best chance to succeed, we are missing great hires.
Relationship to Diversity and Inclusion
What does this have to do with hiring women, people of color, or other underrepresented people? Why’s it that I’ve met so many peers who want to increase their teams’ diversity but complain of a lack of qualified candidates?
While there are many sources of a lack of diversity and inclusion in tech, one is our hiring rituals. Underrepresented people don’t always come from traditional backgrounds. When I say traditional, I mean things like going to college for a computer science degree at a university known for their technology programs. Then, coming out of school directly into a paid internship at Google. And finally, being hired as a software engineer a year later.
Suppose our minimum requirements are a 4-year C.S. degree and one year of experience. Great candidates without one or both these might not even apply. As hiring managers, we won’t even see their resume even if they do apply!
It gets even worse. Sometimes, the language we use in the job description turns candidates away. Let’s compare two bullet points:
- Confidence in refactoring legacy code to be testable and extendable.
vs.
- Demonstrates the ability to refactor legacy code to be testable and extendable.
Suppose our candidate learned at a young age that being confident is rude, or they didn’t deserve confidence. In that case, that candidate isn’t going to respond to the first bullet. We can even take it a step further by improving the second bullet.
- Ability to change existing code so it is easier to test and change in the future.
Did you see what’s happening here? We removed the insider jargon. A candidate might have the skills to refactor but never heard that word before. They see that and might say, “I’m not in the club. I’m not qualified. I don’t even know what refactoring is!”
So far, the good news is these are simple changes that don’t alter what we are looking for but do broaden our audience. But we have to get back to the bad news.
Often, our interviewing techniques reinforce our apparent desire for the traditional background. Schooling isn’t a bad thing, but it isn’t the only way. Formal education focuses on skill development and traits in particular areas. In school, you are rewarded disproportionately for completing assignments regardless of the quality and for the ability to memorize and recall specific and sometimes arbitrary information. If our interviewing activities are heavily biased toward recall, then we are biased toward a traditional background. And any activity that resembles a test is in the same boat.
I’m only skimming the surface here, everyone. This goes deep. It even gets cultural. While I’m passionate about this topic, I don’t want to lose you before we can get back to the good news. We can make simple but significant changes to increase our exposure to great candidates from any background.
Practical Easy Solutions
Nothing here will change the world, but it will open up more opportunities to more people. If more of us do this, then it will make a difference to someone.
Job Descriptions
Think of this document as a one-page marketing sheet. The purpose is to attract great candidates, whoever they are, and from whatever background. This isn’t our shield or mote. It’s a flashing neon sign on a dark empty horizon.
Here are the easy gains:
- Write to a more general audience unless you require a specialist.
- Minimize the use of language that reinforces a traditional background.
- Remove language that requires the candidate to feel a particular way about themselves.
- Read the HBR Guide to Better Business Writing.
- Have someone review it who works in communications or marketing.
- Review it with your recruiter and let them know your goals.
- Don’t water down the skills needed!
Technical Screening
This screening is our best chance of avoiding the costs of someone who simply misrepresented their skills. But the means we use can exclude great candidates.
Here are the easy gains:
- Provide more than one way to do a technical screening. Yes, this requires work on our part. Great candidates are worth it!
- Submit a take-home screening
- Take an online assessment that allows the use of resources.
- In-person tech screening where the candidate receives an outline ahead of time. And they can ask questions and use resources while performing the screening.
- Submit a personal project or open-source commits
- Focus tech screening on the skills that are most used in the role. If the position doesn’t regularly involve Calculus, don’t screen on knowledge of Calculus.
- Don’t screen on the ability to recall. And especially not the ability to remember under stress.
If you’re wondering if an engineer who can recall any given function’s positional arguments is more efficient than one who uses their IDE or references, I would say yes on the surface. What’s more important for efficiency is deploying the correct and legible code once. If efficiency is a high priority, then a slower programmer who is more accurate and produces more maintainable code is a better choice.
The Interview
Let’s start by getting specific about what our engineer needs to be able to do. The skills required should be clear after analyzing the product and the team’s strengths and weaknesses. Suppose we aren’t innovating new search algorithms, or we already have an algo wizard. In that case, we might not need someone who can recall the different pros and cons of various pivot points in a quicksort. I’d argue that we don’t since these are solved problems. You don’t come up with a physics theory that challenges common experience by memorizing the speed of sound.
As a pre-teen and teenager, my life was music. It’s all I cared about. I put countless hours into learning, practicing, and enjoying all things music. One afternoon I was hanging out in the high school symphonic band room waiting for a friend before going to jam. I was at a drum set doing a sticking exercise. The exercise was tricky because it combined flams and paradiddles. My band director came out and said something to this effect, “Aaron, I don’t understand you! There are times you amaze me, but then you struggle with some of the basics in the symphony band.”
My background didn’t prepare me for playing the symphonic snare drum or any melodic percussion instruments. While my director was a percussionist, her experience didn’t prepare her to play drums in an alt-metal band.
What’s happening in many engineering interviews is this: We need to hire a drummer for an indie-pop band. During auditions, we have a section on sight-reading marimba. And on music theory. Then, they have to play an Opeth song. Finally, we test the drummer on public speaking skills. At least three of the four are tangentially related to the role. But what are we going to learn about their ability to play in this band?
What should the audition (interview) look like? The band would send the candidate a setlist of their songs ahead of time and what they will do during the audition. Maybe the band would ask the candidate to learn the songs note for note or add their style. During the audition, they would play through the setlist together—probably a few times for practice and soundcheck, then a rehearsal. Then, there might be time for freeform jamming to see if the band can “click” with the new drummer. Finally, there might be a section of the audition where there is songwriting or learning a new song together. During these activities, the band is observing the skills and working style of the candidate. How do they manage frustration or another member making a mistake? At some point, they would spend time with the candidate to see if they get along outside of the working environment. It would probably take all day. After going through the process with several candidates, the band would deliberate and weigh their options.
Not all bands do this, but it’s a great way to run an audition. An audition is a job interview. What makes this audition so fantastic?
- The candidate has all the information about what they will need to do ahead of time, with plenty of time to prepare.
- There is no pop quiz. The open-ended activities are planned and communicated.
- The content of the activities is directly related to the day-to-day job.
- The candidate is evaluated in the most common setting they would be working in. They aren’t sitting in front of a panel that isn’t participating in the work.
I have come to love the “project-based interview” for evaluating engineers. Here is a summary of one such interview:
- The candidate was screened with a take-home that could be completed within 2 hrs. This was tested beforehand by myself and my team members.
- The candidate was also given a description of the project they would work on during the in-person interview and how the interview would be conducted.
- The candidate sat with the team in our typical pod.
- The candidate was assigned a pair-programming partner every 45 minutes with a 15-minute break in between.
- The candidate could use any available resources.
- After three pairing sessions, there was a group code review. The candidate was asked to start by showing areas they would want to improve in another iteration, how, and why.
- 1-hour lunch break with the choice to have it solo or socially with the team.
- 1-hour behavioral interview with a couple of selected members of the team.
This interview mirrored our working environment. We paired often and did quick group code reviews huddled around a desk or big monitor. The project was a refactoring exercise because we had older software that we needed to be moved to the cloud. The candidate had patents, and OSS commits that I could examine. I didn’t need to waste time quizzing them on data structures.
While this specific interview fit the team, it isn’t the most inclusive. To up the inclusion, we should make pairing and group code review optional. We still want the review, but allow the candidate to decide how it will be formatted. Giving options around group activities can have an impact on people with neurological or psychological diversities. As leaders, we know the value of empowering our employees with ownership. Why not empower our candidates?
Sourcing
Looping back around to the beginning of the process, we have sources of candidates. Recruiters know their craft. Let them know you want to diversify your team. Ask them about organizations like ChickTech! Partner with your recruiter and organizational leadership to diversify the sources for internships.
Quick List:
- Don’t require interns to be recent college graduates.
- Source half of all interns from organizations like ChickTech.
- Ask your recruiter if they can use a solution like Sourceress that allows you to source diverse candidates directly.
Closing Thoughts
When it comes down to it, the conversation about diversity and inclusion is about empowerment. We can empower more candidates from more backgrounds, or we can narrow the door so only those who conform to our biases can pass through. It happens that there are excellent business outcomes associated with team diversity. There are also solid financial reasons to shift our hiring stance from fear to opportunity. While one of us might not change everything that creates a lack of diversity in tech, we can do something about it.
There’s no excuse. I hope you consider broadening the horizons of your hiring processes!
