Hiring humans at CARTO Infrastructure team

During this year at CARTO we have given a qualitative leap towards having a good hiring process.

I’m going to talk specifically about the Infrastructure team. This year is being particularly active because of the need to grow and also because of some rotations in the team. Hiring is a very exhausting process. Reviewing candidates applications, doing sourcing, interviews, technical tests reviews, etc.. In the end, I want to make sure that the right people join the team. Because of this, I prefer to spend all the time needed on designing a good process so we try to maximize the number of matches.

It may seem I’m an expert in the matter. The truth is that before 2017 our hiring process was crap. It wasn’t diverse, inclusive, smooth for either the candidate or us and, obviously, it was no fun. We were able to hire mainly thanks to friends, employees contacts and the company’s hype.

I was about to publish a job offer when Justyna joined CARTO. She, among many other things, has been pushing and helping everyone to have better hiring processes. During the first conversation we had about this job position she barely payed attention to the job offer I had carefully written. Instead of that, she asked me basically five questions:

How will this role contribute to the company objectives
Why the candidate should work with my team and me
How will this role be evaluated
What are the projects and challenges on this position? What will the candidate learn?
What will the candidate work on immediately after joining the team

Although they may seem pretty basic and obvious to answer questions, when you start thinking about it you realize is not so easy.

I started writing the answers to these 5 basic questions in a doc. While I tried to answer in detail, I began to think about many other different aspects of the job or the offer. Without noticing I ended up designing a complete hiring process with a 25 pages document, that will last forever. Of course, I relied a lot on my team. It’s important that everyone shares the same goals and values about the process. In the end, the people that are hired will spend most of their time working with the rest of the team.

These are, for me, the keys to a good hiring process.

Have a very clear idea about the skills you look for

Companies tend to look for a lot of skills, and especially technical skills. You have probably seen job descriptions with a never-ending list of technical requirements (PostgreSQL, docker, nginx, chef, ansible, python, ruby, bash, etc..). This is bullshit. You don’t need so much detail (and so many skills) unless new hires are going to perform always a particular set of tasks (which is not common in small/mid companies). Also, a person that knows so many things probably doesn’t know any at all.

You probably need to ask only for 2 or 3 core technical skills which will be related to those things that you work with every single day. I can count with one hand’s fingers the technologies or tools that we work with every day at CARTO: Linux in general, chef and python. This list of “requirements” can even become shorter. For example, chef and python are things that the candidate will learn if s/he already has experience with similar frameworks/languages. In summary, I’m confident that the only technical requirements a candidate needs are experience working with Linux servers and coding skills. As simple as that.

Another thing I have learned during the last years is that you want/need different people in your team. Different gender, different culture, different working experiences, etc.. You need people that share mostly the same values, but that think differently and solve the same problems from different perspectives. That’s what will make your team keep growing and innovating.

In my case, the people I look for must have several soft skills like team working, ability to analyze, understand and explain things, initiative, care for detail, ownership, and energy. In general I look for people that are going to be able to contribute to the team and bring something new like a different perspective, and of course, people that I feel I would enjoy working with.

Make it personal

We are hiring people, not cattle. I firmly believe in quality over quantity, no matter how much work you have. Spend time on learning about the candidate. Don’t shoot everyone you see on LinkedIn and, for god’s sake, don’t send automated emails. Don’t do it. Don’t.

If you are sourcing, you must be excited about knowing every candidate you decide to write an email to. Read carefully the candidate’s cv, hobbies, blog, comments on StackExchange, etc.. This exercise will help you get either more excited or not interested at all. In any case, once it’s time to send the email, be sure that you know how this candidate can contribute and make it clear in your email. Make the candidate understand that you firmly believe that s/he can be an excellent addition to your team, not only because you think s/he will contribute to the team success but because s/he will enjoy and learn doing it.

Unfortunately, this is not a common practice. Most recruiters either send an automated email or they stick to a keyword they saw in your LinkedIn profile. It’s a loss of time and generates frustration and also distrust towards the recruiters in general. Don’t be that recruiter, please.

Simple, reproducible and inclusive

It’s important that you evaluate all candidates based on the same topics. Although I don’t believe in having lots of technical requirements I need to be able to assess the candidate tech skills. We have interviews and technical tests (I will talk about them later).

When your company grows you realize that you cannot hire only friends anymore and people that would love to join your company also have a life. Evaluate everyone equally but keep your hiring process flexible. For example, if one candidate is not able to send your technical test results in time, maybe it’s not because of not knowing how to do it or is a bad worker, but perhaps because she/he has another job, kids, etc..

Just try to be transparent with the candidate and show your support and will to help during this individual process.

Full transparency

One of the best things about writing a hiring document is that you force yourself to write every detail about what you are looking for, how the process will be and what exactly the candidate should expect when joining your team.

You realize that not everything in the job position, your team or the company is super cool. And that’s ok. However, when you identify those things you have two options, solve them or just be transparent about them.

Nobody’s job is perfect. However, there may be some unnecessarily bad things. Sometimes you don’t realize about those things until you don’t imagine your self explaining them to a candidate and feeling embarassed about it. That’s an excellent exercise. Designing a hiring process can help you identify deeply rooted problems in your organization!

