Blog: Draw in diversity by changing the interview
Draw in diversity by changing the interview process and coding test – here’s how
The biggest impediment to attracting and hiring female software engineers (and other diverse candidates) is the interview process and coding test. Change this process, and you’ll start to change the industry.
The traditional engineering code test and interview process is extremely stressful, unnecessarily complex, fraught with implicit bias, and favors people who are good at testing and talking. We offer ways to make the process better based on women’s experiences inside the industry.
Keep it real and realistic
Too often, job postings outline an unattainable ideal. The list of required skills is usually far lengthier and more complex than the role requires. A study shows that women tend to apply for a new job only when they meet 100% of the listed criteria, compared to men, who usually apply when they meet about 60%. So, an unrealistic list of education and skill requirements in a posting deters female candidates from applying. Hiring managers need to communicate to the recruiter or to the applicants what skills are required for the role and which skills are just nice to have.
Walking the walk while talking the talk
To be successful in the coding test, candidates must be able to write code on a board or a computer while talking about their thought processes. They are often timed and therefore pressured to write the best, most solid code ever, as fast as possible, while discussing it. The coding problems candidates are asked to solve include things such as inverting a binary search tree.
In 12 years in this industry, I have never had to do that for my job, says Hilliary Lipsig, principal site reliability engineer and team lead at Red Hat. Some companies give you coding problems that are overly complex, unnecessarily difficult and actually don’t have any real bearing on the position you’re applying for. Some positions are that hard, but not most of them.
There’s not a standard hiring process, and that’s part of the problem, says Susan LeGendre-McGhee, a senior software engineer for Red Hat. To make it better, start with no coding test. I don’t see the coding test as being equitable for your candidates. Like myself, I don’t do well with timed tests and on the spot challenges. I am a great software engineer and I’m a smart person. But doing an on-the-spot coding test will make me look like a horrible candidate. So, if you’re going to do a coding test, make it something that a candidate can take home.
Diversity of thought makes software stronger
The other problem with the coding challenge and interview is that they are mostly conducted by men who end up hiring someone who looks and thinks and codes like they do. George S. Patton said, If everyone is thinking alike, then somebody isn’t thinking.
Coding involves solving problems with logic. There is not one single definitive way to do anything, ever. There are advantages and disadvantages to different ways of coding. I’ve goneinto meetings with people and had very passionate arguments about architecture approaches, says Lipsig. This code architecture is key to determining how much technical debt you’re going to have. What kind of problems are you going to face down the line? There’s a cost benefit with each choice. Do I use a structured query language database? There’s big pros and cons to each choice. Getting in there and having people to argue with about the best way of approaching things gives us better software. If you just surround yourself with people who always agree on the same thing and always implement the same tech stack, you’re never going to be challenged to grow outside that comfort zone.
The test only proves you’re good at tests
A lot of places have discovered that code tests don’t prove whether or not somebody can code, says Lipsig. They prove they can pass the test. These are tests. You can study for them and know what to do. Some of the things that I’ve seen work well and that I’ve done as hiring manager is to give a very simple test that shows me that you know how to do something that’s impactful for the job. Then have a collaborative session where you sit down and work together with another engineer who’s already at this company on a project. This tells me that an applicant can code their way out of a paper bag and whether a team can work with them. If people have GitHub or Open-Source contributions available, you can see their previous work. And just asking people questions, what did you do in your past work? How did you do it? Talk to me about it in depth. Getting into a little bit of the nitty gritty about people’s projects really tells you more about who they are as an engineer.
My best interview was a technical discussion on my past work, says LeGendre-McGhee. I was asked about what my work involved. How did I do error handling? How did I handle these kinds of things? If you really know the product and the system that you’ve worked in, you can describe that without having to write it all down in code to give people a good enough perspective that you have a technical acumen. You have an awareness of the things that need to be considered when you’re writing software.
The cool part of security is you don’t get coding challenges because it’s such a broad field, says YeseniaYser,senior product security engineer,Red Hat. I’ve revoked my candidacy for positions in the past if they ask for a coding exam, just because I know I’m not going to do well. I’m not a test taker. When I hire, I always look for passion and drive. I also love to ask candidates about what happens when you click the submit button on a websitebecause that gets them taking and explaining. The amount of information you can get from a candidate answering that question highlights what someone knows, it shows me a glimpse into their background and what they’ve learned.
How to draw out the best applicants
An applicant might not have all the individual skills that you’re going to need for that job, but perhaps they have curiosity, passion, technical understanding, analytical skills, and can provide deep insight into how they might approach a problem, says LeGendre-McGhee. Look at the whole person, not just what’s on their resume and not just what coding languages they know.
The best engineer I ever hired, technically speaking, failed the code test that we provided, says Lipsig. But they did such a great job of walking me through what they were thinking and why. They were just out of college with no experience, and it was their first engineering interview. I looked at that and I said, okay, I see the potential for this person to be a great engineer. They were promoted twice in their first year. Sometimes you just need to go with your gut and take a risk.
Change starts now
If you want to diversify the industry and make it better, you must begin with addressing inequitable hiring practices. It isn’t just about women – it’s about making the process more accessible for everyone: people with differing backgrounds and education, the neurodiverse, people who struggle with testing, candidates with English as second language.
Here are 7 ways companies can make the coding test and interview process more equitable:
- Create accurate job postings
- Level set expectations clearly and correctly
- Have a diverse hiring panel conduct the process
- Keep interviewer egos out of the application process and welcome different approaches and ideas
- Rethink the coding test, make it equitable, and ensure it’s true to the position being applied to
- Look at the whole candidate, not just the test score or their resume
- Join a women’s engineering community (such as WIT WISE) to interact with a wider candidate pool
It’s up to you to start driving change in the industry. Your team, your company, and your applications will be the better for it.
