I have yet to meet anyone involved with IT hiring who is happy with the process in its current form. Candidates are frustrated with “shopping list” job postings that don’t reflect the actual work, hiring managers struggle filling positions they don’t quite understand, and IT leaders end up struggling to find the talent they need.

Even the tools of the hiring process are horribly broken. I’ve seen job listings that demand “over ten years’ experience” in a dozen complex technologies, several of which didn’t even exist ten years ago. Hiring managers receive so many applications that automated tools are employed that rely on keyword searches, dumping qualified candidates and selecting the applicants who pick the right keywords rather than having the right skills. So, how do we fix this?

Cost must match benefits

One of the core challenges is that hiring for technical fields requires a technology-savvy recruiter. This isn’t just someone who knows the difference between Java and JavaScript, but someone who can tease out a candidate’s ability to think logically and translate requirements into systems and applications. The cost of a failed hire can be quite steep, not only in terms of salary and benefits, but when combined with the cost of the hiring process and formal and informal training, can easily exceed six figures per candidate. Yet, hiring entry-level IT staff, some of whom will ultimately be our next generation of IT leaders, is usually left to the lowest cost, least effective process.

At a minimum, we need a collaboration between IT and HR that ensures the right candidates are making it through the initial HR screen. Rather than spending 30 seconds vetting the job description HR wrote, randomly sample a dozen applications, including a mix of rejected and accepted applications, and ensure that the first filter in the process is working effectively. If it’s not, and the position is of any importance, consider hand-reviewing applications. While a stack of résumés may seem daunting, you can likely separate the chaff from the wheat with a minute invested in each résumé. Even with a few hundred applicants, isn’t selecting someone who might spend years in your organization worth an hour or two in a conference room with a couple of people on your team?

Check your job description

The lazy way to hire IT resources is to create a laundry list of technologies and assign an arbitrary number of years’ experience to each. Rather than taking this route, consider what problem solving skills the candidate will require. Do they need to write code in high-pressure break/fix situations? Do they need to work closely with non-IT resources and translate their needs into technology? Are you rapidly changing technical environments and need a fast learner? Use the job description to tease out these traits rather than creating fodder for an HR-driven keyword search.

Replacing the broken process

Perhaps one of the most effective fixes for IT hiring is replacing keywords and credentials with an actual technical or business problem. Case interviews are a hallmark of many companies, and cases get an unfair rap as something that’s overly complex, or that only a PhD from Harvard can correctly formulate. Whenever I interview a candidate, I take a problem I recently faced, describe it to the candidate, and ask how they’d approach the problem. No one is going to “solve” a complex business problem in five minutes, but I mentally check for the following:

  • What’s their initial reaction to a complex problem? Is panic their first reaction?
  • What questions do they ask? The line of questioning indicates whether they can quickly identify gaps in the information I provided, and how they are framing the problem. If you present a problem about a complex system integration, and their biggest concern is whether they need to use a Mac or a PC, then the candidate is probably the wrong person for the job.
  • How do they articulate their approach to solving the problem? Again, it’s impossible to solve a case in five minutes, but the candidate should be able to readily articulate the broad steps they’d take in solving the problem.
  • What background and skills will they apply to the problem? Anyone can put “10+ years of enterprise architecture” on their résumé, but it will become readily apparent whether they have skills in this area if they can’t articulate an approach to an EA problem clearly and concisely.

Some organizations have attempted to move in this direction by including coding or logic tests in their initial screening process. Done well, these can augment the hiring process and be far more effective than a keyword screen. However, the tests are often applied too broadly. If I need someone to gather technical requirements from business users, their writing, speaking, and interpersonal relationship skills are likely far more important than a logic test, and hiring for that position likely requires more in-person interviews than for someone who will be spending most of their day coding. In short, the screening process must match the position.

Doing it right is hard

Like all good advice, it may seem painfully obvious that if you want good IT candidates, you need a good hiring process. Like most things in life and work, the concepts are straightforward, yet require diligence and investment in execution. In an area like IT, where people are far more important than the boxes and wires, this investment should be a priority.

Also see:
How automation and algorithms are the future of tech hiring
Can these tech tools fight gender bias and increase workplace diversity?
Myth busted: Older workers are just as tech-savvy as younger ones, says new survey
Infographic: CIOs reveal IT hiring trends for 2016