Over the years of conducting interviews and technical screens with candidates for programming positions, I've come to think that what I'm really doing is trying to set up a scenario in which someone can reliably demonstrate to me to that (a) they have a spark, the little fire inside that reacts to the unknown with useful leaps of intuition, and (b) that they can corral and manage this spark to order in the business of writing code. By reliable, I mean that if they have it, it shows, and that I'm not inadvertently obscuring my observations of this point in some way, and that I'm more or less as good at this determination in every interview I conduct. It is my opinion that coding as a profession is exactly the cultivation and harnessing of the spark first and foremost, and only secondarily the surrounding domain knowledge of how to code, of the ins and outs of a specific language or framework, and so forth.

Every challenge in programming requires the spark. Next to nothing of importance in the process of creating software for a specific task can be rote-learned and applied from a checklist. It of course helps to have a memory for many of the building blocks, and it helps to know the general standards of how things are done (what a CI pipeline looks like this year, what are the general areas to consider when hardening an application), but given the exobrain of the internet, that isn't a requirement. There are so many building blocks and so many domains that the primary skills for any professional programmer relate to competence in research and choice in an environment of uncertainty. The spark - the intuitive charting of a decent first pass path through what is known of constraints and resource - is needed at every level to avoid decision paralysis, becoming bogged down in details, or implementing the wrong approach. It is needed down at the bottom when picking the way to perform a particular nested loop or read in a file, up to the middle layers of choosing and hacking libraries, and into to the upper portions of matching the architecture of a system to the problem it is intended to solve, or picking apart the problem itself to assess whether or not it has been completely described.

Given two people who have about the same degree of factual knowledge in a given programming language, there are those who will dance their way through a task that requires them to apply that knowledge in a somewhat novel way, and those who will lumber and struggle. My contention is that the former are simply better programmers, objectively, and will tend to add more value to an organization, all other aspects of their character being equal. A further contention is that it is the same spark and the same skill in handling the spark that is used when assembling a novel twenty line loop in a few minutes as is used when pulling libraries together and critiquing the scope of architecture, or indeed in any other task in the profession.

What this means in practice is that the assessment portion of a programming interview is ideally conducted as follows. Pick a small, simple coding exercise that is unusual only in the sense that no-one will have experienced it before in the normal course of working as a software engineer, and describe it fairly vaguely and at a high level. Then watch and converse as the candidate attacks and defines the exercise using a computer, IDE, and programming environment of his or her choice, and with access to as much of Stack Overflow and the rest of the internet as they want. I've worked in enough languages to have to consistently look up the signatures of string manipulation functions and file handling because it has all blurred into a sort of pseudo-Javascript in my memory, so I'm no judge of others when it comes to what sticks in mind and what doesn't. It seems to have little to no relation to competence. Among the small exercises I've put forward: write a function that sorts a list badly, leaving at least two items out of place; produce a linked list node implementation that will sabotage the end user in an interesting, subtle, and devious way; figure out the most reliable set of Javascript approaches to cause other people's code running on a web page to fail with errors. This sort of thing is fairly easy to come up with.

How the candidates go about the process is the important thing, not that they finish. You can see the degree of familiarity and comfort with their chosen environments, and the spark is shown all along the way, in every part of addressing the unfamiliar, in every choice and the speed with which that choice is made: whether to ask questions and what they are, where to go searching for things online, how they pick the component parts to use, and how they assemble them. Obviously, given the constraints of time, these observations must all relate to the way in which the candidate applies the spark to the low-level details of programming. But I've yet to see a case in which this didn't also show up later in all of the other aspects of the profession.

It is an interesting question as to the degree to which the spark can be learned, or depends upon degree of domain knowledge in some individuals versus others. From observations of the human condition, I'm inclined to think it largely innate, or at least settled at a fairly young age. On the other hand, some of the scientific literature suggests intuition can be trained. On the third hand, many of the groups propagating that view are selling a consulting service, so it is probably wise to be suspicious. Fortunately these question are somewhat irrelevant in the narrow context of interviewing a selection of candidates to pick the best of them, as I don't have good, useful answers. Unfortunately, in the broader context of just about everything else in life, not having the answer is highly inconvenient. It would certainly be very useful to be able to reliably cultivate the spark in people who do not have it, but the fact that both software development and teaching remain as much an art forms as professions, mired in the difficulties of assessing the quality of practitioners and their impact, suggests that all of the efforts to do so have thus far amounted to little.

In this sense, interviewing and hiring is a process of mining, not crafting. I think we'd all like it to be otherwise, but there is no cost-effective way forward when it comes to reliably producing quality programmers - consider the proportion of people who emerge from software schooling absent the spark or indeed any baseline ability to produce software as evidence for that proposition. There are, however, a lot of people putting a lot of time into this issue, just as there have been for much of the past few decades. It will be interesting to see whether and how this eventually amounts to something - one would imagine that it will have to in the end, if for no other reason than the human brain will be reverse engineered, but prior to that point? The absence of world-changing results arising from past efforts imply that we should probably not be terribly optimistic about the near future efforts to expand the pool of high quality software engineers.