There’s a contradiction in the IT industry:
- There are software developers struggling to find a job
- There are organizations struggling to find software developers
When confronted with this contradiction, some say, “well, yes, the technical interview is challenging.”
But that doesn’t make sense.
If companies are struggling to find developers, then interviews ought to be easier, more forgiving, not harder. As the saying goes, “beggars can’t be choosers.”
Part of the problem is that organizations are too specific with their search criteria, but there’s an even bigger problem: most organizations invest little in developing their developers.
When I say, “little,” I mean relative to how much time and money they invest in finding the perfect candidate. The reality is that no interview process or technique will ever be perfect. The industry already tried brainteaser interviews. They didn’t work. We also know that coding interviews don’t work either. Despite constantly trying to refine interview approaches, we don’t get significantly better. In fact, I’m not convinced that “fixing” interviews is the answer. An interview will always be just a snapshot of a person in a moment in time. That can never offer an accurate picture of a good developer.
Let me put it this way: if you can truly pass an interview by preparing for it, then it’s a failure of a filter. The point of an interview is to assess you — the real you; not some fake persona who memorized a few algorithms and sweet-talked their way to charm the interviewers. If you memorized some facts about data structures to pass the interview, and forgot about them after, then how important were those interview questions?
Software development teams are like professional sports teams. The latter spend time drafting young players out of college and minor league systems just as the former recruit from campuses. The latter seek out free agents, as the former searches the job market. The key difference is that while professional sports teams invest much in player development, software development teams do not (generally). Even when asked to do so, developers are often asked to self-study on their own in their own time — assuming, of course, they’re not inundated with crunch work, which often happens. Learning just isn’t a core (enough) part of many IT business cultures — to the detriment of those organizations.
When companies do hire a star player, the opportunity is often wasted. Because they’re stars, they’re usually swamped with work, leaving little time for mentorship. Organizations can devote part of a star player’s time to mentor and train others to cultivate new stars within the organization. This isn’t even a radical idea. Apprenticeships in skilled trades exist for a reason. Unfortunately, even when mentorship is suggested, it’s often flippant; like, “give them a hand when you have some free time (in your busy schedule).”
Organizations must understand that software development requires skills (e.g., coding, communication, design, etc.) Skills can only improve with constant, deliberate practice, and constructive feedback from those who seek to uphold the highest standards. This is key to the growth, and development of a software developer. This must be a daily part of the job, but is seldom the case, especially in organizations frantically rushing deliverables out the door, and those who see developers as nothing more than interchangeable code monkeys. Code reviews aren’t just quality gates, they’re supposed to be learning opportunities.
Some believe that the shortage of developers will be resolved once everyone attains code fluency.
I disagree.
The current “shortage” is not due to a lack of people with code fluency; otherwise, companies wouldn’t be struggling to find developers. It’s because there is a lack of candidates who qualify for each position. One contributing factor is that many developers lack time devoted to improving their skills on the job, but that need not be the case.
Instead, consider if every company invested more in “player development,” there could be more qualified candidates in the job market. Maybe, then, companies could afford to spend fewer resources searching for the perfect candidate as the next developer they find may, very well, be good enough knowing that they will continue their growth within the company. Of course, companies must also loosen their search criteria. If a developer has good fundamentals and can learn quickly, the languages and tools they know are far less important.
It’s time for organizations to waste less time fiddling with an interview process that’s not going to get much better and invest more time developing the developers they do have. It benefits the organization, it benefits the developers, and ultimately, it benefits society. Win-win-win.