The Generalist/Specialist hiring mismatch
Over the years, I've been involved in the interviewing- and hiring process of hundreds of candidates for software engineering positions. And while I've been interviewing candidates for well over a decade, it's something I've always felt uneasy about in some ways, given many organisations have processes that probe deeply for one skillset, while the actual job requires an entirely different set of skills. Organisations that are good at hiring might still only have a 70% success-rate in candidates becoming strong contributors, and I suspect most organisations are at 50% coin-flip territory.
Nowhere is this more apparent than in software engineering, where the interview process frequently focuses the majority of its efforts on probing a candidates expertise and knowledge of algorithms, data structures, technical trivia and specifics of a given tech stack. While proficiency in all these things are important for the job, perfect situational recall of these things is not, especially not in an age where Google, ChatGPT, StackOverflow and other tools are readily available to help us relieve having to overload our brains with specifics until the moment we need them.
Where most interview processes fall short is in probing for the ability to learn, adapt and apply new knowledge, and the ability to think critically and creatively about problems that may be vague, and how to solve them in collaboration with others. This sort of high-level problem-solving is what makes great engineers.
In practice, we interview looking for specialists, but what most organisations really need are more proactive generalists that have just enough specialization to be able to probe deeper, learn and apply new knowledge as needed.
But how do we adapt our hiring processes for this new reality? How do we probe for general problem-solving skills, interpersonal skills, and the ability to learn and adapt? I think we still need some basic screening for technical specialization and proficiency, to weed out the pretenders and fakes, but having it as the sole- or majority focus of the interview process is a big mistake.
I think we need to rethink the way we hire software engineers and leaders. In the age of ChatGPT, the algorithmic puzzler and trivia-recall quiz interview is all but dead, and I'm not sure it was ever that useful.
How do we make this change, what will the change look like? I don't know, but I think it's a conversation worth having. If you have ideas, feel free to drop a comment, or email me.