The stereotypical technical interview process is broken.
Those who know me well will attest to my views on this subject matter! I’m hoping the parallels I’ll draw with cycling will demonstrate a degree of balance to my (usual) argument. I don’t intend to provide a completely bulletproof analogy, instead do just enough to plant a seed.
An introduction to the pro peloton
The professional cycling peloton is made up of highly skilled, elite athletes. Road cycling is a surprisingly complex, tactical sport that requires advance planning, strategic thinking and a pool of riders in your team — yes it’s, a team sport — with a diverse range of complementary skills. It’s not just about who is the fastest rider because fastest doesn’t have a single meaning in the context of road cycling.
Let’s look at the categories of rider in a road cycling team:
A sprinter trains specifically to have explosive power over short distances. A sprint typically happens at the end of a (fairly) flat stage, and sees the sprinters from each team competing individually to win that stage. The power output of a top class sprinter is, whilst extraordinary, only short-lived, and so the raw excitement of the sprint is reserved for only the last kilometre or so, a tiny fraction of the overall length of the stage.
Whilst their fast twitch muscle fibers are awesome for explosive, short-lived sprints, they’re no good for the gruelling endurance demanded by a significant climb.
A climber is a rider who trains hard to condition the endurance supporting slow twitch muscle fibers required to sustain a consistently high power output over an extended period of time. And they’ll have targeted their training specifically to tune for extreme performance when climbing hills and mountains. A peak performance climber rapidly climbing a mountain (such as Mont Ventoux) appears to transcend the limitations of human performance; it’s a wondrous sight. However, those slow twitch muscle fibers aren’t too useful for sprinting .
General Classification (GC) Contenders
In multi-stage races, especially the pinnacle Grand Tours, a team will field their out and out team leader, the rider they believe has the best chance of winning the overall general classification, i.e. the race. GC contenders are a very rare breed of athlete — their extreme athletic capabilities are a consequence of more than just commitment and dedication to their sport. I won’t go into detail of VO2 Max here, but, suffice to say, some people are just born with a greater potential for reaching extreme levels of performance.
GC riders can sustain high levels of all-round performance over the course of many consecutive days or weeks in the saddle. The very best GC contenders are superb climbers, but they must also be extremely proficient at time trialling. They’re unlikely to be winning a sprint any time soon!
A domestique is a rider deployed by his or her team to support the team leader. Domestiques are highly talented all round riders; although, like GC contenders, it’s necessary for their abilities to lean heavily towards endurance. They will typically lack the ability to sustain the levels of performance required to win a multi-stage Grand Tour.
A domestique will often sit close in front of their leader, carving a nice slipstream through the air, allowing the leader to conserve energy in preparation for a stage defining mountain ascent. Note: we’re barely scratching the surface of strategy and tactics here! We can, though, say for sure that it’s the domestiques — the ultimate in unselfish team players — who hold the power to make or break the overall success of the team.
Drawing a conclusion, then, we can say that cycling is very much a team sport, and a team requires a mix of variedly skilled, exceptional riders in order to achieve success.
So, what’s all this got to do with software engineering then?
It’s now time to draw some parallels to the wonderful world of software engineering. On a side note, I’m sort of hoping that the reader (you) has already acknowledged where I’m headed with this post!
In my opinion, the stereotypical engineering interview — the whiteboard interrogation, the algorithm you must implement on the clock with a poker faced interviewer breathing down your neck — tends to work in favour of identifying software engineering’s equivalent of a sprinter. This is your very sharp, academically gifted, problem solver. These are the engineers who are very good at rapidly solving difficult, but generally narrow scoped, problems (e.g. identifying the root cause of particularly nasty live production issue, or solving a complex, albeit well encapsulated, algorithm).
But, these fast twitch brain fibers may not lend themselves so well to solving the broader scoped problems, the sorts of problem that aren’t solved in a few minutes or hours (e.g. decomposing complex domain models and evolving them over time within a constantly changing business context). These are problems that you may want to hire the equivalent of a climber for, whose slow twitch brain fibers are tuned to sustain the endurance required to see the bigger picture in a software product/project.
A software engineering team cannot rely solely on sprinters. In my experience, the sprinters of the software world might be relied on to write code that looks good in 15 minutes, but not necessarily so good in 15 months. Just like a cycling team, you’re going to need a diverse set of skills to support the overall success of the team.
the sprinters of the software world might be relied on to write code that looks good in 15 minutes, but not necessarily so good in 15 months
Truth be told: there isn’t one type of software engineer, just like there isn’t one type of cyclist. Of course, you always want to hire elite performers, but you’ll overlook many of them should you mistakenly assume that only the skills of the sprinter represent the skills of the elite software engineer.
The life blood of many software teams are the domestiques, those in a team who more quietly go about their business without creating all the headlines. The domestiques play a critical supporting role in a team, and their importance should not go unrecognised. Elite performance has many guises and it’s easy to miss the fundamental contributions of engineering domestiques when you have sprinters and climbers competing to take all the glory.
The life blood of many software teams are the domestiques
Software engineering’s equivalent of a GC contender is better known as the fabled 10x developer. There are some software engineers who do have that extra something, a raw, all round natural talent that extends way beyond the norm. But, like with cycling, even a 10xer may not necessarily be a great sprinter — in fact, the 10xers are more likely to be the ones with the endurance required to look after the long-term health of a software platform. The long-term health of software is about winning races, not stages.
Imagine for a moment if a professional cycling team assessed a rider only on the merits of that rider’s sprinting skills. There would certainly be no place on that team for Chris Froome (multiple Tour de France winner), despite him being one of the great athletes — and GC contenders — of our generation.
The long-term health of software is about winning races, not stages
When we’re hiring in technology, we need to invest time in identifying our skills gaps, and hire the best candidate according to those requirements. Are we looking for a sprinter? Are we looking for a climber? Do we really need to bolster our engine room with a domestique?
Team Sky recognises that Chris Froome can’t win without a highly capable— and diverse — team of domestiques around him. They carefully look to select other riders who have the skills to support their ultimate aim: to win Grand Tours with Chris Froome as their team leader.
there isn’t one type of software engineer, just like there isn’t one type of cyclist
Once you recognise that there isn’t one type of software engineer, and you understand the attributes of elite performance in each of the subtypes, then you can tailor your interview processes accordingly. It would be pointless, for example, to expose an excellent climber to an interview process designed to identify the elite skills of a sprinter (and vice versa).
One size doesn’t fit all, so don’t hinder your hiring efforts by acting as if it does.
Like I said at the beginning of the post, this isn’t a bulletproof analogy, and I think I ended up talking more about cycling than software! But, I’ve hopefully done enough to make a constructive point. I believe in the importance of building teams with complementary skills, and thus it’s absolutely necessary to make sure you avoid a one-dimensional interview process weighted towards only one subtype of engineer.