A few years ago I took part in a working group for a large company I was working for. In a highly competitive market, especially at the time, identifying senior developers – specifically talented ones – was a big problem. Even more so for a company that while profitable and stable wasn’t exactly the first one developers thought of.

There are many common ways to evaluate a developer. Often coding exercises are employed but those are more often for people just starting out so you can evaluate that they have the basic skills for the position. Puzzles, like the ones Google has used, can help to discern how someone thinks about and approaches a problem – “how many X can you fit in Y” for example. 

My argument at the time was that if you’re trying to find a senior developer, maybe this wasn’t the right path. While it is possible to have say 8+ years of experience and still not be a very good developer, I didn’t think a coding exercise was going to help us here. Especially if you’re looking for a strong, skilled developer. There was a real risk that if we asked too much of them or bored them, they’d walk away because they had so many options. So how do you balance that trade off – not pushing away desirable candidates but finding out enough to feel confident in your hiring decision?

So we started with the question: what are we really looking for when we say a senior developer? For example imagine you have 3 levels – beginning, intermediate, and advanced then how do you define when someone crosses over from one to the next? While years of experience is important, it’s not the best metric. I’ve met developers with 2 years of experience that I trust much more than some with 20 years of experience. So we started to tease out what we really meant and came up with several metrics.

1. Experience. While it’s not the most important, it is important. Mainly in that over time you see different ways to solve problems, more importantly the wrong ways to solve them. You learn from mistakes, not successes. Often one thing that makes me trust a developer more is when they are presented with a problem their first instinct is not “how do I solve this?” but “should I solve this / what is the real problem we’re trying to solve?”. 
2. Identifying complexity. This is important in grooming to make sure you have tickets that are of reasonable size. But also in understanding that everything is a trade off – so are we making the best one available? It’s also spotting those things that seem simple at first glance, until you start to pick them apart. Something that builds trust with me is when someone asks probing questions that cause others to think beyond the surface and go something like “oh, that’s interesting, yeah what about X? Or what do you expect when Y happens?”
3. Communication. Think Reddit’s “explain it like I’m 5”. Can they break down complex, technical problems and solutions into something digestible to non-technical folks? Can they ask the right questions to make sure we both understand and actually address the problem? Can they tease out expectations? Can they mentor and level up other developers through pairing and code review – guiding them to solutions and not solving it for them?
4. Technical review. Can they help non-technical people list out technical requirements for tickets? Can they understand dependencies on other libraries or teams? Can they spike on a new library, plugin, etc to understand the solutions and drawbacks it offers?
5. Humility. Can they take accountability when they make a mistake or bug? Can they show grace to others when they do the same? Can they keep their ego in check – like using a library that does most of what we want instead of just immediately writing a new one themselves? Can they solve only the problem at hand, not future problems we may never get to and which will only add complexity to the code base?

With all that in mind one of my favorite suggestions was that instead of presenting a candidate with a coding exercise we give them code to review instead. This would allow us to see what they focus on and ignore. Whether they identify problems we expect, or ones we didn’t think about. Give us an idea of the tone and how constructive the feedback they might provide is. It’s more like an essay question instead of a multiple choice. As I said before, can they guide instead of tell? 

An article I read that stuck with me talked about something along the lines of “it’s not about making every review be an A+, it’s about improvement. Making a B into a B+, making a C into a B. Etc.” That really struck me as someone who can be a bit of a perfectionist and have unreasonable expectations of myself – it’s important to not push that on others, only to help, to teach, to foster learning, and most of all to be kind.

We’ll always find ways to improve on the code past us wrote as one of my favorite webcomics lays out expertly. “Perfect is the enemy of good” after all.

Finally, on hiring in general I saw something interesting on Hubspot that they do some version of near the bottom of most of the developer positions I saw there. “We know the confidence gap and imposter syndrome can get in the way of meeting spectacular candidates, so please don’t hesitate to apply — we’d love to hear from you.” with links to articles about what they mean by “confidence gap” and “impostor syndrome”. But I thought that was a really interesting way not to drive away quality candidates and be inclusive.