Hiring

I don't understand the way our industry approaches hiring: we write job ads that scare people away, we hire recruiters to do the job for us, we ask candidates meaningless questions. It's almost like we don't care who we hire and, maybe, we don't.

Our industry is so obsessed with shipping fast and breaking things that it forgets that people ship things. We often use a hiring pipeline that makes no sense because we didn't design it ourselves. We do what everyone else does or what we were doing before. That's rarely the right approach and, moreover, it can't be the right approach when it comes to people. You need to know who you want to hire. Before you start feeding your hiring pipeline with candidates, you and your team need to agree on who exactly you are looking for. Most companies build profiles that stop at "Lang X developer" or "Senior whatever". Those are not people profiles, they represent only the area of expertise and the seniority of a profile. We hire people though, not their CVs.

I suggest you build a mental model for your hiring needs. You do so by taking into account many factors and dimensions to identify who to hire next. For the sake of the conversation, let's consider a bare minimum of dimensions:

  • Gender
  • Age
  • Cultural background
  • Technical seniority
  • Area of expertise

I'm personally not smart enough to keep all of them in my head for more than one team, so I always use a mental model while working with multiple teams. The technique I use to build and visualise this mental model consists of the following steps:

  • Get the names of all your teams on a whiteboard.
  • Add a score for each dimension to each team.
  • Look for the lowest scores in each team.
  • Adjust your hiring strategy accordingly.

I can accept that scoring teams by each dimension is an oversimplification of reality. Mental models are oversimplifications by definition because all models are wrong. But they're a useful starting point. In fact, this simplified approach is already significantly better than just caring about the technical seniority or the area of expertise like many companies do. I generally count people in each team by each dimension and averages for age.

This process scales well because you can apply it to aggregates. It works even if you have teams of more than a hundred people. The idea is always the same: look for the dimensions in which you score the worst. Once you know who to hire, you can focus on the pipeline. I recommend you do this exercise every two or three months, it keeps the information fresh in your mind and you get a good sense of who to look for. One interesting side-effect of this approach is that it often leads to the best kind of hiring: internal hiring. Let me use a trivial example. Imagine you have a team that really needs a JavaScript expert and then you got another team where you have two JavaScript experts. Maybe one of them is bored? It would be a win-win situation for everyone.

Knowing who to hire is the most important step of the hiring process because it comes before you even start the process. But it's only the first step of a long journey. As hiring is about people, you need to care about it every day. Hiring is a process you must design on your own, so let's move on to it.

Design your pipeline

Hiring is hard but firing is much harder. The best way to avoid firing people is not to hire them in the first place. You can never get to a 100% success rate with your hires because time is always a pressing factor. If you can afford the slowest process possible, then do so. There are too many factors that contribute to a successful hire, so you have to accept that you may fail from time to time. In my experience, a good success rate is 90%: nine people out of ten stay with you for a significant amount of time and both parties are happy about their choice.

The best way to minimise false positives is (surprise!) to strive for diversity. You involve as many people as possible in your process, you let team members talk to candidates. It works both for you and the candidates: you find out as much as you can about them and they find out as much about you. Tell the candidates everything you find relevant about your company and ask them what you missed. I often got the feedback that my interview process was better than average because candidates were getting much more information about us than from other companies they were talking to. That's a competitive advantage, and it sends the message that you care. It's easy to give people the wrong impression about yourself, in the end we never manage to dedicate enough time to candidates and they're probably talking to many companies at the same time. Letting them talk to more people on the team helps you avoid misunderstandings. In aggregate, you and your team should give them the right impression.

You need to be empathic if you want to design a good hiring process. Look at your hiring pipeline from the perspective of the candidate. Create a delicate balance between the experience of the candidates and your need for information about them. For the sake of this discussion, here is a high level breakdown of the hiring process:

  • Put an ad on job boards.
  • Screen the candidates.
  • Interview them.
  • Hire them or reject them.

