Four Common Mistakes in Hiring Software Engineers
Published:Contents
1. Overview
Developing a hiring pipeline is one of the ultimate bike-shedding endeavours for any software organization. The idea of hiring, and how to do it "right" is an easy one to understand and, as such, one in which everyone wants to be involved. But your goals as a software engineering organization should be simple.
While overall needs may be nuanced and diverse, we can spell out some at a high level.
2. Goals of hiring
Hire qualified and diverse talent, capable of supporting your organizational needs
At a bare minimum, you are hiring to satisfy a need for your organization, and that means you need qualified hires. As such, any interview process should attempt to assess candidate skills and make sure they can do what is needed of them. Additionally, we want to make sure we are not limiting diversity in our hiring. Diverse opinions and backgrounds working together vastly improve the efficiency of solving problems and solving problems is why we hire software engineers.
Limit organizational resources needed to fully assess a candidate
Every hour of time spent assessing a candidate is not just an hour spent by that candidate, but an hour spent by one or more resources paid by your company in completing the assessment. You should want to be respectful of everyone's time and ensure that time is used efficiently. This will save your organization time, which means it will save money, and will also save frustration on part of your candidate.
Minimize candidate friction throughout the hiring process
There is an old adage, "You are not the only one interviewing a candidate. The candidate is interviewing you as well." Minimizing candidate friction during your interviews and assessments -- ensuring that candidates are comfortable and able to perform well -- reflects well upon your organization and hiring team. It also has the added benefit of allowing each candidate a chance to shine.
Minimize time to hire
At the time of this writing, there is a labor shortage. Every company is competing for the same limited pool of workers. Limiting the amount of time it takes for your company to determine a good fit can give you a hiring edge. But that is not the only reason we should consider reducing the time to hire. Candidates are generally appreciative of focusing your time and energy in quickly reaching a decision. Repeated rounds, delays in decisions to move forward, or prolonged scheduling conflicts can reflect poorly on your organization. Would you want to work for an inefficient company that does not respect the value of your time?
3. 4 common pitfalls in hiring
Now that we understand our goals, at least at a high level, we can begin to discuss many of the common ways our hiring pipelines counteract them. Let us address each of these with the caveat that they may not be universally true when hiring. However, the odds are high that they will prevent you from finding and retaining valuable candidates.
Crafting a misleading or incongruous job posting
Job postings can be difficult to craft. You need to make sure that you can account for the skills and duties of the job in a way that limits underqualified applications while not running off the qualified applicants perfect for your role. This process can lead to a number of issues, but two are actually surprisingly common.
First, we should make sure that our job postings accurately describe the nature of the role. If your posting is inaccurate or excludes duties, then any hire made would be under false pretense. Unless, of course, you explain the "real" duties of the role in the interview. In this case, the applicant will likely leave feeling as though they have been bamboozled and had their time wasted. Most everyone appreciates honesty in nearly all aspects of life. So make sure you put the time and effort into making sure your posting is accurate. Otherwise, at best, you will start out on the wrong foot with any potential hire -- if you can make a hire at all.
Secondly, many organizations may not yet have strong technical roles as they hire out their engineering team. In these instances, it is best to consult with a technical expert in crafting the skills needed for a job posting. We see three common errors error here.
One is creating job postings which are non-sequitur to those folks you would like to have apply. For example, we recently saw a job posting looking for "Strong Python developers with experience in common Python libraries like React." The problem with this request is that Python is a programming language and React is a library for JavaScript, a completely different programming language.
And two is creating a job posting requiring technical knowledge which is unachievable. For instance, in hiring an experienced front-end engineer, a posting might require ten years of Vue.js experience. This could seem perfectly reasonable to the hiring manager who might not have as much front-end experience. Sadly, as of this writing, Vue.js has only existed for eight years. This limits the pool of qualified engineers to zero.
Finally, the third common incongruity we see in job postings is "throwing the kitchen sink" into the qualifications. Make sure you are asking for the skills required for the role. Do not ask for extensive experience with every technology under the sun. Many smaller companies often ask for skills like, "Five years experience working with Drupal, WordPress, and Django," when what they really need to say is "Experience working with the Drupal CMS." Drupal, WordPress, and Django are all very different Content Management Systems requiring different knowledge and skills, and it is uncommon to need to know how to use all three for a single role. There are jobs where that knowledge is necessary, but they are few and far between.
Testing for skills that are not required for the role (i.e. algorithm questions)
One of the single most pervasive issue in hiring software engineers today are questions related to algorithms -- such as performing a depth-first search or inverting a binary tree. Originally, utilized by large tech companies like Google, the use of algorithm questions has needlessly permeated much of the technical field as other companies sought to copy the tech giants without necessarily understanding the reason such questions might be asked in the first place. That reason -- weeding down thousands of highly-qualified applicants to a hand-full in order to save internal resources.
For most every other company or organization, this is overkill. Engineers spend months memorizing common methods of solving algorithms in order to pass these questions, but ask them a few weeks after hire how to write a bubble sort and they will do what any sane person would -- look it up on the internet and see if someone has released a public library that implements it. So -- what are you testing when you ask algorithm questions? Mostly, the ability of the candidate to temporarily memorize obscure facts. Is that the major skill required to be successful in a role within your organization? It is unlikely.
Instead, interviewers should find a small set of questions applicable to the role. Ideally, technical interview should revolve around real problems that test real skills that will be useful on the job. If you ask an engineer when they last had to read a stack trace, most will have done so recently. If you ask an engineer when they last had to implement a bucket sort without the of libraries or native language methods, they will tell you it was during their last interview.
The worst outcome of this approach to determine candidate competency is that you might very well find yourself hiring an engineer who knows how to memorize lines of code, but does not know how to solve problems or debug production issues.
Hiring for "cultural fit"
When we were asked the best methods to evaluate candidates, we always suggest creating a set of objective criteria with which to assess every interview. We take copious notes when conducting interviews, looking for evidence that the candidate will succeed or will not succeed in the role. As much as possible, we want to remove subjectivity from the interview process because this allows bias to creep in. Bias left unchecked can reduce diversity of opinion and as such, weaken an organization dramatically.
There are few criteria which ooze subjectivity more than "cultural fit."
What does cultural fit mean? That the person you are interviewing does not talk the way you would like? That the person does not think the same way you do? That the person has different interests or motivations than you would have had? No answer to these questions avoids the path of ruin. So, it is best to consciously decide to avoid using "cultural fit" as a criteria.
That is not to say that you might turn away an unashamedly arrogant candidate who derides others. Software development is a team sport and everyone we hire should be able to work well with others.
Placing an emphasis on gut feelings
This is the second monster of subjectivity that creeps into the interview process. Like "hiring for cultural fit," it is hard to find a good reason to trust one's gut. It gives us reason to trust our biases more than reason.
Notes are a great way to help determine whether that gut feeling is wrong or right. Treat yourself as a fact-finder, instead of a wise sage, and use questions to determine definitely whether a candidate will succeed or will not succeed in a role. If your decision comes down to gut feelings, you should probably be asking better questions.
4. Conclusion
The above mistakes or pitfalls are not universal. They may even, rarely, be necessary. But for most software organizations, each should be avoided. All are contrary to the goals we have outlined.
So, when working on your next interview pipeline, remember to try to avoid these errors. Some are so ingrained in the software industry it might seem counterintuitive not to include them. Instead, determine what your goals are when hiring great teammates to help your company succeed. And make sure you are working towards them.
Categories: hiring organization