Hiring Like The Life Of Your Team Depends On It (3/5)

What underpins this value is that slowing down is not an option and moving faster is a core responsibility of a team.

Growing is a Risk: the Fox and the Henhouse

The Problem with Quality

The ratio of time spent building / fixing is arguably the only useful measurement of quality in a team. An ideal value for this quality metrics would be much closer to 80% than 100%.

At 100%, the team is losing its sense of pragmatism. Its ability to fix stuff is dulling. And most likely, it is spending too much time finessing its software to the detriment of moving at pace for the business. This is the trap of engineers seeking their own glory. The team, usually highly principled, divides practices in two categories that never overlap: the good and the ugly. The team talks a lot about it, more than business value or time to market.

They believe in collaboration but don’t realise they never practice it. Same thing with hiring. They’re willing, but the right candidate hasn’t showed up so far. Somehow, the rest of the world isn’t good enough. Past attempts have proved it would pose a serious risk to their immaculate codebase. The rest of the story goes like this: An event makes the team look around. In utter shock, the team realises no one cares about their work. The ungrateful idiotic world has moved on. This is the pitfall of puritan engineering.

This is death by poor product ownership, and more precisely poor customer focus. It is always brutal. Product ownership is a complex domain of responsibilities. It’s all about the team having skin in the game. We align. We commit. We take accountability for the value delivered. We seek feedback. It’s amazing.

If you fear these are symptoms you can see in your team, the risk you need to take is to hire people with strong customer focus, who deliver results without resorting to puritan engineering. Yes your quality bar may drop slightly but trust me it’s temporary. The overall team is too quality-conscious for this to be a serious threat. Shifting the team’s culture from pure technical quality to materialised value is the right thing to do.

Team Fit, How an Entire Industry Chickens Out

If you can be more flexible than you could think with hard skills, it’s not the case with soft skills. Unfortunately those are tricky. That’s why we need our values. They are just a basis. We need a definition of what good looks like. And then we need to know how to find them in a candidate. Something much less black and white than verifying the solution to an algorithmic problem. This is where I believe the whole industry has gone crazy. It’s like most it’s given up.

Let me tell you about what I call hygienic interviewing. Once a year, I just take one of this LinkedIn spammers up on their job offer. And then I try to go as far as I can in their interview process. I never intent to join¹. Over the past 4 years, I have done about 50 interviews with around 15 companies: Google (11 interviews, all but one purely technical), Facebook (failed at stage 2, only technical interviews, I was too slow), Palantir (7 interviews, all but one purely technical), etc.

I find it fun but the reason for my dedication is the huge gap I see between what makes a great member of an engineering team and what is assessed for in those interviews. Therefore, you can’t really assume that doing a good job at one keeps you sharp for the other. Hygienic interviewing is my way of training. In those interviews, all that seems to matter is pure technical excellence, solving and coding. The former is secondary and often surprisingly subjective, the later is almost entirely irrelevant. Let’s talk about that.

Jeff Bezos likes to say he doesn’t care about people being fast or smart, what he looks for for his team are people who are right a lot. It’s a core leadership principle in his company, Amazon. That’s right, the man who created the fastest delivery service on earth doesn’t care if his engineers are fast individuals. And he is right. In our job, the speed element is delivered by the machine, the team as a whole, its processes, by thinking big and out of the box, by cleverly outsourcing, etc. Your ability to write a delete function for a red-black tree correctly, and in less than 30 minutes is worth a t-shirt at best but certainly not a salary.

One hygienic interviewing I took in 2016 shows how technical excellence can be secondary and surprisingly subjective. I was asked to write a CLI in Scala interacting with Marvel APIs to list names of superheroes. The test statement was pretty much that, a one liner. I had 2 hours before my solution would be reviewed. I did that and I was rejected. Reason for rejection #1: I didn’t use a dependency injection framework, therefore my code couldn’t be tested. Reason for rejection #2, I had chosen to use Circe to deal with JSON and that was deemed as “not serious”. Reason for rejection #3, I didn’t use a cache therefore my code wasn’t “production-ready”. I listened to all that respectfully, then I thanked everyone and took off. That’s a good outcome for an hygienic interview.

You get your training done without getting emotionally attached. If you win their hearts, you have to break those by declining their offer politely. Now do you see what I mean by “often surprisingly subjective”? My code is far from perfect and there would have been reasons to reject it. Some of those reasons, I mention in the README. Yet none of the given 3 reasons are one of them, reasons that perfectly illustrate the 3 fallacies I have seen over and over in the art of making great engineering hiring decisions. This will be the focus of the next post.