How Is The Engineering Hiring Process at ShuttleCloud?

At ShuttleCloud, we’ve had several openings in the past 5 years. We’ve made a lot of mistakes in all of them. As always, we try to learn from our mistakes. We take everything we do as an iterative process: try, fail, learn; try, fail, learn.

Try-ShuttleCloud-engineering

In the last opening, we’ve tried to create a hiring process we can feel proud of. Particularly, I keep complaining about the stupid processes our industry has. Namely, whiteboard programming, processes with more than 5 technical interviews, tricky questions, rude/arrogant interviewers, etc….

Below, we want to share with you what we’re doing in ShuttleCloud to hire two new software developers.

Values

Values

If you want to have a successful procedure/process that is homogenous, you need to have all the steps clearly thought out and well documented. This is similar to what happens with the message and values of your company. In this way, all the people involved in the process convey the same information and use the same knowledge to make decisions.

In our case these are the values:

  1. Be respectful.
  2. Our time and candidate’s time is valuable.
  3. The process has to be fair.
  4. It should have the fewest steps possible to determine that the candidate is the right one.
  5. Each step has to be very well defined and that info has to be sent to the candidate.
  6. In each step, starting when the candidate enters the process (when their CV has been reviewed and the hangout interview has been planned), we will communicate the decision to them, whether it’s a go or not.
  7. We will convey timing to the candidates. For example, the length of the hangout, the time they have to do the coding test, and the time is going to take us to reply them in each step.

The process itself

Something we were certain of is that our offer had to be very transparent, and include as much information as possible.

  • Who we are.
  • What we do.
  • Our culture/philosophy.
  • What we expect from the candidate.
  • What the candidate has to expect from us.
  • Salary range.
  • Vacations policy.
  • Schedule.
  • Perks.

You can see this structure in the two positions we have opened right now: Senior Software Developer and Software Developer.

After some discussion with the team, we came out with the following process:

1. Review CV and explaining the process.

The first step would be to review the CV. Once a candidate has been accepted, an email explaining the whole process would be sent to the candidate. What we mean by explaining the whole process is this:

    1. Explain each step.
    2. Explain the timing for each step.
    3. Give a clear idea of what we expect from them.

You can see the email we’re sending here.

2. Hangouts Interview

The second step is a 40 minute Hangouts interview. In this interview we explain more about ShuttleCloud, and want to hear why the candidate wants to join ShuttleCloud and the most important things about the candidate’s CV. We also ask about the candidate’s expectations to make sure we can meet them.

Finally, we ask some technical questions to understand the candidate’s technical level. We have the list of questions in a wiki, so that every member of our team can access them and use the same ones.

The things you should ask depend a lot on each company; in our case we look for people with a good understanding of computer science fundamentals. We don’t ask tricky questions or look for a canonical answer, because we want to hear the concepts in the candidate’s own words. These are some of the concepts we usually ask about:

  • OOP. Explain in your own words the key ideas behind it.
  • Data Structures. For example: what do you know about a HashMap?
  • Processes and Threads.
  • Security (basic knowledge)
  • Design patterns
  • Network (TCP, UDP, HTTP)
  • Memory.

It’s not necessary to answer all the questions correctly, because we want to understand where each candidate is from the technical point of view. We take these answers into account along with other aspects like attitude, learning pace, experience, cultural fit, etc.
We also ask for feedback of the interview itself in order to improve it. Actually, we ask for feedback in every step 🙂

3. Resolve a Small Problem: a VideoGame

If the user passes the interview, the next step is to solve a small problem, a video game. First of all, as always at each step is to send the email conveying all the details

  • The problem.
  • What we want to evaluate in the code (OOP, Testing, Readability, Extensibility, Good practices like SOLID, design patterns, etc.).
  • The time the candidate has to solve the problem.
  • The time it will take us to answer them.

You can see the email we’re sending here.

4. Personal Interview

The last step is to have a personal interview at our office. In this step the candidate will spend one morning working with us.

We will talk about their solution to the coding test and also, we will give them a problem to be solved. From the architectural point of view, these are the things we want to see:

  • The candidate’s didactic/educational skills.
  • How the candidate approaches problems.
  • How the candidate designs a solution.
  • Architectural knowledge. That is, we want to see the big picture of the candidate’s solution and then go deeper talking about the internals of those components.

As in all other steps, the candidate will receive an email with all the information. You can see the email here and the coding test here.

How do you scale the process?

Scalability

We divide our team in groups of two people, then we split the candidates among those groups (so far, for the current openings, we’ve received more than 100 candidates). Each step was done by a different group. So, for example, if group 1 does the hangout interview, the coding test will be reviewed by group 2.

What tools do you use to handle the process?

The process is documented in our Wiki. There, every member of our team can see the full process and all of the documentation. We don’t want to have any gaps, so if someone has a doubt, it will be documented there. For example in the wiki you can see what to do in each step:

  1. A small review of the CV. Click here to see the details.
    1. It’s a go: go to step 2. In recruiterbox set to state: hangout
    2. It’s a NO go. In recruiterbox set to state: Rejected. (Not a fit)
  2. …….

To handle the whole process we use RecruiterBox. It’s a very easy to use tool. You define your openings and it gives you an URL for each opening. For each candidate it gathers some info for you, like LinkedIn, Twitter, etc.

You also define the steps here and even the emails templates for each step. Something really useful is that it tracks all the conversation in one place, including internal notes, so it’s really easy to remember candidates in each step.

Pitfalls

Despite of all our efforts we’ve still made some mistakes, which is normal– that’s life.

Painfall-developers

These are the ones we’ve identified:

  • Freedom to choose the language. We wanted to allow people to choose, so that they could show their best abilities and skills, but this has limited our possibilities to evaluate the solutions because we’re not fluent in all languages.
  • The first step should have been the coding test or a small questionnaire, which requires less time.
  • We are a remote-friendly company but not completely remote. We need to convey this more clearly to avoid misunderstandings.
  • Open Source day. We need to convey this better as there are some questions about how this happens. For example, the projects should be related to ShuttleCloud (tools, software, frameworks) that we use.

We’re close to ending the two openings we have available currently, and the feedback so far has been great. People have told us that this is the best experience they’ve had in a hiring process and it’s the clearest process.

This is great news, but we know that we still have to improve a lot though. As I said above: try, fail, learn; try, fail, learn.

Leave A Comment

Your email address will not be published. Required fields are marked *