My 3 Biggest Hiring Mistakes

Photo: Wikipedia

As a community, or at-least on my twitter feed echo-chamber, we do love a good moan about broken hiring processes. Often for good reason and to hilarious effect. I’m not saying we should stop doing it, although once I’ve finally worked out how many golf balls you can fit in a Boeing 747 maybe I’ll change my mind.

But forget all that — I want to turn the tables. I want to discuss what it’s like to be the interviewer, or more specifically, some of the biggest mistakes I’ve made when it comes to hiring people… or attempting to.

1. Wholeheartedly trusting recruiters

I’d seen endless C.V.s, interviewed numerous candidates and felt completely hopeless. Finding someone who could join our team and make an impact seemed impossible. We were in a remote location and the blend of skills and experience we needed just weren’t available in the local market. I love hiring and training people, but it wasn’t an option.

So we took on another round of C.Vs from recruiters. I worked with my team to find grains of hope in this new batch of applications. Encouragingly, a few showed signs of promise so we excitedly sent them the coding challenge straight away.

Previously, we received shockingly-bad code samples. Not subjectively-bad, objectively-shockingly-bad; test files with comments saying “test to go here”, 500 line scripts without any kind of model. It was a very simple challenge, designed to weed out those who couldn’t write basic code.

But in this new round of code samples we found a glimmer of hope….

One solution was actually well structured. It actually contained a few classes and methods so we could see what was going on. It even contained test files with working tests. I passed it onto my team and asked them for their thoughts — they were all in complete shock, too “It has classes. It has tests. Hire this person quick!” they said.

We invited the candidate in and we couldn’t wait to meet him. We were going to chain him to the desk so he couldn’t escape. But the positivity didn’t last long…

As we sat down and I explained we would be doing pair programming together on his code sample, he gave me a look of disgust. As we then paired on some basic activities and I asked questions about code and his opinion, his looked like he wanted to smash my head off the wall. He looked disgusted that I wanted to code with him, arrogant that I dare question his code or challenge his opinions, while his responses were short and snappy.

After the interview, I convinced myself that it was all in my head — my poor judgement of character. Perhaps I caused him to feel that way. It was right at the end of the day; maybe I was tired and coming across a little grumpy myself. I convinced myself that my first impression was wildly inaccurate.

When the recruiter came knocking asking for feedback, I was completely honest. I explained to the recruiter that my first impressions were that he was very arrogant and would struggle to work in our environment. But I openly explained to the recruiter that maybe I had misunderstood this person who had shown the best coding ability of all of our candidates.

When the recruiter replied with: “The candidate said he felt nervous and wasn’t able to communicate clearly. He thoroughly enjoyed meeting you and would be a great addition to your team”. I felt so relieved. It really was my poor interviewing skills and poor ability to judge this candidate’s character.

The recruiter wouldn’t be telling us what we wanted to hear because they stood to make a profit, would they? And I wouldn’t be foolish enough to buy into it, would I? Of course not!

So we hired him…

2. Too afraid to let go of a bad hire

That awful first impression I had, turned out to be uncomfortably true. The developer I interviewed was the developer we hired.

He hated everything. He hated our agile ways of working. He hated our testing strategy. And boy did he absolutely hate me. However, it was ultimately my decision to hire so I tried to do everything possible to make it work. Colleagues were telling me to get rid of him, but I pleaded with them for more patience while I made it right.

Things didn’t get better, unfortunately. He used to arrive at stand up with a “can’t be bothered” attitude. He would unashamedly say “can’t remember what I’m working on”. He would refuse to work on things. He would complain endlessly about coding standards and tooling, but when asked for his opinions would provide absolutely nothing. He would spend days doing the wrong thing and not care about it.

I looked bad: I hired this developer. I chose to keep him in the team. I chose to persevere in trying to find ways to make him happy whilst he arrogantly disrespected me. People saw me as foolish and stupid. I bought this pain into the team and I seemed to be happy with it.

My intentions were 100% genuine, though. It was hard to find capable candidates — we may not be able to find another so easily. I didn’t want to be seen as cementing my place in the team — deliberately rejecting candidates so I was impossible to replace and could squeeze more money out of the organisation. And I made the call to hire this person — it was my responsibility to help him fit in and be productive.

Talking didn’t seem to work, though. In fact it got so bad that I wrote him a letter, explaining how I felt whilst politely warning that one of us would have to leave if we couldn’t work together.

I also spoke to colleagues from previous companies and I even shared my feelings with existing colleagues asking for their advice — everyone was telling me the same thing; if he’s still toxic after months of your best effort, the situation is not going to get any better. If you can’t talk to him and discuss the problems, you have no chance of fixing them.

But I didn’t have the courage to take their advice; I was trapped by the sunk costs fallacy.

Shortly after, I chose to leave the company for another reason. Perhaps when I left he was happy. Perhaps it was actually all my fault. Or perhaps next time I won’t be foolish enough to let recruiters tell me what I want to hear.

3. Believing personality is enough

Onto a different organisation and a different story, but still plenty of poor decision making to share with you. Surprisingly, this time I found someone who was great, easy to get on with, and everyone loved. So what could possibly be the problem?

The problem was that this candidate’s technical skills weren’t strong enough. His background was different, so I looked beyond some of the obvious anti-patterns in his code sample and his fundamental misconceptions about agile and continuous delivery.

Back then I believed anyone could be a highly productive programmer in the right environment. I believed that with enough time and patience anyone could do this job as long as they were easy to get along with and had an interest in continuously learning and improving. This developer certainly ticked those boxes, so I told senior management I wanted him in my team at all costs.

Jim Carrey is hilarious, but maybe we should still ask him to do the coding challenge first. Photo Flickr

Having him in the team was actually great. He made the office environment 1000% better. At-least 1000%. You could argue that motivation boost alone was enough reason to hire him.

As the months passed, though, his code didn’t really get much better. All of the passion he showed in the interview didn’t follow him into work each day. He didn’t make an effort to understand this new programming language and he wasn’t correcting some of the mistakes the rest of the team were pointing out to him. We were spending a worrying amount of time fixing his code.

Other people in the team started to become very annoyed. There were frequent clashes over this developer’s poor habits. All of the positivity he initially brought to the team soon became a negative. And once again, my reputation was taking a battering as people from all over the organisation could see people in the team arguing when I wasn’t there.

But this was my fault. I believed that we could help this developer reach the same level as everyone else in the team. I knew his skills weren’t sharp, but I believed that anyone could be a good programmer if they had the right mindset.

It was a poor decision that wasted a lot of time and money. I won’t be making the same mistake again but I do still strongly believe that hiring based on potential and attitude can lead to hugely positive outcomes.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)