Let me use an example. Everyone has seen job descriptions saying things like “required ability to handle multiple simultaneous priorities.” I have, at least. This is a smell. It’s similar to when you see an apartment advertisement that says “very well illuminated basement.” This probably means that there are big lamps in the apartment, not natural light coming from big magical windows. So, if you require a candidate to be able to handle multiple simultaneous priorities maybe you have an organization problem and your employees are already frustrated or stressed.

So, don’t try to hide anything in the process. If you identify something really bad, try to fix it. If you cannot, or there are just some parts of the job that are boring that is entirely ok. But be transparent about it. I’m sure that for every boring or lousy part that the job position has there are also several pretty good that the candidate will enjoy.

Salary range

This is a controversial topic. Some people don’t like to publish a salary range and some people get mad when you don’t do it. I don’t usually publish a salary range for these positions. Not because I’m trying to make a fool of the candidate or pay less money. It’s because I don’t know the candidate in advance and I use a process to try to learn how the candidate will contribute to the team so I can finally present the best financial offer I can according to the impact I believe, after the inverviews, the candidate will initially have in the company.

Said this, in the very first phone screen we describe the different salary ranges depending on the candidate skills. Everyone involved in one person hiring share their feedback internally and we all pay close attention to this feedback in case we identify, at any moment, that the candidate’s expectation may not match with what we are seeing in the process. In case this happens, we share immediately with the candidate this concern in case this is a problem. We don’t like to waste the candidate’s time.

So, we don’t publish the salary range because unless you want a person that will contribute in a very specific way it’s hard to commit to a salary in advance. But I believe in being very transparent and clear during every step of the process, so everyone has a pleasant experience. Most of the times, after some months we we confirm that this person has the right salary. However, it has happened a couple of times that the candidate makes much bigger impact that we thought s/he would make, after the interviews, and we raise the salary as soon as we can.

The current process

First of all, I believe there is much room for improvement in our current process. We pay attention to every step of every interview and ask a lot of feedback to the candidates. That way we can keep improving it. Actually, during this year, this process has already had a couple of slight changes.

Very important. Although the candidates want to join your team, it doesn’t mean that they should do whatever needed to get the job. Nobody should need to sacrifice an animal in order to make it. They have a life and values.

In the other side, your team is very busy with the daily routine. You want your team to be fully involved in the process, but you should not demand a lot of time from them. The key is to find the right balance, always focusing on effectivity. Every step of the process must serve an objective. They must be insightful. And the insights must be wholly related with the required (good to have) skills that you defined previously. If any specific step of the hiring process is not helping you to decide how that person is going to contribute or doesn’t give the candidate a better idea about what to expect in the future, probably you need to either remove o modify this step.

Our current process is something like this:

First, one person from HR has a phone screen with the candidate. It’s a friendly conversation focused on telling the candidate a little bit about the job position and to understand the candidate’s expectations and motivations to join the team
We send a take-home test. It’s a very enclosed code test with precise inputs and outputs. We also give direct information about what we expect to see in the code. The exercise is simple and fast to do and to review
We have a 1-hour conversation with the candidate where we talk in detail about the company history, our values, how we work and what type of projects we work on. We also ask the candidate to tell us something she/he’s passionate about the job or about one technology or something like that
We have a 1-hour technical interview about some Linux systems scenarios where we help the candidate to debug the problem like in a role play
Finally we have two face to face interviews. The first one is an architecture problem also in a format of role play and the second one is a general conversation with our VP of Engineering.

During the first phone screen, our recruiter describes the entire hiring process and let the candidate clear that we will be giving feedback after every step. We try to make the candidate’s life as easy as we can. We do this by providing flexibility to choose the schedule of every interview and to give flexible times to complete the take-home test. We also give flexibility about the type of the interview (remotely or face to face). Usually we try to meet the candidate in person in the last interview. If that’s the case we help the candidate to come to the office for this last interview.

Everybody likes numbers. During the first months, this new hiring process took to us more or less 11h (per candidate) and, at the very least, 11h to the candidate. After several improvements, now it takes around 4.5h to us and 5h to the candidate. Not perfect. But we are working on it.

The feedback

When you design a hiring process, you design for people. Candidates will meet a lot of companies and companies will meet a lot of candidates. Most of the times there won’t be a match, for any reason. You must expect that everyone has a nice (and, if possible, rewarding) experience.

Our process is not perfect and it won’t ever be because every candidate is different. However, we make a lot of efforts to, at least, keep improving. We always ask for feedback. I must say that I’m tremendously happy with the feedback we usually receive. Very different people have told us that they have either enjoyed or learned during our process and that they have been delighted to know us (either if they finally joined or not). I’ve done a lot of interviews and hired people in the past and I never received this type of feedback and in such amount. Of course, we have also received some critiques, most of them constructive, that we have used to improve the process.

At the same time, we always give feedback about the reasons why we decide to finish a candidate’s process before the last step.

I personally can say that hiring, although well done, is exhausting. However, if well done, it’s a rewarding experience. I’ve got to know a lot of interesting people that I hope to see again in the future.

By the way, besides this is something I really wanted to tell I was also extra motivated by some conversations with Félix and also by the blog post he wrote some time ago that you really need to read.