How to avoid toxic employees

By Najaf Ali

I’ve made clear on numerous occasions and go into explicit detail in my book about hiring, your decision on whether or not to give someone an offer for a job as a developer should depend primarily on their results in a work-sample-test.

You can buy my book where I discuss the topic at length here. Failing that you can listen to Patrick McKenzie and I talk about it a lot here. You can also read a post by Thomas Ptacek on the subject here.

I received an email recently asking the following:

Your hiring process is just a single marked test? How do you avoid assholes with a single work test, basically?

Our hiring process isn’t just the work sample test. The work sample test is there to answer a specific question: To what degree can this person perform the tasks required of the job? If they’re in our pipeline and do well on the test, we will give them an offer. It doesn’t tell us whether they will actually do the job, and it probably won’t tell us much about their personality.

For a bit of clarity, it might be worth getting specific about what we mean by a toxic employee or an arsehole developer. We’ll all have varying definitions of this, but for me it would probably boil down to someone that, deliberately or otherwise, negatively impacts the mental wellbeing of other people on the team. Here is a non-exhaustive list of things such a person might do:

Take sole credit for ideas or work that they did alongside others

Blame other members of the team for all setbacks

Be needlessly harsh when giving feedback in code reviews

Harass, threaten, or otherwise bully other members of the team

Aggressively undermine team morale and/or productivity

Continually make comments or jokes that minimise the lived experiences of others on the team

There is indeed not much we can do with a work sample test to identify behaviours like these when the candidate is in our hiring pipeline and we’re administering the test. While the test is designed to give us a good read on technical ability, it’s unlikely that the format will be a good one for assessing how “toxic” an employee is.

That’s not to say that there isn’t more we could do in our test to assess for how well they work with others. We could for example present the candidate with some code to review with some obvious problems in it, and see how they respond in their feedback. This would help us assess both their technical ability and how they give constructive feedback, with severe deductions for e.g. insulting/attacking the programmer that wrote the code.

However, this borders on interview territory and so we run into the same problems that interviews have: the candidate may not review the code the same way during the hiring process as they would during a typical work day. It’s also highly contextual, in that they may give very polite and well-reasoned feedback in a code review, but be highly toxic in some of the other ways described above.

Overall, while there’s probably more we could do to identify these toxic behaviours during selection, to me it’s ultimately not the right place to be making a decision about their personality and how well they will work with the rest of the team.

Let’s go back to the original question:

Your hiring process is just a single marked test? How do you avoid assholes with a single work test, basically?

Our hiring process isn’t just the work sample test. For a given candidate our hiring process might start years before they ever consider working with us. The hiring process in theory ends when they leave our company, but we have an alumni club and in effect have a standing offer for anyone we’ve ever hired as a senior developer to have their old job back, no questions asked, so it doesn’t really ever end.

In terms of the specific question of how we avoid arseholes with such a hiring process, I think it’s worth thinking about it in three broad phases of the employee experience leading up to passing probation at our company, and probably beyond. Each of these phases will in some form or another, filter or control for arseholery, so that while we won’t prevent 100% of arseholes getting through to a full time job with us, we will in practice have an organisational arsehole immunity that helps us deal with the problem of arseholes in some form or another.

The three phrases, in incredibly broad strokes:

Candidate sourcing

Application + selection

On-boarding, probation, and continued employment

In terms of arsehole-filtering, our goal in candidate sourcing is to minimise the number of arseholes that reach our hiring funnel to begin with.

If you rely on job boards, mailing lists, and recruiters to source candidates for you then your hiring process and management will have to be good at deselecting arseholes. We don’t typically rely on these things. We instead focus on building relationships with potential candidates directly, and hiring through mine and our employees personal networks.

For example, in a given year I will try to get to know in the order of twenty to thirty junior developers that are either looking for or in their first jobs as developers. By “getting to know” I mean I will buy them a coffee, maybe invite them to our monthly networking dinner, and perhaps have a few email exchanges, usually involving their career and how they can accelerate their progress in some form or another. I might find those junior developers by giving a talk at a code school like Makers Academy, or at a women in tech initiative like Codebar.

All of those junior developers I’m speaking to go into an internal trello board of potential future candidates. I try to maintain a relationship with them over the long term. We might hire one of them as an apprentice right away, but the real benefit comes in three to four years time, when I already have a relationship with them and so they’re happy to hear from me when I tell them we’re hiring.

By developing these relationships and seeding our candidate pool with them, I may not have 100% confirmation, but I’m likely to get early warning signals for arseholery before they ever enter our hiring funnel. We’ll only ever reach out to the least overtly arseholey candidates.

We also try to reach out to people in the networks of our current employees. No one recommends someone they never want to work with again, so this is a fairly good initial filter for arseholery.

Most of the time this yields enough candidates over the long term that we never have to publicly advertise our developer vacancies. We have a good enough set of relationships with existing candidates that we can convince a significant enough percentage of them to at least consider working for us.

However, if we do need more candidates into our funnel, then aside from direct outreach, we will try to focus on communities and mailing lists that we perceive are less likely to yield arsehole candidates. Ada’s list is one example that has been very fruitful in terms of non-arsehole candidates. The “coaches” screen on the Codebar website is another. After the first few years of operation, that’s about as public as we’ve had to go to fill our developer roles.

In terms of arsehole-filtering, our goal in the application and selection phases of our hiring process is for arseholes to self-select out of the funnel.

