Is your technical recruitment designed to bring out the best in software developers, or is your hiring process forcing them to join your competition? Tech talent are builders by nature and the best of them hang out at Github and Stackoverflow instead of LinkedIn. However tech hiring practices in most competitive areas fail to focus on skills and instead are biased towards presentation.
In 2015, Max Howell, the creator of Homebrew, shared a tweet that eventually made Google re-examine its interview process. Homebrew is arguably the most successful package manager software for macOS. Max pointed out the irony of being rejected in a white-board interview at Google when its engineers used Homebrew on a daily basis. His tweet found a lot of traction amongst developers all over the world who find tech hiring and recruitment processes falling short. Brian Acton was similarly rejected by Facebook and Twitter, before he went on to build Whatsapp and Signal, two of the world’s most popular messaging apps. Facebook later acquired Whatsapp for over 20 billion dollars.
There are multiple instances of high-profile developers being rejected during intense interviewing processes that fail to recognize their inherent merit. It is a consensus amongst developers that the recruitment practices and interviewing processes for tech talent are archaic and at times lack relevance. The applications they create and the challenges they solve, speak for them. Here are six ways your hiring process might be alienating quality software talent.
Resume & Keyword Driven Hiring Process
The first stage when applying for a new position from the developer’s end is to send out their resumé and then wait to hear back. The challenge here is that in a resumé taken up with technical keywords and jargon, it is hard to demonstrate how one stands apart. It is similarly difficult to convey the degree of one’s skills and experiences through mere keywords. Eliminating applications based on keyword matches rules out a lot of suitable hires. Keyword-focused elimination is a superficial technique that forces candidates to tweak their resumes and stuff them with keywords, just to be noticed.
Focus On Experience (Not Skills)
For the recruiter, it is a task of increasing complexity to tell apart the depth of a developer’s skills and aptitude based on his/her resumé from a pool of similar applications. The natural inclination is to focus on some traditional indicators including years of experience, and organizations worked for. In a fast-evolving and innovative field like technology, the number of years could also be a handicap unless one stays abreast of the latest changes taking place. Millennials are more comfortable answering technical questions on StackOverflow than keeping their resumé current. Not only that, but theirs is a generation that wants to find purpose through work more than the previous generations. They will often if not always choose an organization that aligns with them ideologically, even if it means bypassing ones with better repute. Therefore, traditional metrics of worthiness do not apply smoothly to the domain of technology and its craftsmen.
White Board Presentations
When Max Howell spoke of being rejected in a whiteboard interview, he struck a nerve with many developers. Presentation-centric interviews ask the candidate to engage in complex high-level abstract thinking while being put on the clock and judged by a panel. While it is true that a certain degree of stress is natural during a test of skills, most developer interviews provide an overall discouraging experience for a lot of candidates. Different individuals perform their best under different conditions and expecting every developer to do their best under intense scrutiny sets up a lot of them to fail. Besides, such interviews do not necessarily test for the key skills that a software developer would typically employ on a day-to-day basis either.
Irrelevant Interview Format
Unlike some other professions, a lot of very successful developers do not have a traditional education in computer science. Many with formal degrees supplement their education by working on their own projects. As soon as they acquire a good understanding of basic principles and good practices for programming, developers are required to be very hands-on. But a lot of organizations design their interviews with a heavy emphasis on the deep rigors of academic learning rather than the developer’s ability to build and fix applications. While testing on abstract questions is necessary, and in-depth interviews might be required for the role of a researcher, most developers could do without being tested on algorithms that they are never likely to come across during their day jobs.
Checklist & Tool Driven (Not Aptitude Focused)
Another common issue that leads to the rejection of a lot of talented people in the early stages, is hiring for one particular sub-skill as opposed to their general aptitude for that skillset. People with a first-principle understanding of a domain still face rejection because they were using a tool slightly different from the current-market favorite. Additionally, the vast number of available software tools and technologies do not allow for any one individual to keep up with all the new releases even in their own domain. Therefore, checklist-driven interviewing does not test for the ability of the engineer to learn and scale into new technologies, an essential skill in the fast-paced tech environment.
Long Drawn Out Hiring Process
Interviews are often drawn out over a long period, with multiple stages of being tested. Often these are tests that could have been administered more efficiently over fewer days. For the developers themselves, the process of getting hired starts even earlier. Due to all the roadblocks discussed above, particularly the flawed nature of technical interviews, many developers spend upwards of six weeks preparing for new roles. These new roles are often later transitions from one organization to another, with very similar requirements of skill and competency as their current ones. Many developers postpone looking for new roles or forego the idea of finding new ones altogether, due to these extra demands on their time to clear stressful tests to demonstrate abilities they are by all means already proficient in.
Can you Hire More Efficiently?
While developers are most valued in their domains for their ability to build and fix things, the prevalent hiring practices do not set up good ecosystems to test for contextual skills. In that sense, there is a cultural misfit between the hiring entities and the people they seek to hire, making the process of hiring a painstaking and unrewarding task for everyone involved.
The encouraging aspect, however, is that recruiters need not start from scratch to make the hiring processes more relevant and rewarding. Only the existing interviewing ecosystems and selection paradigms need to be modified somewhat to facilitate a more transparent and intuitive experience for good candidate selection. In our next article, we discuss the measures that can help a hiring specialist draw the best and most fit people for the roles they seek to fill.