There is a better way to match candidates to job openings.

Less than 8 minutes, 1953 words, 4th grade

Key takeaway

The single, junior-senior axis on which we tend to rank developers is a poor choice. The “senior” role is not an extension of the “junior” role; it is an entirely different animal.

A better way to compare developers is with a set of axes. Each represents one the various skills required in that role. These axes form what we call an n-dimensional space.

And with just a smidgen of math we can calculate the distance between two points in this space. In short, we can determine best fit.

Humans like to keep things simple. Binary if possible: good or bad, smart or simpleminded, tall or short, black or white, fast or slow.

When pressed, we will admit to a continuum. There are degrees of good and bad and few things—if any—are entirely good or bad.

We apply this same approach to tech work. Witness, for example, the ubiquitous categories of “junior”, “intermediate”, and “senior” developers. As if these skill sets live along a linear continuum.

They do not.

Everything is contingent

There is no such thing as a “great” developer or a “lousy” developer. There is only one thing that matters:

FITNESS

Is the developer fit for the task weʼve assigned?

Some developers are fit for many tasks, others for very few. But it doesnʼt matter as long as they are fit for the task we are asking them to do.

Take a bespoke dev with zero people skills. Put them in a coaching or leadership role. They are going to suck mightily at it. They just want everyone to leave them alone to solve puzzles. But they solve those puzzles better than anyone else on the team.

So why would you put them into a role that demands talents that they not only lack, but also disparage? Why not put them where they will do awesome work?

In contrast, our typical commodity coder will be miserable if you put them in a role that requires them to invent new features. But if you put them as a mentor working with commodity devs, they may well excel.

Life in n-dimensional space

We are all familiar with one-, two-, or three-dimensional spaces. One is a line, two is a plane, three is a solid.

This is the limit of our ability to visualize dimensions, as we appear to live in 3-dimensional space. But that is no reason to limit the possible number of dimensions.

We can talk of dimensions beyond our typical three of height, width, and depth. We can group these higher-dimensional spaces and call them n-dimensional. Here, n is any integer greater than three.

So we can have 4D, 7D, or even 11D spaces. We are not limited to 3D. And just as we can measure the distance between two points in 3D space, we can measure the distance between two points in 12D space. Even if we canʼt visualize more than 3D.

Wait! Donʼt panic. This isnʼt actually difficult at all. All it requires is that we define the axes and then plug some numbers into a formula. Itʼs not even math. It is merely arithmetic.

The formula involves multiplying some numbers by themselves — “squaring” them. Then we add them together, and then “unsquare” the sum using the “square root” key (√) on your calculator. Easy peasy.

But keep reading. You wonʼt need your calculator after all.

Junior-Senior is a worthless metric

Never mind that junior and senior roles are so poorly defined that they create more confusion than they dispel. Never mind that they are more related to prestige and/or pay than any particular skill set. Junior and senior simply donʼt belong on the same continuum.

Continua measure degree.

I repeat: the point of a continuum is to measure degree between two poles. If “junior dev” is one pole and “senior dev” the other, then this implies that the difference between a junior dev and a senior dev is one of degree.

That is, juniors and seniors do the same things, but one does them better. The implication is that a junior dev becomes a senior dev by “junior-devving better”. Not by learning orthogonal new skills.

But now look at job descriptions for so-called senior developers. They include skills that are not only not required for junior work, but also absent. If not outright discouraged.

For example, senior devs often act as mentors, coaches, trainers, leaders, etc. None of these is the purview of a junior dev.

As I say, these skills are orthogonal.

But when it comes to hiring, there is really only one continuum that counts. It ranges from “get lost” at the bottom up through “I guess we can live with that” all the way up to “soulmates!” at the top.

It is a continuum measuring the quality of the work done. And there is one continuum for each skill required. Each is an axis in our n-dimensional space. And each stretches from “kill me now” to “open the champagne!”

So it is not simply, can this person do the work? It is will they do the work consistently well? Itʼs about performance, not aptitude. Put simply, aptitude is necessary but not sufficient. You gotta walk the walk.

Axes to grind

So what are these axes? Well, they fall into two broad sets. The first is the so-called “soft skills”. Given how rare they are, we ought to call them the “hard skills”.

Here is an incomplete list of skills we expect from developers, especially “seniors”:

1. Commodity coding: repeating established patterns with minor variations.
2. Bespoke coding: going from blank canvas to unique new product.
3. Mentoring: helping others to define and fulfill their career or life goals.
4. Coaching: realtime feedback intended to improve performance in the moment.
5. Teaching: facilitating and inspiring the acquisition of new skills and knowledge.
6. Leading: blazing a new path and inspiring others to come along.
7. Managing: organizing activities to improve performance and achieve goals.
8. Emotional maturity: personifying wisdom, patience, and empathy.
9. Life experience: masterful pattern recognition through long practice.