At some point, either because I’ve reached out to a potential candidate or because they’ve seen a job posting by us somewhere, they will begin to consider the possibility of working for us.

One of the goals of this part of our hiring process is for the candidate to be given enough information to make an intelligent decision about whether or not to apply to work for us. To do this we aim not only to over-communicate the details of the role, but to give so much information that there’s no reasonably way they could consume all of it.

This is still a work in progress, but so far we have a few bits and pieces that are focused on getting the candidate that information.

Our job spec: job-spec.markdown - This is the top of the funnel for basically all new candidates.

What I call our “non profit contributions disclosure”: nonprofit-contributions-disclosure.markdown · GitHub - Legally we can’t discriminate based on political leanings, but I’m guessing that if you’re a raging mens rights activist you will be sufficiently turned off by our contributions to women-in-tech initiatives to not bother applying.

Our consultant developer “role definition”: hbs-consultant-developer-role-definition.markdown · GitHub - I go into as much detail as I can about the things you will be reasonably be expected to do on the job here. The idea being that if you look at this document and don’t like 70%+ of what’s on it, you probably shouldn’t apply.

I would ideally like to publish a bit more about our values and expectations on our company website but at time of writing this is still a work in progress. Suffice it to say, somewhere in our material the sentence “we expect all employees to treat each other with basic human dignity” needs to appear. Wherever it appears should be linked to from our job spec.

Longer term, I would also like to put together an “employee handbook” or “new starter guide” based on all of our internal documentation and other material, but this is still a long way off. We would give people access to this as part of the application process, both so that they can self-select out and also so that they can get excited about the prospect of working with us if appropriate.

In all of this we probably need to do more to make arseholes self-select out. The strategy here has to be to make clear somewhere how we expect people to behave in relation to each other and then make sure that any candidates that want to progress to the work sample test have read the relevant material.

In terms of arsehole-filtering, our goal in on-boarding, probation, and continued employment is to detect, correct, and if required, fire for arsehole behaviour.

If a candidate passes the work sample test then we give them an offer. After that our on-boarding process begins. To the extent possible, we want new starters to be collaborating with other developers on the team, more or less from day one.

Outside of specific client requirements, we try to be fairly lightweight on process. We have fortnightly one-to-one meetings (with me and each developer), other fortnightly cross one-to-one meetings (with one developer and another developer), and then retrospectives (with everyone at the same time).

I try to do one-to-ones every two weeks, and a standard question I ask is “how are things going with developer X”, where X is each other developer on the team. I ask it in every one-to-one, and so far we’ve been lucky enough that 100% of the time, the answer is in the positive. However me asking this question means that there’s a set time and place to bring up small problems, legitimate issues, and fully-fledged grievances with other developers on the team.

This process is continual, but during the probation period of a new starter, I’m hyper-sensitive to feedback about that new starter. I’m willing to be reasonably lenient in this stage, especially since it’s a new role and they’re finding their feet. In terms of arseholery, I’m looking for triangulated feedback. If two developers on the team independently give unsolicited negative feedback about the new starter, I know that there’s an issue I need to look into.

I should add at this stage that human beings are incredibly complicated. A new starter may have been entirely non-toxic at their previous job, but something about our work environment or practices might bring out the worst in them. Conversely someone that was fired for not working well in their previous team might change their ways the moment they start working at our company, because of something in the environment we provide for them. Forgetting new starters, existing employees may go through a rough patch in their life somehow, and that might manifest as negative behaviour at work. That could be a death in the family, serious illness, problems with their marriage, substance abuse, mental health issues, or any number of other things that happen to human beings sometimes.

For those reasons, when we give feedback to existing employees that are manifesting some of those aforementioned negative behaviours, we want to do so in an ultimately blameless way. Most of my strategy for giving this kind of feedback comes from the book, Difficult Conversations. I recommend that anyone that has to deal with humans reads that book.

When I give feedback to someone for any reason they may not be behaving according to the expectations for the job, the flow-chart looks roughly like this:

Without making any assumptions about their intentions or intrinsic character, I bring to their attention specific behaviours that weren’t in accordance with our expectations, and the impact those behaviours had on other people in the team. Wherever there is any confusion about the expectations, my aim is to clarify them, typically in writing.

I try to work with them to come up with a plan for correcting that behaviour in future.

If the plan works then problem solved, continue with regular operation.

If the plan doesn’t work then we try to iterate on it, or I fire them, depending on the specifics of the situation.

Side note to this: egregious cases of harassment won’t warrant any of these niceties. That gets you instafired and blacklisted. We will always always always take the side of the victim in these cases.

Having such a system is HR basics, but I’d argue is far more important to controlling for arsehole behaviour than anything in your selection process. If you’re having fortnightly one-to-one meetings and have strong internal relationships in your team, then I think you’re well positioned to detect and address this kind of behaviour.

To summarise we want to reduce the number of arseholes that get to our hiring funnel, we want arseholes to self-select out of the funnel when they get there, and we want to detect and address arsehole behaviour for new starters and all employees in the course of working for us.

That about sums up my current stance on detecting and addressing toxic behaviour in our hiring process. As I’ve said above this is still all a work in progress for us. We’ve been perhaps been extremely lucky in that we’ve never hired any arseholes. But I feel like we have the HR infrastructure in place in terms of process and relationships that we would quite quickly address this kind of behaviour if it happened at our company. I believe the rest of the team would agree, but you'd have to ask them directly to be sure.