I'm not writing down a more detailed process on purpose so we can focus on the general principles.

Job ads

Job ads in our industry are a joke. Ad titles are ridiculous: are you looking for a "Jedi" JavaScript programmer? A "warlord" backend developer? Or a "kick-ass" application developer? Maybe your titles are more like the classic type: a rock star or a ninja. These ads foster a culture of white male kids that read Hacker News and think they're the smartest kids on the block. This culture is a complete no-go for a diverse team. Use titles that are descriptive of the roles. For example, "Frontend developer" is just fine. You can add "Senior" or "Junior" to your titles as long as you know what they mean to your organisation. In fact, it's a good exercise to think about your definition of those words. The conversation often leads to interesting outcomes. There may be a disagreement within you teams, and converging to a common understanding is a great outcome of every conversation.

The content of the ads presents similar problems:

  • Buzzwords and business talk with no meaning.
  • Too strict or non relevant requirements.

The buzzwords mostly indicate you either copied and pasted your ad or you let your HR people write it for you. Either way it means you didn't dedicate enough time to the first point of contact between your organisation and your next hire. If you write your own ads, you can remove all the nonsense and show to potential candidates that you care about people in this first interaction. One other reason to write your own ads: it helps you set requirements that make sense.

Some examples of nonsensical requirements:

  • X years of experience with Y

    This isn't inclusive. Some people I met in my career would read something like "5 years of experience with X" and say "Well, I read a blog post once about X so I guess I'm cool". That's a problem because it wastes everyone's time. But false negatives should worry you even more. Many talented candidates that read this requirement would think "Oh, I have only 4.5 years of experience: I can't apply". Use a different wording to achieve the same result. I write something along the lines of "Proven experience on multiple projects with X". It covers the 4.5 years case too, and it's more inclusive writing. Furthermore, as one of the best people I've ever worked with would say, "X years of experience means nothing if you have done it wrong for X years". It's not the amount of years you spend working on something that matters -- but the quality of that experience.

  • Degree or equivalent

    The only significant difference I noticed in people with a degree is that they sometimes start a sentence with "I've read in this book that you call that X". Well, I would hardly consider that a plus. Sometimes it can even be counterproductive. I met people too attached to the theory and what their books tell them. But most programming we do isn't engineering in that sense, it's more of a craft. In our job, the practice turns out to be more important than the theory in a vast majority of cases.

  • Use of design patterns

    I see this requirement way too often. Maybe it means that if you didn't read this book you aren't cool. I have a hard time understanding it. I don't think it's ever happened to me to say or to hear someone else say: "I think we should use the visitor pattern here". Don't get my wrong: it's a decent book. But that doesn't justify it as a requirement in a job ad. There is a great number of people out there that you want to hire who didn't read this book and they get along just fine.

  • Git and GitHub

    This is taken for granted by many hiring managers. You must be familiar with those two if you want to work in the industry. This is a seriously broken assumption. On average, we use a small subset of the tool features in our daily workflows. It takes a couple of sessions with a more experienced person to learn the basics. Are you willing to close the door on talent because of a few hours?

    GitHub is only one of the tools people use to develop software. Don't fall for the idea that everyone uses it, it's obviously not true. You have to teach new hires how to use your internal tooling. You can look at GitHub the same way -- it's just one tool.

  • Side projects

    This translates loosely to "we want to hire only people that had enough free time in the past to have a pet project". I assume the intentions of this requirement is to underline you like people with a passion for learning and experimenting. If that's your intention, write that.

The purpose of requirements is to filter people out. Don't filter people out because you are used to copying and pasting a requirement. Don't give people the impression that you don't care enough about hiring them to write a few meaningful lines about why they should come work with you.

Screening

