We do live team coaching for tech teams, and software trainers don’t pass our interview process.

We found out why

About a year ago, my co-founder noticed a pattern: a few candidates seemed to have great, relevant experience and we thought they would be shoo-ins for delivering live team coaching for the tech teams we work with. But none of them had passed the first stage in our interview process. We don’t struggle to source great coaches, so at first we didn’t read much into it.

But after several more months of the pattern staying the same, our curiosity got the better of us. We dug into why, searching for a flaw in our interview process.

What it revealed was something bigger: there was a dramatic difference in skill sets between traditional trainers and the ideal candidates we were looking for, and a fundamental mismatch between trainer skills and learner needs. In this article I’m going to break down where the software trainer candidates fell down, and take a stab at explaining why.

Shallow technical understanding

It would be reasonable to assume that we were nit-picking, or perhaps introducing unconscious bias to our interview process and that’s why we were continually rejecting a specific group of seemingly qualified folks. We wondered that ourselves, so I want to address it upfront with some examples (in summary, the rejections were on dramatically fundamental grounds for us):

Candidate A did not understand the difference between calling vs. creating a function in Python. This candidate was an experienced Python trainer with a stellar CV of companies and institutions they worked with.

Candidate B thought that two halves of a WHERE condition in a SQL query had to be in the same order as the columns in a multicolumn index before the index could be used.

Candidate C had never seen the super keyword in Python, and can’t begin to explain what it does.

These would all be eminently forgivable traits if we were hiring junior to mid-level engineers, but not for someone who is coaching a broad range, including seniors and leads. Their technical understanding needs to be beyond reproach — in practical terms, they must know the topic on a deep enough level to accurately and clearly answer probing ‘why’ questions. In conclusion, these misunderstandings were huge red flags for us.

When we asked ourselves why these candidates might lack understanding in the examples above, we realised that the reality for most software trainers is that they don’t need to deeply understand what they teach in order to satisfy the needs of a junior or someone new to engineering. Indeed, those learners are unlikely to notice — let alone challenge — when the holes in the trainer’s knowledge emerge.

We found that when asked to explain something that doesn’t make sense in an advanced session, traditional trainers tended to revert back to what we would call a ‘junior level’ explanation: “that’s just how it behaves”. This also makes sense when you consider what the majority of their experience is likely to be.

It’s also possible that the profile of person who chooses full time software training — rather than being a senior engineer with mentorship and coaching responsibilities — might suggest they’re less interested in the intricacies of software engineering, and more interested in the human side of teaching. After all, senior engineers with staff responsibilities have a very high market rate, and they get to enjoy both teaching and building software. If you’ve chosen to not pursue that route, it’s likely that you’re:

1. Not so interested in building software (compared to the joy of teaching)
2. Not so good at building software (i.e. you aren’t able to get a senior role)

This might explain why depth of understanding is commonly lacking — it’s either not something they’re adept at, or not something they’re passionate about (otherwise they’d be doing it)!

Additionally, as a direct result of being a trainer rather than a software engineer, it’s likely that they haven’t built things in a while, meaning they’re more likely to struggle with questions about real-world application of a feature. We found in our interview process that while trainers can describe how a feature or function works in theory, that context of how it works in practice was lacking.

Awkward power dynamics

We don’t just care about the depth of technical understanding someone has.

Traditional trainers generally tended to have great empathy and communication confidence and clarity. However, when running a demo coaching session with senior developers, they struggled with communicating appropriately with their choice of words and their tone of voice. These implied a big discrepancy in abilities which came across as condescending, particularly when explaining or introducing a topic. This tone issue may simply be the product of habit — they’re used to talking to people re-skilling in bootcamps, undergrads etc). But the effect was that they sounded like they were talking to inferiors rather than peers. For mid-career software engineers, a more appropriate dynamic is peer-to-peer respect with transfer of specialist abilities that one person has, and the other does not.

A knock-on effect of the more traditional classroom power dynamic is that traditional trainers tended to respond badly to being challenged by learners on a deep question they didn’t know the answer to, and would readily get defensive about their knowledge. This is very understandable when you think about it from their perspective — especially if their experience teaching has been primarily in an environment where the teacher has automatic high status and they aren’t used to being questioned. Junior engineers are unlikely to have the knowledge or context to challenge a teacher in a way that would reveal a hole in their understanding. By contrast, people who work as software developers are challenged constantly as part of architecture, design and code reviews — they’re (for the most part) used to explaining their thinking and learning new things through the discussion.

Unable to live debug

We found that software trainers really struggled with the live debugging part of our interview process. This is a skill all senior engineers need, but one that traditional software trainers basically never use.

A big part of our coaching experience is looking at learner code and spotting bugs and mistakes as they tackle challenging problems hands-on. That’s why we built our app to make it easy to view Github-style diffs in learner code and respond to learners individually.

Traditional trainers might not look at code written by learners at all, or only look at code produced by juniors — who go wrong in obvious ways that are easy to spot. Experienced engineers can do things that *work* but are less efficient, or that will introduce future issues in specific edge-cases — it’s a subtler and more nuanced skill to spot those, but that’s what our coaches need to be able to do — and in real-time during a session.

Lack of (recent) real-world experience

Experience in building stuff, seeing it break, and working out how to fix it is what makes experts.

Our learners often have questions about real-world application:

“Does this come up a lot?”

“What are the edge cases?”

“When would you use it?”

“When would you use it instead of using some other alternative?”

There’s an expectation that learning goes beyond just knowing what the feature does in theory. Our coaches need to be able to give clear real-world examples for when something is used or not, and why.

If a software trainer has been training full-time for a few years, they run the risk of already being out of date on the real-world application of the technology they’re teaching — even if they have built with it in the past.

In Conclusion: Our coaches work… because they aren’t trainers

What we’ve learned from our interview process is that mid-career technical folks have different, and hitherto uncatered for needs than those just entering the industry, and so they need something altogether different from training, and from trainers — whose skill set just doesn’t cut the mustard.

We actually think they don’t need training, or trainers! They need coaching, and coaches — and those things are fundamentally different.

They don’t want spoon-fed solutions, they want the coach to spot subtle misunderstandings and guide learners towards solutions — so that they can ultimately emerge from sessions able to apply what they’ve learnt directly back to their work.

This is actually pretty good news for us because the number of experienced engineers in the world dramatically exceeds the number of software trainers.

We still interview trainers, and we believe that some can and will be amazing for us one day — but so far, 100% of our coaches are full-time engineers who love helping people learn on the side.