Fallacies are destructive. They are mistaken beliefs based on unsound judgment or flawed reasoning. Technical hiring managers are not immune to believing fallacies; if not exposed, these fallacies can trap you in a never-ending cycle of ineffective hiring practices.
The following are fallacies we’ve seen technical hiring managers fall victim to.
1. There are plenty of developers on the market
The U.S. is in its biggest tech labor shortage in history with nearly 1M unfilled jobs, and this number is projected to continue to grow significantly. Because of this shortage, effective recruiting is more important than ever. Hiring the right technical talent requires more time, strategy, and resources to grow your company.
2. Developers will apply for my job
The best talent is gainfully employed and not actively seeking new opportunities. In fact, only 14% of developers are actively looking for a new job, while 55% of developers are open to new opportunities, but not looking. Waiting for the perfect candidate to apply is like sticking a fishing pole in the water next to 100,000 other fishermen (and women), walking away for 8 hours, and expecting to find a fish on the line when you return. Even tech giants with iconic brands have thousands of recruiters reaching out to candidates on their behalf. You need to actively pursue passive candidates and court them with a compelling problem to solve.
3. People want to work here
Why? You should assume candidates don’t know anything about your company. It’s your job to kindle excitement in candidates. From job posting to conducting interviews, every interaction you have with candidates is an opportunity to sell the candidate on the role, company, and mission. Not all great developers have a personality that shows outward excitement, but they may still be excellent at the role.
4. Good developers can think clearly during whiteboard interviews
Research has shown that many well-qualified candidates are eliminated by whiteboard interviews because of anxiety—they aren’t used to performing in front of an audience. Instead of whiteboard interviews, developers prefer live coding interviews that include discussion. Candidate experience must be considered when designing an interview process, as nearly half of job seekers have declined an offer due to a poor experience.
5. The right candidate is someone I’d grab a beer with
Whether or not you would hang out with someone outside of work shouldn’t influence your hiring decision. In her viral TEDxPasadena speech, Valerie Alexander explains that companies with diversity are more successful and profitable because they have people that think differently in the room. Biology biases you to think positively about a person if they look like you or act like you, regardless of the individual’s actual ability to perform in a role. Confront your bias(es) in hiring. Hire based on competency and fit for the role rather than similarity to yourself or the rest of the organization.
6. I need to hire an expert
Be wary of using the term expert when explaining the proficiency you’re seeking in a particular skill. Engineers often equate this term with superhuman, and rarely self-describe using this adjective. Often developers with the deepest expertise in the field feel they know the least. Their humility stems from an acute awareness of how much there is to learn. Great developers learn quickly and choose the technology that best suits the task at hand as opposed to defaulting to their preference. Hire people who are proven performers; don’t restrict your search to experts, or you might miss someone great.
7. You can accurately evaluate someone’s problem-solving ability in an interview
Accurately measuring problem-solving ability or intelligence requires extensive professional training. A research-backed, standardized general mental ability (GMA) test has the highest validity for predicting job performance and the lowest application cost. Facet’s hiring handbook outlines the selection methods that most effectively predict job performance.
8. Coding tests are accurate and effective
Work sample tests are only effective if they mirror the job the person will be doing. And coding tests often feature problems that have no direct relation to the daily job requirements, rendering them useless. HackerRank, Leetcode, and other contrived coding environments don’t fit the bill. That’s not how developers work. Coding is done independently over time, not under a one-hour deadline with little time to troubleshoot.
9. Intelligent developers raise the bar
If you yourself are a 90th percentile developer, that leaves only 10 people you can hire before hitting the 100th percentile and being unable to raise the bar further. Mathematics aside, hiring a bunch of Einsteins isn’t the only way to take your team to the next level. Strive to hire a variety of strengths that provide your team and company with diversity and balance. Research shows that companies that are more diverse are more innovative and work better together. Teams with diversity of knowledge, ideas, and tools provide companies with a competitive advantage.
10. Side projects are evidence of a strong performer
Eighty-eight percent of developers code outside of work, with 73%of them coding as a hobby. With such widespread participation, side projects aren’t going to help you weed out the wrong candidates. In fact, hobbies and interests, when evaluated on their own, are low predictors of job performance. Your time is better spent accessing GMA to identify a good developer.
11. Good developers contribute to open source
Some developers like to contribute to open source in their spare time. Others don’t, and that’s okay. Only a small percentage of developers are lucky enough to contribute to open source as part of their job, so you shouldn’t use it as a general measuring stick. A more valuable trait to look for is lifelong learning and improvement in their craft, which can take many forms.
12. I’m too busy to prioritize hiring
Steve Jobs said, “Hiring the best is your most important task.” You can’t afford not to hire people. Waiting will only dig you further into a hole of talent need and you risk burning out your existing team as a result. The only acceptable reason to delay an interview is “production is down.” Hiring will require an investment of your time and resources but with the right hiring strategy, the process can move quickly. Facet can help.
13. It’s risky to deliver meaningful interview feedback
Your job is to hire the best-qualified candidate. If your decision to pass on a candidate isn’t discriminatory, don’t fear sharing your reasoning, especially if you’d like to maintain a relationship with the candidate for future positions. Forty-eight percent of developers wish they would receive feedback after an interview.
14. Gaps in employment mean someone is unreliable or unqualified
Sometimes gaps are just that—gaps. Great people are often laid off because of mistakes the CEO made. Candidates have a life outside work that may require them to step out of the workforce for a period, like to care for a sick family member. To manage a deceased parent’s estate. To prioritize their health and well-being. To travel the world. The list goes on and on. If you want to know why a gap exists on their resume—ask. Don’t assume it’s a negative consequence or due to a lack of ability.
15. If the developer’s last startup didn’t reach unicorn status, they aren’t talented
Developers have very little control over the success of a company. The founders’ decisions carry the most weight. There are many talented programmers who work at startups that will fall short of unicorn distinction.