When it comes to hiring, everything is harder than it looks. Screening candidates is no exception. For starters, don't leave the screening to one person in your team. I see this happening often unfortunately; I made this mistake myself more than once. If you work with more than one team, you can't do the screening for all your teams, it doesn't scale. Try to figure out with the teams if people would fit in their team, teach the teams how to screen candidates. Screening CVs as a team mitigates the risk of doing a bad screening just because the one person doing it didn't start off the day on the right foot. This process becomes expensive when you involve more people. But if you are not willing to spend time on hiring, you aren't willing to build a great team.

Most HR tools let you rank candidates during screening, but there is no point in doing so. The purpose of screening is filtering out as many people as possible before you interview them. It's a harsh reality: you have to reject people based only on their CV. Ask yourself if you want to work with the person behind this CV. It's a closed-ended question that's designed to help you focus on the purpose of the process. Screening is awful and I wish one could avoid it altogether. But you can't avoid screening at scale: advertising brings many candidates into the pipeline or, even better, your company is popular enough for people to apply on their own. I know only two ways of avoiding screening:

  • Actively reaching out to the people you would like to work with.
  • Interviewing people referred by someone you know.

Sometimes I wonder if it's possible to feed the hiring pipeline only with those activities. I thought about it a lot in the past, but I've never managed to try it at scale. As everything, it has a downside: it closes the door to some awesome candidates out of your network, which is obviously not inclusive. One more downside of this approach: you are likely to reach out to people you consider fit for your team. That doesn't necessarily mean enough diversity.

Another common technique for screening candidates is using code challenges. Do not do this. Code challenges don't help you find the people you are looking for. Here are some questions to help you frame the problem:

  • How many times have you fired someone because of their technical skills?

    I never have. The problem was never the code. I had to let people go for many reasons: they misbehaved with co-workers, they couldn't find their place in the team, they didn't like the company. The problem was never the technical skills. Do you know why? Because that's the easy part of working in a team, it's the easy part of being a software developer. Interacting with other people, understanding requirements, building the right thing for your customers is the hard part.

  • Are you not afraid of false positives?

    People that don't like code challenges wouldn't apply. If you think about it, you are giving the highest priority to writing the code. Is that what developers do all day? There is much more to the job than just writing code. Moreover, the more experienced you are, the less you try to solve a problem with just code.

Code challenges can feel like an exam and that can hurt your diversity efforts. Many people performed badly at exams, I can personally relate to this as I've always got really nervous when taking an exam. Code challenges also take up time. Not all candidates have so much time to dedicate to you. They may be unhappy at their company, but you can't infer how much they want to work with you by the amount of free time they can dedicate to you. Some people have very busy lives, and you may be filtering them out because your code challenge takes half a day they don't have.

I never used a code challenge in my career and I still managed to hire successfully. And yes, they all knew how to write the code.

Interviewing people

It's easy to intimidate people during interviews and scare great talent away. To set the tone, I start interviews by telling candidates that I dislike the concept and the format of interviews. Then I explain that I just want to talk to them. It often makes people more comfortable because you are speaking to candidates like a human being: they don't feel you are going to interrogate them.

When you are planning the interviews for a candidate, be aware of the total duration and timing of the process. It's easy not to be inclusive. I know of companies that ask people to come over for a week and work for them. I understand the intention, you don't want false positives, but such a lengthy process leaves out all the candidates that don't have a spare week. I'm pretty sure that there are fewer people with a spare week than without.

I suggest you schedule meetings taking candidates' needs into account. If they meet you halfway, you are already on the right path. You don't want to screen people out of your process because they can't make an arbitrary time slot you chose for them.

You are trying to hire a person, not their CV, so don't ask candidates to list all the technologies they know, or solve an algorithm on a whiteboard. It's better to ask them about their background. How do they explain themselves and their career path? Your goal is to understand who they're, what made them the person and the developer they're today. Spend time understanding what they like and what they don't like.

It's a common mistake to try matching your needs with someone's profile. The goal is to understand if they actually are the person you are looking for. Candidates are human beings, so they evolve constantly. They have different needs, they come from different countries and have different goals. Asking them about their past working experience, if they have any, is a great way to understand how they got where they are today.