These are oversimplifications and there will be overlap. Most people have more than one of these skills. Bob might be a great teacher, but a lousy mentor, while Carol might excel at both.

And no doubt there are other skills required to do good development work. It depends on the context, of course. And we can draw up similar sets of axes for testers, UX engineers, designers, architects, etc.

Then we should also add axes specific to the work required. For example, an FP axis. Or a JavaScript axis. Or an axis based on knowledge of specific company IP. The more specific, the better.

And note that all these skills are qualitatively different. Some, such as bespoke coding, are strongly biased toward innate talent. Others, such as commodity coding, most devs acquire by consistent practice.

We can also weight the axes. A showstopper skill, such as the ability to do functional programming, might have a high weight, e.g., a 1. A nice-to-have skill such as coaching might be a 0.2.

How to ensure best fit

Suppose that we set each axis to range from 0 to 100. We see that one experienced developer is a 70 on commodity coding, a 20 on bespoke coding, and a 90 on mentoring.

Another experienced dev is a 90 on bespoke coding, a 15 on commodity coding, but only a 5 on mentoring.

The question we should ask is this: Why do we think that the first dev is better than the second or vice versa? The truth is that it depends on the context.

Measuring skills in n-dimensional space: the distance from desired is 72:

No! Not the maths!

Yes, the maths.

Now weʼve located both our devs and our desired skill set in this nine-dimensional space. Note: weʼve only shown three dimensions here for clarity.

Next, we calculate the “Euclidean” distance between these two skill sets and the desired skill set. This is how we determine who is the best match for the job.

Hmmm. I like to code. So of course I coded up a calculator for n-dimensional distance. I guess Iʼm saving you the maths after all. Feel free to send me shoeboxes of unmarked bills in various denominations.

To keep it simple, letʼs imagine that we have a job that requires differing degrees of three of the above skills. And we have two candidates, Alpha and Bravo.

OK, Iʼm not very imaginative when it comes to names. But maybe we want to keep them anonymous to avoid bias. Ha!

Might look like this:

• Desired
  • Commodity coding: 25
  • Bespoke coding: 75
  • Mentoring: 100
• Candidate Alpha
  • Commodity coding: 15
  • Bespoke coding: 90
  • Mentoring: 5
• Candidate Bravo
  • Commodity coding: 70
  • Bespoke coding: 20
  • Mentoring: 90

Whoʼs the best fit? Try it out.

Drag the sliders for Alpha and Bravo to the right values (or click then use the arrow keys). You should see the raw distance from the ideal, and the score as a percentage. Lower distance/higher score is better. A “best fit” winner should appear top right.

Here we can see that Alpha has vastly greater skill in bespoke coding. But Bravo is actually a better fit for this role, 72 vs. 97 (remember that a lower number means a shorter distance).

This is because mentoring is highly valued in the role (100). Bravo excels at mentoring (90). This outweighs the difference in bespoke coding skill between Alpha and Bravo, 75 vs. 20.

But it pays to avoid being too strict about this. Any deviation from the desired skills lowers your score, whether above or below. So if the job requires 80% bespoke and youʼre 90%, then that counts against you. You are “overqualified”. But in reality, that small difference is likely not significant.

But if youʼre wildly overqualified, well, that might be a problem.

The same is true for underskilling. A small difference might not matter, but a large one will. Right now, the calculator is linear. But we can square the distance from desired to make it non-linear. Then large differences will count more than small ones.

You can select the “non-linear” option on the form to see the difference.

You can also weight axes. Is bespoke coding only half as important to you as commodity coding? If so, then set the max value for bespoke coding to half that of commodity. For example, 50 versus 100.

Oh, the things you can measure!

We can do much more with our n-dimensional distance calculator.

How about self-evaluation of progress toward a set of goals? Or matching team members such that their skills match or complement each other? Thatʼs a great way to choose teams.

Or replace the tired left-right political spectrum with something measuring many different aspects. When you break out half a dozen axes, then you start to see why the extremes of “left” and “right” sometimes seem similar. But itʼs not a “horseshoe”. It is n-dimensional space.

(This is a great way to annoy your friends and family.)

Remember, this tool is a guide to visualization. Donʼt overvalue it. When hiring, the only truly effective method is to put people to work on a trial basis. We mean a short-term contract. Once you get to know them, then you can determine if and where theyʼll fit in your organization.

And you can get a better feel for where they sit on each of your key axes.