A few words about hiring

I find myself in conversations about hiring all the time. The reason is pretty obvious: we need more people to help us reach the goals we want to reach. More talent. It takes a collective effort to ship 99% of things we build and that makes hiring a central problem when it comes about building, scaling, running a business. But do not get me wrong: the actual reason I am writing about hiring is not the fact that it is so central to the development of our teams and our businesses. The actual reason is that despite hiring is a core subject, most people approach it in a way that I barely understand.

There are so many things I do not understand about how we interview people, how we write ads we post on job boards, how we treat candidates, that I have a hard time finding a constructive way to talk about this. When I get this feeling I become more analytical. Analytical thoughts calm me down again. So let’s break the hiring process in parts and take it from there:

• You need ads on job boards.
• You have to screen people.
• You have to interview them.
• You have to either hire them or reject them.

I may be simplifying this, but at the end of the day every breakdown is a bit of a simplification of an actual process - and I can live with that.

Ads on a job board #

Are you a “jedi” JavaScript programmer? Or maybe a “warlord” backend developer? A “kickass” application developer? Maybe you are more like the classic type: rockstar or ninja.

I am not sure why this happens. It is plain bullshit and it is stupid, sorry for being so harsh about it. I have a hard time understanding the reasons behind this culture and to be honest I do not want to find out. I learned to look at the bright side of this aspect of job ads: I avoid companies like that. It is a good side effect that I enjoy a lot.

Now, let’s move on to the actual content of the ad. There are a couple of content patterns I see all the time:

• Buzzword, business talk with no actual meaning
• Very strict requirements to meet that are actually just nonsense

The buzzwording mostly indicates people are lazy and let their HR people write the ads for them. I know this is a strong assumption but, let’s be honest, have you ever cared about “fast-growing company”, “disrupting ideas”, “uber for X”? I guess you have not. And if you dedicate some time to writing your own ads, most of this crap will go away. I encourage you to write your own ads yet for another reason: it helps setting requirements that make sense. Some examples of nonsense requirements:

• X years of experience with our awesome stack

  This is really not inclusive. People tend not to believe me when I tell them that I had to A/B test this in order to understand I was doing it wrong. My explanation is the following: most 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 is fine, you would be able to figure this out while interviewing them anyway. But the actual problem here is that a lot of very cool candidates would read that and say “oh I have only 4.5 years of experience and that is a strict requirement so I won’t apply”. I generally use a different wording that means something very similar and it is more inclusive (in my opinion at least, I would love to hear yours on this topic). I write something along the lines of “proven experience on multiple projects with X”. It covers the 4.5 years case too.

• Degree or equivalent

  Honestly, who cares if you studied or not? Yes, it can be a requirement when you work on specific projects. For example, I once had to hire a lot of developers with a degree while leading a project for the Italian government (yeah we do have some form of “government”, there’s no proof it is helpful though), because it was one of their non-sense requirements. If you must hire people with a degree please give a proper explanation about it in your ad. The only significant difference I found while working with people that have a degree is that they sometimes start a sentence with “I’ve read in this book that…”. Well, I would hardly consider that a plus.

• Use of design patterns

  I read this one a lot. What the heck? What do you even mean with this one? “If you did not read this book you are not cool”? I really have a hard time understanding it. I don’t think it’s ever happened to me to say or to hear something like “I think we should use the strategy pattern here”. It is good if you’ve read this book because it is a good (super boring) book. But I can hardly justify this requirement in a job ad.

Last but not least, I want to underline that it is very likely for candidates to read about your company for the first time while reading your job ad. It is the first point of contact in most cases and you do not want to give people the impression you are just another company out there using the same ad as everyone else.

Screening people #

This is harder than it looks, as with everything else when it comes to hiring. I do not think it is a good idea to leave the screening to one person in your team - and I see this happen often unfortunately. If you have more than one team, you can play a small game, you can try to figure out with the teams if people would fit in their team. There is less chance of getting it wrong and reject someone based on the fact your team member did not have a good coffee in the morning. Obviously, this process may turn to be very expensive and I have already had this argument. But if you are not willing to spend time on getting people, you probably should not be working with people.

There is yet other thing I would like to discuss about screening. Sadly, this will sound like an annoying rant. In any case, if you’ve made it this far into the article, you must care at least a little. Code challenges are bullshit and you should stop it altogether. Here we go. I said it. Now I have to justify my claim somehow, but this is a rant remember? So I will leave raw ideas here and there because I’m actually still too angry with my own industry and this practice to come up with a calm cohesive argument:

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

  I never have, for example. The problem has never been the code. I had to fire people (which by the way sucks so you should work not to get there and hire the right people) because they misbehaved with co-workers, because they couldn’t find their place in their team, because they didn’t like us (of course that’s fine too, do not take it personal if it happens to you). The problem has never been the code, and you know why? Because that’s the easy part of working with a team of developers. Understanding the requirements, interacting with other people with a different background, culture, skillset, experience. That’s the hard part.