You can get technical if needed, but avoid questions like:

  • What's 2^16?
  • What are your favourite data structures?
  • What version of Ruby do you use?
  • What's the difference between ArrayList and Vector in Java?
  • How would you write pseudocode that reverses a linked list?

Those are real questions I have been asked. If you are asking such ridiculous questions, I urge you to ask yourself why. What do you think is the message your question sends? What's the outcome you expect?

I assume that people ask questions to assess candidates' experience level. But these questions don't assess people's experience! They test for taste, memory, and a little knowledge. These questions mistake knowledge for experience. It's interesting to find out if someone you would like to work with has a good memory, but that isn't as important as their experience in the field. Experienced people know that our brains are much better equipped for processing complex information than for storing it. It's not what you remember that makes you an expert at something, but how you use your knowledge to complete a complex task. Focusing on how they use knowledge leads to questions that better asses people's experience level.

My favourite way is to ask broader questions whose answers change over time. You have to be careful to design the questions so that people must use their own experience to formulate an answer. I encourage you to think it over, don't reject the idea right away. There are many technical questions you can ask that are not "knowledge-based". Broader questions are better because they don't focus on the small details, but rather on how deep the understanding of a topic is. Here is a list of questions I ask depending on the context:

  • What's your opinion on automated testing?
  • Do you care more about a specific way of testing things?
  • Why/when would you TDD?
  • When do you think it's a good idea to rewrite a piece of software?
  • What do you like or dislike about technology X?
  • When you were working with technology X you said it was hard. Why?

These questions are designed to tell you how much time someone spent working with X and what they really know about it. It's easy to figure out if a candidate knows about X only because they've read a blog post about it. Their answer always tells you.

Don't take these questions as a script though. The best interviews don't feel like interviews at all. They are good conversations between people that have a common goal: both parties are trying to understand if they would enjoy working with each other. That's the goal.

Rejecting people

Be fast and always tell people where they stand in your process. I've failed both at times and I'm ashamed of it. It's plainly wrong. Respecting the people we interview is basic human decency. Try to be as thorough as possible in the feedback you share about a rejection. If you don't have feedback to share, it means you did something wrong in the interview process. Avoid using canned answers for rejections, people hate canned answers. The reason is simple: people hate it when you show no interest in them. Canned answers are fast and automated answers, so they give people the impression you don't care about them. I'm not saying canned answers are always wrong. I do use them in some cases. Here is how I decide how to answer people:

  • If both parties invested time in interviews and meetings, then I always craft an email.
  • If I know there was no time investment for either party, then I use a canned answer. For example, sometimes you reject someone upfront because you don't see the value of bringing them to the interview stage. A fast canned answer is better than a slow crafted rejection with very little to share, and surely better than no answer at all.

Rejecting people is hard because it's harsh. No matter how you put it, you are telling them you don't believe they're a good fit for your team; you are telling them you don't want them in your team. The best you can do is tell them the truth. When I started hiring on a monthly basis, this process became very time consuming. I struggled to find a balance between having enough time to work for my teams and treating candidates fairly. I learned a little trick that changed everything for me. The idea is to book a little more time than you need to interview someone. You plan to spend one hour with a candidate? Book one hour and fifteen minutes. This way you have a buffer of time you can use to take notes and write down your impressions while they're still fresh. It helps a great deal especially if you end up rejecting the candidate. As leaders, we tend to immediately move on to the next thing that requires our attention. We tend to forget about things that are not relevant to us anymore. Sadly, people you are about to reject belong to this category and it's only human to quickly forget about the details. The notes I write down end up being the content of the email I send to people, so I suggest you do the same. Write something like: "there were two people for this position and I got a better feeling about the other one because when we talked about X I thought Y" or "I felt more comfortable with someone else because Z". Harsh sentences but don't worry about it, people appreciate harsh truth more than soft lies. People offer to stay in touch because the process was awesome. They remember your email because you showed care in an interaction no one ever does. Being honest gives you the opportunity to leave the door open for some candidates. You may reject someone because their profile doesn't fit your company at the time of the process. But it may work in a six-month time, so keeping the door open with some candidates may pay off.

