This article was originally posted at the Accelerate Delivery blog.
Continuous Delivery removes the friction of delivering code to production. We can apply similar principles to the hiring process in software engineering. Like a software delivery pipeline, we can optimize steps in the process. As in continuous delivery we want to maximize the throughput and stability of our hiring pipeline. In the context of hiring "throughput" and "stability" have particular meanings:
- Throughput is the speed that we hire a candidate
- Stability is the quality of the candidate regarding team fit and engineering skills
We'll examine some experiments you can run on your own hiring pipeline and the benefits you should expect to achieve.
Tactics
The following experiments can run individually or all at once. You can adopt them 100% or to a small degree. Like all things continuous delivery, it's best to take the smallest, actionable step.
Remove phone screens
Let's assume a typical process to hire an engineer looks like this:
The phone screen stage regularly loops several times. There are phone screens with recruiters, HR representatives, engineering managers, and engineers. Employers hope to create a funnel of applicants that decrease in quantity but increase in quality with each phone screen. The goal is to have the highest quality candidates make it to the interview stage. The antipattern here is that high and low quality candidates go through all the same steps. Each step has a chance to weed out bad fits, but also deter good fits. Imagine what it's like for the candidate when faced with these gatekeepers. High quality candidates have choices. Why will they choose to go through yet-another-phone-screen with your company? From the hiring company's perspective it's a funnel to produce great candidates. From the engineer's perspective it's a gauntlet.
As a hiring manager, I want to replace as many phone screens as I can with "trust". One form of trust is that other people are doing their job. Establish relationships with people upstream in the hiring process. Learn how they screen candidates. Teach them how you do it. Help them become champions for your preferences. The other form of trust is that you are doing your job. Convince the other gatekeepers that your phone screen will be representative of their needs. The goal is to remove yourself entirely, or be the definitive phone screen. From the candidate's perspective this means they have may have a single phone screen. They may have no phone screens if they already have a relationship with you or someone you trust.
High signal interviews
An interview is like a code review. In this simile the candidate is a pull request and the interviewing team is doing a peer review. A peer reviewer trusts that CI enforces a stylistic baseline with linters and formatters. Peer reviewers don't review code style. Peer reviewers check for requirements implementation, logic flaws, and maintainability. This is an engineer's precious output. This is the unique, creative code that a human can produce that a computer cannot. Like a code review, you should not be verifying stylistic opinions in an interview. Interviewers should be checking the logic and culture that the candidate produces.
To remove stylistic concerns verify as much as you can about a candidate before the interview. Look for any possibility of a code sample. Reading code before the interview shortcuts awkward whiteboard questions about printing odd|prime|divisible-by-five numbers. Raise your baseline understanding of a candidate before an interview. This allows the interview to focus on the candidate's precious output.
During the interview present the candidate with high-signal questions. These questions should lead the interviewing team to make the ultimate decision: yes or no. "High-signal" has a different meaning for different teams. Given your team's desired characteristics, ask the candidate questions that verify a match. If your team is "biased towards action", "collaborative", "enthusiastic", "curious", etc. ask questions that drive answers around those characteristics. Avoid stylistic opinion questions like, "Which CSS-in-JS library do you prefer?" This is a great topic to discuss over lunch, but not helpful in an interview. We are looking for "strong opinions, weakly held", but we shouldn't measure a candidate based on their current opinions. It's more important to verify that a candidate changes their opinions based on new information than what those opinions actually are.
Offer letter at the end of an interview
Look at the interview process diagram again:
Sadly the interview is only the halfway point. We can make optimizations even after the interview. Employers gain time and good will by having an offer letter ready at the end of an interview. If you've honed your interview process to produce a high signal then what's stopping you? There's prep work involved in crafting an offer letter, but nothing unusual. The variables are generally: the salary you can offer, sign-on bonuses, stock options, and the candidate's name. For many candidates you can take care of this work up front. There may be ranges you can adjust as the interview progresses, but the variance should be minimal. This is an interview for a Senior ______ Engineer, or a Director of _______. The budget and variations are well-known before the interview takes place.
There's momentum during an interview. The candidate meets people they could be working with. The candidate begins to develop a relationship with them. The candidate asks questions and voices concerns that are hopefully answered and alleviated. The end of the interview comes and then, the candidate waits. Try drafting the offer letter before the interview. Get feedback from the interviewers before the end of the interview. You can continue the momentum of the interview with an offer letter and be one step closer to hiring. This isn't to say the "Offer" stage of the process completely collapses into the "Interview" stage. There is still time for negotiations around the offer. This is to say that you can start the offer stage immediately.
Benefits
Applying these tactics to hiring has similar advantages to continuous delivery in software development.
Low risk
Much like a small PR reduces risk. A short interview process removes risk for the candidate. They don't have to think about sneaking away from their current position for many phone screens or several on-site interviews. As an employer you've demonstrated that you know what you're looking for and you make it easy for the right candidate to simply say, "yes".
Risk decreases for the employer too. You're more likely to bring high performing candidates from the interview stage to the hired stage. High qualified candidates have less time to interview and consider other offers.
High throughput
Open headcount is a signal that the business and your team have a need. The longer the headcount is open, the longer that need goes unfulfilled. In an understaffed situation the incumbent engineers are more stressed. These developers work around the gap or try to pick up the slack. Fill open headcount as quickly as possible with the right person. You can get qualified candidates into roles faster when you optimize your hiring process.
Conclusion
Hiring, like software delivery, can benefit by focusing on stability and throughput. You don't want to sacrifice one for the other. Make modifications to lend credence to both.
Top comments (0)