Too often technical hiring is based on screening that doesn't actually take a candidate's real skill into account. We know this first hand, as we ran an experiment for 2 months trying to place 100's of Py users at companies ranging from 10 employees to over 1000. You can read more about that in our last blog post on closing the skills gap. The TL;DR is that we successfully placed two engineers at awesome YC startups Modular Science and Skymind.
As we began to work with more and more candidates, we gained a deeper understanding of the technical recruiting and interviewing process, and how this process changes from company to company. Within the last few months we've had the opportunity to sit down with recruiting leads from incredibly innovative companies like Airbnb, Reddit and OpenAI.
Talking with these recruiting experts, we learned about some of their biggest pain points and challenges with technical hiring. Here are some of problems that we discovered:
Time Intensive & Costly
All types of interviews, if done right, are extremely time-intensive. Understanding whether someone will be a good match for your role takes a long time. There are many boxes to check when making hiring decisions, and there should be no shortcuts.
Common aspects of the technical interview include phone screens, assessing a candidate's portfolio, culture interviews, and in-person interviews. Each of these steps are crucially important, but also extraordinarily time intensive. Your hiring process is a costly and necessary investment in your company.
For companies that need to scale up quickly, time spent on manual technical screening often results in interviews with candidates who don't even meet your company's technical bar and should have already been screened out. The reality is that this can be extremely costly to your company. According to Sequoia Capital, it takes on average about 990 hours to hire 12 engineers, and if spread over the course of a year you'll need to spend 19 hours a week on recruiting candidates alone. Let's estimate that the average fully load cost per hour including recruiters, engineers and anyone else involved in your hiring process is $200 / hr. That's a whopping $15,200 every single month spent on hiring engineers.
So it's pretty clear to see that hiring engineers can accumulate tens of thousands of dollars of costs in the form of time spent by engineers screening and interviewing candidates. Instead of having engineers and recruiters spend hours doling out the same coding problem interview after interview, they could be using those hours to solve that mission critical bug, or write that next feature your design team just finished. This kind of monotony creates a poor experience for both candidates and engineers.
Difficult to Calibrate
Depending on the size of your company, keeping track of candidate skill-level, and making data-driven hiring decisions can become increasingly complex. Every company claims to hire the "best of the best," but what exactly does that mean? What metrics are used to measure the "best" engineers?
In our own research talking with both companies and users, we found that the current recruiting process at many companies evaluates engineers by resume keywords, what school they received their CS degree from, and which notable companies they've worked for. None of these are necessarily indicators of whether an engineer is one of the "best." Furthermore, does "hiring the best" mean hiring the best candidates in the industry, or simply the best ones that are applying to your company? Making this distinction requires establishing some kind of standard that you must hold candidates to throughout the interview process.
Finding a way to benchmark candidates and standardizing the screening process ensures that candidates moving through to onsites already meet the technical requirements of your company.
As I talked about earlier, we've found that many companies screen engineers based on resume keywords, school, and company experience. Having engaged with and assessed hundreds of Py's users, we know that this outdated process screens out many great self-taught engineers who haven't yet built up serious credentials. These people automatically get eliminated before even getting a chance to demonstrate their skill.
Another compelling bias in technical recruiting is the PLU problem ("people like us"). This has been written about and analyzed by many researchers before and refers to the idea that great engineers tend to connect best with people like them. Ultimately, this creates a cycle in the hiring process that discourages diversity of thought. Standardizing your screening process creates a merit-based system that can help eliminate the PLU bias.
So to recap, here are the top 3 problems we heard:
- Traditional technical screening processes require engineers to ask the same problem tens or even hundreds of times. This is super time intensive, costly, and often leads to engineers getting burned out of interviewing.
- Calibrating your hiring process is difficult without technical benchmarks and standardization.
- Many great self-taught engineers don't get a chance to interview because they can't pass resume screens.
Automated technical screening helps to solve all these problems. Modern code screening tools like Hackerrank, Codility, Lytmus and Py all seek to solve this problems by attempting to eliminate many of the time intensive inefficiencies discussed above. Each of these companies has done great work within their particular niche of the technical interview. Hackerrank and Codility have successfully created coding challenges that are used by thousands of companies to streamline their screening processes. Lytmus solves a similar problem by simplifying project-based assessment instead of coding challenges. Py is bringing its own unique approach to both challenges and project-based screening that puts candidates first. We've learned an incredible amount from administering millions of assessments to our learners and we're excited to bring this knowledge to help companies hire better.
Learn more about our software at here!