Hire slow

Most startups hire fast and fire slow and that's considered somehow normal. I apply the exact reversed principle: hire slow and fire fast. This sounds good in theory but it's hard in practice. Anything involving firing is hard.

Growing companies are constantly understaffed and hiring is the only way to overcome the problem. It took me a while to accept that:

  • You could always do more with more people.
  • Hiring has no short-term positive performance effect on your teams.

More people in your team means you could do that one thing you never manage to do. It's a stressful feeling and it was difficult coping with it at times. But I learned that there is always an opportunity hidden behind every problem. Here the opportunity is to do more with the people you already work with. Make sure you always share with your team your hiring plans: it's a great introspection process. People come up with plans to do more with less when they have a better understanding of what's missing and what's relevant for the upcoming future.

More people means more communication to manage, it's an obvious and necessary overhead. Expecting spikes in the performances of your team is wrong. Instead, plan for the obvious drops accordingly. Hiring can't fix your now problems, it's an investment for the future of your teams. Stay ahead of your own needs and hire just a little before you need more people. This is how to make hiring a slow process: you are always hiring for what you don't need just yet. As soon as you find yourself saying "We need X developers now", you are three or four months late and you can't recover from such a delay.

Hiring slow is your opportunity to minimise false positives, too. If you hire the wrong people, the best you can do is to fire them. Unfortunately, that's an awful solution. Firing is always a failure: something went wrong and now there is no better option than giving up.

Fire fast

Firing is ugly, there is no better way to put it. That's why I advocate for doing it as soon as possible. I think of firing as the worst possible outcome of the on-boarding process which I organise in the following checkpoints:

  • First week
  • First month
  • First quarter

There is more to on-boarding than just looking for hiring failure, but let me focus on that aspect for now. In the first few days, I only look for big red flags. The kind of inappropriate behaviour that must result in immediate firing; sexist or racist behaviour comes to mind. The one-month checkpoint is the first chance for both parties to ask themselves if they did the right thing. A month is generally enough to assess if you enjoy working together or not. At the third month checkpoint, I ask myself the question "Do I want to work with this person for the next X years?" and if the answer is not "Of course, she is awesome!" -- I know I have a problem to fix. Tell people the truth: explain in detail your expectations and what isn't working. Follow up closely, as much as once per week for a few months if needed. It's expensive, but it pays off if you are proactive. Following up closely generates a reaction and that helps you make the right decision. There are three possible outcomes:

  • The problem gets fixed fast.
  • The problem gets worse fast.
  • Nothing happens.

It's easy to deal with the first two cases. If the problem gets fixed, great news: you can work with this person. If it doesn't, bad news, but you now know you can't work with this person. It gets trickier when nothing happens. In my experience, this is the worst case scenario because you won't be able to recover from this situation, but you can't say for sure yet. Maybe you can't connect with the new member in order to help or, worse, they don't even care about the issues you brought up. Talk to them every day if needed. If nothings changes, you hired the wrong person or they chose the wrong company. The actual reason doesn't make any difference to what you need to do.

Sometimes though, people don't fit anymore. They have been working with you for a while and they realise they aren't happy anymore. Companies are living entities. They evolve fast and there isn't anything wrong about this. In such cases, you have to pay extra attention to how you let people go. It's easy for both parties to show lack of care and leave behind a bad feeling. Once again, the solution is talking as much as possible about it. They helped you achieve your goals, now it's your turn to show them you appreciate what they've done. Some people don't behave nicely in their last weeks and it can happen even with people you really liked working with. It's human: their heart is somewhere else already and they can't help it. Observe the situation closely. If it gets unprofessional, talk to them and let them go as soon as possible. It's the best option.