Interviewing your future coworkers — finding a kinder, fairer way to hire
Do you dislike subjecting hires to whiteboarding, laundry lists of skills requirements, unpaid homework, and computer science drills, but don’t know what to do instead? Are you worried that your current process is driving away applicants who are underrepresented in tech? Are you tired of complaints that “we just can’t find good applicants for this role?” This article is for you.
We’ll cover everything from the job description to the final interview.
Job description: describe a real-life task, instead of lengthy desired skills
Which approach do you think is more likely to draw in the right candidates? A long list like “3 years in JavaScript, 1–2 years Postgres, some familiarity with statistics,” or actually describing the challenges of the day to day work? This small challenge is really similar to the work that someone would actually do at the company, and it’s something I’ve put in job descriptions.
If you had a CSV file, Google searching, and some time, could you write some JavaScript to calculate the average values from each column, return the results via a GET endpoint on a small local server, and show them in a graph? Do you enjoy data-related puzzles and challenges? Then please apply!
Some of the greatest difficulties of hiring a developer are that the titles are meaningless and years of experience with some particular tool is a poor way to measure whether someone might have the right skills. Furthermore, research shows that people who are underrepresented in tech are less likely to apply unless they meet all the listed criteria, compared to other sample groups.
Job description: watch out for language that drives away team players
Terms like “rockstar” and “fast-paced work environment” can drive away the people who you want on your side. These words are well-meaning, usually an attempt to convey that the work is interesting and varied, that domain expertise is valued, but that’s not often how job applicants read them. This description can be read as “unsupportive and frantic work environment” to some people you may wish to attract. In a healthy team, people collaborate so effectively that heroics and panic-coding are uncommon, where deadlines and outcomes are predictably met. So why use these kinds of words in your job description?
Tools like Textio can help you examine how your word choices in a job description could impact the kinds of applicants that you get. You’d be surprised at some of the suggestions! Check out this article to learn what words to use in their place.
Read up on unconscious bias
Facebook has my favorite resource on unconscious bias. The slide deck is short and succinct. It’s your job to understand common failure modes and correct for them when you see them. For anyone who participates in the interviewing process, get them to read the same article or resources as you. It’s helpful if everyone is using the same point of reference, in order to de-personalize the experience if someone might be showing unfair bias.
For example, let’s say a colleague describes a woman candidate as “too harsh” for the team. It’s helpful to be able to say, “do you think it’s a red flag or just a first impression?” instead of “well, I read this one article that said women with leadership skills are more likely to be rated negatively than men…” You get the idea about how that could turn out!
Always tell candidates what the interview will be like
As an interviewer, I consider it my job to help someone give the best interview that they can. For me, this means no surprises. It means viewing my process through the lens of someone who is nervous and anxious, and refactoring accordingly.
I have a template email that goes out before every phone screen, saying that I’ll tell them about the company and the position, ask them to describe some of their recent experiences, and then do open Q&A. I recommend them to research the company and prepare some questions that they have. At the end of the phone screen, I tell them that if they are selected for the next round, we’ll ask them to provide some code samples for us to analyze and ask questions about. I reassure them that we aren’t looking for perfect code samples — in fact, we’ll be asking about how they would improve the code if they had time to keep working on it. I explicitly state that there will be no trick questions, computer science algorithms, live coding, or whiteboarding. I tell them to dress how they feel comfortable, there’s no office dress code, and that I’m wearing jeans and a plaid shirt. Lastly I suggest that they bring a laptop if they want to show off something that isn’t on their public portfolio.
During the interview, I kick off with an outline recap. I explicitly say, it’s ok to take a quiet moment to think before you answer questions. After the interview, if there’s something you forgot to share or that you think of later, you can email me!
The thing is, I want to hire the best candidate, not the candidate who is best at interviewing, and so I try my best to put people at ease.
Do a code review instead of homework & whiteboarding
I get itchy just thinking about whiteboarding. On one hand, sure, it can help show how people think… under pressure and fear or anxiety! I don’t want my current coworkers to ever feel that way because of me, so why would I do this to a possible new hire?! Likewise, I strongly dislike giving homework, because who will do best? The person with the most free time and/or economic stability has an unfair advantage.
So what can you do instead of putting people on the spot with live coding and whiteboarding? Doing a code review of something a person has already written gets you everything you could learn from whiteboarding, and more!
Ahead of a 2nd-round interview, I ask candidates to share 2–3 code samples. I tell them that if they don’t have enough samples, we may do some live coding, but I would let them know ahead of time if that turns out to be the case. I also let them know that it’s ok to share 1 code sample that was from a group project. I review what they sent ahead of time and come up with a few questions. The questions tend to fall in a few main categories:
- Did anyone work on this project with you? How did it go? This is a warm up question and a light check for red flags.
- Pretend I was going to work on this project with you. Would you explain this section to me? This shows how well they understand what they’ve written and what their communication skills are like.
- If you were working on this with someone else, how would it change how you work? I’m looking to see what they already know or don’t about good Git habits, testing, etc.
- How would you improve this section to make it easier for someone else to understand? Does this person have empathy and the potential to be someone who could train the next hire after them?
- How does (some function) work? Why did you approach it this way? Smoke test to make sure they wrote the code, and insights into the problem-solving process
- I critique some section, and then ask “What do you think?” This is a test for how they handle criticism. If I press them a couple times for more explanation, and there are no red flags, afterwards I tell them explicitly “I was looking to see how you respond to criticism, since that’s a normal part of software development. I appreciate how you handled it in X way.” This is to put them back at ease.
- How would you further develop this if someone paid you to work on it for a week? This serves three purposes. One, it’s a nice palette cleanser after #4. Two, through followup questions, I can see how they might handle an open-ended project and an unstructured task.
This is the time to ask hard questions. Pull no punches. The point of doing this segment as a code review instead of whiteboarding/live coding is that one mistake doesn’t derail the rest of the interview, and being nervous likely can’t ruin the whole exercise in the same way as live coding. Everyone still has a chance to recover from a tough question, show you their best, and end on a good note.
Use live pairing for candidates with insufficient code samples
There are many reasons why someone may not have enough code samples to do the type of interview listed above. Maybe they are very junior and don’t have many, or maybe they are senior and all their code belongs to their employer. Maybe they leave their work at work (gasp!) and don’t code as a hobby. I don’t want to screen these candidates out! So live pairing can be a way to still give them a fair shot.
I won’t go into a ton of detail here because there are many strategies that have been extensively written about by other people. To summarize, my suggestion is to choose an example that is either real-world pairing, or some type of coding challenge that has levels to it, where almost anyone can succeed at part of the levels. If you go the coding challenge route, make sure to inform the candidate that the goal is not to finish the challenge, they can ask you any questions they’d like, including asking for help, and that a quick Google is ok. Knowing when and how to ask for help is a skill! Effective Googling is also a skill! I want my future coworkers to be able to do these things, and so I should let candidates do them and see what I learn about their skills.
When you make a decision about this candidate, it’s important to note aloud that you will have different information about them than candidates without pairing exercises. Do your best to balance accordingly.
Resist hiring for “culture fit”
Too often, “culture fit” means “people like us.” It’s not a good thing when it takes that turn. There have been attempts to rehabilitate the phrase, but I think it’s easier to instead screen for whether someone connects at least a little with the company mission or engineering team values, and leave the idea of finding a good “fit” at the curb. Many of the best coworkers don’t fit, they define — they take an active role to mold and shape culture, making things better than they found them.
So how can you interview for connection to the mission or goals of the team? I ask this question:
A year from now, imagine we are celebrating your accomplishments. I just gave you a double high-five. What did you do?
This question has varying levels of success, depending on how creative, quick thinking, and relaxed a candidate is. I try to ask it near the end of the interview, when I’m most likely to get an imaginative, candid answer. Hopefully, by that point, some of the interviewing nerves have worn off. The answer shouldn’t be considered a dealbreaker, but it is an excellent tie-breaker if I’m torn between two candidates with comparable skills.
Another question I like to ask along these lines is:
If you could wave a magic wand and change one thing about your last workplace, what would it be? (as a followup, what did you do about it?)
This is a good question to look for red flags. Do they talk down about others? Do they have unrealistic expectations? Do they shrug off problems, or try to communicate with others to resolve them?
Follow a repeatable structure
Resist the urge to iterate on your interview process between candidates for the same role. To make a fair assessment of skills, you need to pick an approach and stick to it. That doesn’t mean you can’t have a natural, conversational flow, but it does mean that if you learn a better way to do something, you should write it down for the next time you do hiring.
Do a retrospective
After your new coworker has settled into their new job, ask them for their honest assessment of how the interview process could have gone better. Ask if they have any ideas for the next round. Then, meet with your fellow interviewers to digest. Revise any process materials right away, while the information is fresh. Every company or team’s hiring process is different, and it takes some trial and error to find out what works best for you.
Possible shortcomings of this process
The main shortcoming is, I am not sure how well it scales. It has worked excellently for a small startup (less than 10 people). If you have 50 candidates to interview in a month, it might not work great, but there may be pieces you can borrow. I’d argue that in cases of explosive growth, it matters even more to take the time to hire the right person, since they will be running interviews themselves soon, but deadlines are deadlines.
Additional resources
In addition to the articles linked throughout this post, I recommend:
- A list of companies that don’t whiteboard, maintained by Lauren Tan. Add your company to the list after you get buy-in from your coworkers!
- April Wensel’s article, Leave Your “Gut” Out of Hiring. Her articles in general can be very eye opening to how different engineering processes we all accept as normal are actually actively harmful
- This set of materials and research on unconscious bias. I’ll mention it again because it is absolutely critical. I read them every six months. It is your job to uncover your own bias and do something about it. It’s also your job to bring others up to speed. If your team is resistant to talking and reading about unconscious bias in the workplace, maybe you need to start looking for a new job :P
One last note
You can’t do everything all at once, and you won’t always get it right. Candidates will cry, you’ll mess up, etc, etc. This is normal. What’s most important is that you treat interviewees like future coworkers as best you can, you learn from the mistakes, you keep making improvements, and you maintain an open dialog within the hiring team. You got this! Good luck!
