Getting Hiring Right
While this post primarily focuses on hiring engineers since that’s where I have the most experience, many of the thoughts here are applicable across the organization.
Since writing about Sindeo’s shutdown a few weeks ago, in addition to my own search, I’ve had the unique experience of being an observer and mentor to a team of engineers going through the hiring process at dozens of companies. Most of these have been net-positive experiences for my former colleagues. However, it has really highlighted that even when companies try to be scientific about hiring, they are probably focusing on the wrong areas. My firm belief is that hiring is both an art and a science in nearly equal measures. Some quick Googling shows that I’m not alone in this belief (yes, confirmation bias at work here!) Where do things go wrong?
Define the Role
It’s still amazing to me when I talk to hiring managers and they are still unclear on what they’re hiring for. It’s one thing to refine your search a little bit, but the difference between a junior front-end and a senior full-stack engineer is pretty significant. Similarly, a hands on, engineer-first manager will not necessarily have the same long term motivations as a candidate who has been relatively hands off but is great at building teams and managing people and process. To avoid wasting time, be honest about the pieces that are missing within your organization. Then make sure everyone internally is bought into the role. I talked to one company recently where the hiring manager (CEO) was talking about a VP of Engineering role but the incumbent director of engineering thought he was getting a peer to manage another development team — that made for an awkward conversation with the “peer”. Finally, craft your job description(s) to make sure you are clear about what you want so that you get the right sort of candidates.
If I had seen the job description before I interviewed, I never would have applied!
Yes, that’s a real quote from one of my team members after getting the job! On paper, this engineer wouldn’t have been qualified for the posted position. However, after blowing the company away on the tech challenge and interviews, it became clear how good this engineer is and what a natural fit there was. Getting your job description right is critical to getting a good applicant pool. Too often, I see job descriptions include laundry lists of every single thing the employee might need to know, not just those skills that are critical for success. This has been shown to introduce bias at the very first external step of the hiring process. Instead, when you’re taking that first, internal step of determining what you need, make an effort to distill that list down to the most critical success factors. After you’ve drafted the description, run it through a bias detector. There are free options available, but you can also find paid services like Textio that are more robust if your budget will support it.
Once you have a clear job description, you can start to fill your funnel. This is where you’ll find the difference between good and bad recruiters. What separates them? Research. Despite how simple this sounds, there’s actually enough that goes into this that I’ll write a separate post on recruiters and sourcing. In the meantime, suffice it to say that if you’re sourcing yourself, you should do a little homework before reaching out to a candidate. If you’re using an internal or external recruiter, make sure they’re doing the same. First impressions are critical to getting the ball rolling smoothly.
As a hiring manager, I find technical / coding challenges to be an essential part of the hiring process. I want to know how someone thinks, if they can solve problems, and if they can write some code. Some gross generalizations for myself: I’m typically looking for generalists, so I don’t care what language they take the test in, am not concerned with whether they can find the O(1) algorithmic solution, and could care less if they need to Google some syntax along the way. Obviously there will be exceptions to these “rules”. So it has surprised me to see the various tests that my team has gone through. Front-end engineers being asked deep SQL questions or to code an entire back-end in Ruby. Junior engineers being given senior challenges “because we have never hired someone with less than 10 years of experience and don’t know how to modify our challenge accordingly.” Exercises where the candidate is asked to spend “no more than 8 hours” on the test, but then is given no feedback at the end of it. Tests that have implicit bias such as spelling at grammar.
Just like with your job descriptions, structuring your technical challenges is important and they should reflect the skills needed for the position they are intended for. If you’re looking for a computer vision engineer, then questions about Convolutional Neural Networks makes a lot of sense. In that vein, I can see an English test being really useful when evaluating a marketer, sales person, or lawyer, but its utility for an engineer is less obvious to me. While some have suggested moving away from the automated challenge, I think those are fine. Instead, I’d encourage you to focus on the skills that are most critical when designing your challenge. For example, my wife recently created a case study for entry level operations candidates. The critical skills for her team are problem solving and attention to detail; Excel skills are nice to haves. She did a great job of structuring the case study as an Excel spreadsheet in a way that allowed for a “brute force” method that didn’t require Excel knowledge, but would allow for candidates with specific expertise to shine.
Interviewing is a two-way street, an opportunity for the candidate to vet you as much as for you to vet the candidate. So, while you expect the candidates to come in having done a lot of research into your company and well prepared for the interview, they would like to see the same level of effort from you. Spend some time briefing all of your interviewers on the specific areas of focus to make sure questions aren’t being repeated. Make sure your team has read the candidate’s resume, looked at their github, browsed their LinkedIn, etc. (but be careful about what you look for and use). Train your interviewers and make sure they practice in advance and are able to keep the interview legal. I’ve been surprised by how many stories I’ve heard of inappropriate or illegal questions that my friends have been asked during interviews.
You generally only get one chance for an onsite interview with the candidate, so you want to make sure to get all of your questions answered. Well prepared and rehearsed interviewers will stick to the schedule, be more effective in the questions they are asking, ensure they get the answers they need, and provide a better candidate experience. Speaking of which…
The Candidate Experience
The candidate experience during the interview process is really important. Yes, the candidate needs to sell themselves to you, but the same is true in reverse. Given how small the world is in combination with tools like Glassdoor, negative candidate experiences can really impact your ability to hire. A couple of anecdotes:
- Three of the Sindeo engineers interviewed at one company. After the interviews, they compared notes and discovered that answers to their questions about mentoring, internal promotions, and process were not consistent. When only one of the three received an offer and the other two didn’t even receive follow up emails, it made the decision not to accept the offer easy.
- I’ve heard from several female friends and colleagues that they are asked inappropriate questions about their appearance, dating status, and worse during interviews. Needless to say, they were unimpressed and decided to take their talents elsewhere (and in several cases, filed complaints with the HR teams and/or EEOC).
- A former colleague went into an interview where the CEO, rather than giving an upbeat sales pitch about why the candidate should join the new company spent the entire time trashing the candidate’s current employer. Some advice here for candidates and hiring manager’s alike — you want people running to a new job, not from an old one.
In short, the more excited you are about a candidate, the more likely they are to get excited about you. Ultimately, you want all of your candidates to walk away from the interview as net promoters of your company, even if they don’t get the job. Ultimately, their perception of your company becomes their reality.
The Cost of Failure
Interviewers tend to be most concerned with trying to avoid “false positives” as hiring a candidate who doesn’t work out can be highly problematic.
— Harvard Business Review
There is absolutely a tangible cost to getting hiring wrong. In fact, the cost of advancing a “bad” candidate increases at each stage of the funnel. It’s really low cost to reject someone based purely on their resume, but by the time they’ve come onsite, you’ve invested a lot of time and energy into the candidate. And, if you make a “bad” hire, it can really be painful and expensive to fix. To that end, I typically give everyone on the interview panel “veto” rights — and vetoes aren’t explicit. If anyone is lukewarm about a candidate, that’s a signal not to hire. However, there is also an opportunity cost to not filling a role. Multiple times in my time as a hiring manager, I’ve had a critical role that we just couldn’t come to consensus on any candidates. To get around it, I’ve brought on engineers in a contract-to-hire capacity. This gives people, especially introverts, an opportunity to overcome a “good, not great” interview experience through on the job experiences. I am very candid with these employees about what the yellow flags were that prevented a full time position so that they know what, exactly, I’m evaluating while they’re under contract. And I give them open and honest feedback along the way so that they know how they’re doing. This helps avoid the “misses” while keeping the cost of a false positive a little lower…
It’s All About Culture
I’m planning to write more extensively about culture — specifically about building and nurturing it intentionally — but until then it’s important to mention in the context of hiring. Whether you’re a company with well articulated values that people live and breathe or an organization that aspires to have that level of culture, you still want to make culture a focal point of interviewing. Some companies (like Amazon) describe their core values clearly on their websites. Others send their values to all candidates. Their goal isn’t get find more homogenous cogs for their organization, but to find people who believe in the same values, even if they have different approaches to getting there. At a recent @fintech-devs-pms meetup, Kevin Lochner, Engineering Lead at Clara, talked about hiring for competency fit rather than culture fit.
Personally, I advocate for “culture add” over “culture fit”, which is very closely related to these concepts. Knowing what you value will help you find people who share those values even if their approach to adopting those values is different.
A hiring process built around an undefined notion of “culture fit” is fraught with bias.
This is by no means an exhaustive post, but will hopefully provide some help to overcoming some of the common “mistakes” I’ve seen in hiring processes. Any questions or comments? I plan on diving into these topics and more in future posts and would love to share stories from others about what works and doesn’t work!