The Hiring Problem

In an earlier piece I asked the question among software developers, who is the best in the world? Or to put it another way, what does the model developer look like? To begin answering this question I used various concepts I've formulated in other pieces to describe how software happens. E.g. Forming the plan (a mental model of how computer systems will operate) and navigating the field of truth (deployments, versions, accounts, network conditions and more...) when investigating gaps between the plan and what is observed in a digital experience. I then made the assertion that the only general conclusion we can make about the model developer is that they meet the moment in response to the project at hand.

Part of meeting the moment is winning the confidence game with your team. The first opportunity that developers have to do this is during the recruitment process. It starts with a resource gap. There may be skills that a project demands that existing staff do not have, or demand outstrips supply for some aspect of development output. The process moves forward when there is a business case to support bridging this resource gap. Once this happens, there's an opportunity to solve or mitigate the problems of the present and perhaps also the (anticipated) problems of the future.

Fast-forwarding, a job description hits the labour market. The job description contains information about the business, responsibilities, compensation and so on. One of the key differentiators for roles in software development compared to other fields is the diversity of the pool of primitives that you will find mentioned in the section detailing the expected skill set for jobs with the same title. This follows from comments made way back in code and quality metrics, and commoditisation, among others. There are markets for solutions to problems that take place in digital spaces, but "competing" digital solutions do not necessarily attempt to solve the same problems (see also: differentiation) which may be the source of some culture shock for the uninitiated. Nevertheless, it is self-evident in the market digital products just as it is self-evident in the descriptions of roles for software developers.

It must be said that stated skill requirements in these descriptions sometimes (often?) betray a misunderstanding of the technology landscape, most obviously in "minimum years of experience" for technologies that are younger than the prescribed minimum, and less obviously for esoteric groupings of skills.

Fast-forwarding again, there is a process of assessment applied to a field of candidates who have responded to the description. Much like the profession of software development itself, the assessment of software developers is far from a commoditised process. Historically, assessment may involve any combination of the following: a walkthrough of a portfolio of work, a take-home test, a live-coding session, "what-if" questions relating to digital factories or to projects, and "what happened" questions about past experiences.

We can take the norms in processes today and see that they're aligned with forming The Plan and testing against a knowledge of primitives that are relevant to the project at hand, as well as various general software engineering fundamentals. Personally, I would like to see more tests that involve navigating the field of truth to solve an issue, which is a really significant part of the job of working on production systems.

Until next time.