On tech hiring: lessons from the peloton

Given my love of both software engineering and cycling, I thought it would be an interesting experiment to draw parallels between them, specifically in the context of hiring, and with regard to skills and teamwork.

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

In cycling, a race is made up of stages. A race may take place over one stage (e.g. a ‘Spring Classic’ like Milan-San Remo), or many stages (e.g. a ‘Grand Tour’ like the Tour de France).

Let’s look at the categories of rider in a road cycling team:


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.


General Classification (GC) Contenders

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 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?

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.

Software engineering nut. Cyclist. Musician. Dog lover