Hiring Like The Life Of Your Team Depends On It (4/5)
What underpins this value is that slowing down is not an option and moving faster is a core responsibility of a team.
The Three Fallacies of Software Engineering Recruitment
Conflating Elegance and Quality
Let’s ponder this: no use of dependency injection framework implies untestable code. I am sure you already see the issue. Well, issues. But do you see where the team’s reasoning went wrong? They don’t assess the technical proficiency of their candidates, they assess the elegance of their solution. It’s totally subjective.
Now not working with someone because he/she has incompatible sense of elegance is arguably acceptable. But here, have we proven that the team and the candidate suffer from such incompatibility? Not at all! Remember, the problem statement was a one-liner. If one really wants to assess for compatibility of elegance, one needs to supplement that statement with a manifesto of elegance of some sort:
We believe in testable code. And we believe the best way to achieve this is by using a dependency injection framework such as sindi1.
That’s right, if you tell me this, my solution will be radically different. I may even decide to never give one and walk away but isn’t that the whole point of a hiring process? Elegance is the icing on the cake. I have mine, you have yours but that doesn’t say both can’t meet and function harmoniously. It may just need a little push.
As an engineer, you should be infuriated to see randomness ruling your hiring decisions. If your team has a strong sense of elegance, that’s great — but don’t fool yourself by thinking there is any universal truth to it. There is none. If that can be a cause for rejection, then make sure you’re absolutely transparent about it. And if you reject someone on that account, then say “rejected for incompatible sense of elegance: in conflict with shared principle #5”. Being clear on the line between quality and elegance is integral part of being a mature team. Done properly, this hiring technique will make a team aware over time of the weight and complexity of its definition of elegance.
As per assessing the raw quality of a solution, it boils down to those three disappointing questions:
- is it a working solution?
- does a valid rationale exist for each of its design decision?
- could my team evolve this solution and take it to the next level?
Any other consideration is nice-to-have and subjective. Elegance by definition is nice to have. I strongly recommend you be very explicit about those 3 questions in your feedback on technical tests during your hiring.
Not Being Prepared for the Unfamiliar
Now let’s review the second rejection reason I received that day: Scala JSON library Circe was a bad choice. It could well be that this perception explains why the Circe project decided to put a list of prominent adopters as the first section of its README. Nevertheless, it’s still an impressive list, enough to invalidate the weak “bad choice” argument.
At the time, Circe was still fairly new. Even though Twilio and SoundCloud were already on that list, handling Json in Scala was still dominated by libraries like Play, Spray, json4s, etc. But not my CLI. I had chosen the unfamiliar Circe. To my judges, it wasn’t easy to articulate but that left them uneasy. Go away weirdo.
I have always had a huge problem with teams hiring “likeminded people”. Remember the team of puritans and my advice for them to hire someone with stronger customer focus. Yes it is a surreal advice, asking an entire team to get out of its comfort zone and willingly go under the influence of their latest recruit. But sometimes, your life depends on it.
So one more question to your team: what weirdo does your team need to get its daily dose of healthy discomfort?
Production Readiness and Interviewing…
Please, please don’t let the candidate believe you actually think they can deliver production-ready solution from scratch in few minutes / hours by working on a dummy exercise. Production-readiness isn’t just down to code. It’s about an entire ecosystem whose weakest link defines the robustness of the whole thing. CI/CD, NFT, monitoring, logging aggregation, environment management, DC topology, it’s the symbiosis of all of this that makes for a production-ready software. That’s why no coding exercise should pretend to assess that aspect. And that’s also why at the department level, we should aim at growing this symbiotic ecosystem as a collaborative effort. Because it’s hard and it’s a huge investment.
That being said, when it comes to talking with the candidate about their solution, it’s a great avenue to explore:
- What would you need to make this code production-ready?
- A customer complains about flaky behaviour, how would evolve your solution to make it easy to investigate such an issue?
- Walk me through a possible failure scenario of your solution, and how you would improve it to make it reliably self-recover.
We have cleared utter nonsense that has spread across our industry. We can now think straight about a well-designed hiring process. This will be the topic of the next post.