Code is the Least Valuable Thing You Can Have A Job Candidate Write

You know the rigmarole: First the candidate talks about their skillset and past experience, and then they’re administered a coding exercise to verify that they can walk the walk. Generally, if they do well in the coding exercise, then things get serious and the prospective employer begins courting the candidate in earnest. The discussions become lengthier, and more team members are pulled into the interview process.

This is the de facto approach to hiring in the tech industry, and its three key shortcomings are well established:

1. Coding exercises don’t simulate real-world problems.
2. Discussions in interviews are often more theoretical than practical.
3. The emphasis on culture and fit lends itself to implicit bias.

There’s a single constraint that explains all of these issues: Time.

Real-world solutions require real-world context. Depending on the industry, context about a real business problem is something that can take anywhere from hours to years (think health insurance) of immersion before that context is fully, mentally synthesized.

We use coding exercises that use abstract problems because we don’t have time to consider all the branching logic that might be needed to address a real, tangible problem. An abstract coding exercise at least uncovers some information about a candidate’s technical abilities — a candidate can’t fake coding expertise.

We use theoretical discussions because we don’t have time to explore all the intricacies of a real world problem. A theoretical discussion at least reveals how a candidate communicates about a technical topic, and they also help to gauge a candidate’s level of enthusiasm.

We lean on intangibles like culture, fit, and gut instinct to help us make a decision about a candidate because we often don’t feel like we have enough reliable information to make a clear decision. Our dependency on intuition is often a symptom of a larger problem: the low level of meaningful, objective, classifiable information obtained during the interview process.

This isn’t inherently bad: subtle clues that don’t rise to the level of conscious awareness are encoded into intuitive feelings. When we consider our feelings, we’re considering information — we just don’t know the shape of the data. Both relevant and irrelevant data points (such as gender, ethnicity, or demeanor) are all meshed together into a single intuitive feeling. Intuition, in other words, is a black box, and while black boxes may be useful, they can also be dangerous.

So how can we gather more information about a candidate’s likelihood of success without increasing the amount of time invested in the process?

We can make them write. Not in coding language, but in human language. Why? I’ll make my case in four points.

Code is Human Communication

Code tends to be thought of as part of the same family of cognitive function as mathematics, but in practical usage, it has more in common with written communication. Yes, it’s true, it’s ultimately a chained sequence of logical operations if you peel back all the layers of abstraction, but, well, so is human language. The fact that NLP is one of the more straightforward forms of machine learning suggests that human language follows logical sequences, even if the brain’s logic is fuzzy (sometimes very fuzzy).

Unlike mathematics, coding languages typically employ words for methods and variables rather than symbols (with mathematical and logical operators being the notable outliers). Readability is an important factor in how the code is written.

And like a book or any other large body of written work, a codebase is divided into large and small segments which are, ideally, readable chunks of content.

Most importantly, there is a purpose behind code that is usually not mathematical or academic in nature. More often than not, we write code to help people facilitate transactions, track events, move through event flows, or manage their digital domain. Through our code, our applications communicate with users in the written, human language that we encode into the UI and the documentation.

Code is a form of human communication that we use to create products that facilitate human communication.

Code is the Culmination of All Communication that Precedes It

What percentage of code that’s written in a business setting doesn’t get talked about or written about in human language before it’s codified in a programming language? In my experience, it’s somewhere around 0%. First a team discusses and documents the problem, then they discuss (and hopefully document) potential solutions, and then, finally, the coders code.

And even then, coders often continue discussing the problem as they pair program, write code review comments, and discuss testing/QA feedback.

The artifacts of these communication processes are retained in requirements docs, epics, ticket/issue descriptions, acceptance criteria, and comments on PRs… but that’s only a fraction of overall communication that goes into writing code. If you sit back and think about it, the sheer amount of human communication that transpires in meetings and chat rooms in a healthy software team is enormous.

Healthy Communication = Healthy Product

What happens when a software organization doesn’t value human communication? Well, let’s start by identifying the symptoms of unhealthy communication:

• Mid-sprint realization that the scope of the work is larger than was initially understood. This isn’t so much scope creep as it is latent scope awareness.
• Repeated back-and-forth handoffs between the coders and the QA testers.
• Freshly completed projects that already need to be overhauled to meet the original business needs — even if the requirements were met as outlined. If you ever found yourself saying, “If we had understood this better before we started, we would have done it differently,” then you’ve been the victim of anemic pre-implementation communication.
• “Bugs” in the finished product that are a result of misunderstood requirements, or a failure to handle edge cases.

In other words, missed deadlines and an unreliable product.

Things tend to fall apart when team members lack context (as is often the case when contracting or outsourcing software development). If different people on the team have different ideas about what’s being built, the end product is going to bear some vague resemblance to Frankenstein’s monster.

The only way to avoid such a stitched-together monstrosity is to make sure that the different pieces of the product were designed from the beginning to be inherently cohesive. This is why Domain Driven Design has been so successful. It asserts that a successful coding product is the product of clear communication between coders and domain experts (and/or product owners or stakeholders).

Coders that thrive on healthy communication will be happy to put in the time and effort needed to understand the business goals and translate them into a workable solution, and to make sure that everyone is on the same page before and throughout the project.

But it’s not just up to coders. If your organization tries to rush through the pre-implementation phase, things are going get messy.

If your organization constrains communication to a small group and doesn’t take the time to communicate with other groups so that the entire team is equally confident in the strategy, things will get messy.

If your organization fails to communicate with itself in any way, or even subtly disincentivizes communication, things will get messy.

You Are Who You Hire

I mentioned at the beginning of this article that coding exercises are a way of making sure that a candidate can walk the walk as well as talk the talk. Well, when it comes to making sure your organization walks the walk, it all starts with the hiring process: it’s the catalyst that sparks every other process. In the same way you are what you eat, your organization is who you hire.

If you want your organization to value something, the hiring process is the best place to cement that value.

So make your candidates write a little code, sure, but make them write a description for an epic, a scenario, and a ticket’s acceptance criteria, too. If your new hires excel at written communication, so will your organization.