• Do you really need a code challenge to understand people’s hard skills?

  C’mon. Really? Don’t you get the feeling it takes a few simple questions about their experience with different technology to assess their level? Beware I’m actually just assuming people use code challenges for this reason. I simply cannot understand it - maybe I should talk more to people who use this hiring technique.

• Aren’t you afraid of false positive?

  This may sound completely stupid to you (well, that would be fine) but here’s my main argument in favour of avoiding code challenges: people that do not like code challenges wouldn’t apply for my company. If you think about it, you’re giving a lot of importance to the “writing the code” part. Is that what developers do? Don’t you tell yourself all the time you like building things? Or solving problems? “Writing the code” is just one part of it. And, to be honest, I believe the more experienced you are, the less you try to actually solve a problem with code.

As you can imagine, I’ve never used a code challenge in my career, I’ve successfully hired a lot of people without it. And look, they all knew how to write the code you care so much about.

Interviewing people #

This is notoriously hard for everyone. It’s hard not to intimidate people at interviews and for this reason you risk to miss the right talent for your company. So you have to make sure you’re talking like a human being. You can’t treat people like computers (I do know a lot of people that would prefer that to be fine). What I suggest is the following: ask about background. Try to understand who those people you’re talking to are. Try to understand if they are the employee you want them to be. Do not try to match your wishes with their profile. It never works like that. You know, they’re human beings, so they evolve constantly. They have different needs, they come from different countries. Then ask about their past experience if they have any. And here I may get technical if needed. I do not ask questions like:

• What’s 2^16?
• What are you favourite data structures?
• What version of Ruby do you use?
• What’s the difference between ArrayList and Vector?

Two things here: those are questions people asked me at interviews. Believe it or not, there are companies asking such ridiculous questions. Are you really asking questions like those too? Why? A honest question. Please let me know. Because it’s beyond my understanding.

I ask what I call vertical questions about technologies. I’m not a native speaker so maybe “vertical questions” makes no sense for you. This is what I mean: vertical questions are the kind of questions that are vertical to your experience level. Your answer will change over the years because your perception of the topic, your understanding of it will change over the years. I encourage you to think it over. You will find a lot of technical questions you can ask that won’t sound like the above-mentioned bullshit. And they are going to be more inclusive questions too: they’re not aggressive. They do not focus on the small details but rather on the actual understanding people have of this or that technology. Here is a quick list of things I may ask depending on the context:

• What’s your opinion on automated tests?
• Do you care more about a specific way of testing things? (Like unit vs integration tests)
• Why/when would you TDD?
• When do you think it’s a good idea to rewrite a piece of software?
• What do you like/dislike about technology X?

You see, those questions look easy but I encourage you to reflect. Don’t the answers to them represent the person you have in front of you more than a piece of code?

Hiring or rejecting people #

Be fast. This is one of the things I have learned. I have been slow, sometimes I did not even notify people and that is something I am ashamed of. It is wrong. We need to respect the people that we interview as much as we can. Moreover, I try to be as thorough as possible in the actual feedback I share with people: I hate canned answers. So I do tell them things along the lines of “Sorry I just liked someone else more than you. You were fine”. And I get quite some good feedback about that. And I know why. People hate when you lie to them in their face without shame. Please note that I do use canned answers in some cases. And this cost me a lot of thinking to accept I do need canned answers from time to time. So I split my answers in two categories:

• If both parts invested time in interviews and meeting (no code challenges here!) then I do write personal emails.
• If I know there’s not going to be any time investment (like when you reject someone upfront because you do not believe in bringing this person to the interview stage) then I use a canned answer. A fast canned answer is better than a slow “kind of canned answer” when there’s no point in moving forward.

Now just a few words about hiring people:

• Be fast, talent goes away fast. Make people an offer, try to get them on-board as fast as you can.
• Try to make their first days as cool as possible. Build a process with your teams to make it so. Generally, if you already have “the right people” they’ll be very happy to create a process to ensure a qualitative on-boarding process.

A few more words #

I find these very difficult, but I still try as hard as I can to achieve them:

• Diversity is the key for success. Make it obvious in your hiring process.
• Do not fall into the “cultural fit” trap. People do not have to fit “into your teams”. They have to fit “within your team”.

Probably those points deserve their own article.