Engineering hiring process at Alan
By: Rémy-Christophe Schermesser
Tags: Engineering, Transparency, Hiring

Photo by Tim Mossholder on Unsplash

We have the reputation of having a heavy recruitment process. As a transparent company, we’ve decided to shine more light, and clarity on it. This will allow you to understand why and what we do.

To do so, we reuse the question and answer format of this previous article.

What is the engineering hiring process at Alan?

How we hire people at Alan

At Alan, our recruitment process is designed to be global while specialised for engineers. It’s based on four main principles:

Objective : we have a defined set of assessments relevant to the role and backed by concrete examples.

: we have a defined set of assessments relevant to the role and backed by concrete examples. Fair : we learn continuously how to evaluate, calibrate, and manage unconscious bias.

: we learn continuously how to evaluate, calibrate, and manage unconscious bias. Transparent : our expectations are explicit, well-documented, and transparently shared with the candidate.

: our expectations are explicit, well-documented, and transparently shared with the candidate. Effective: our interviews have a good signal/time ratio, and the interviewer knows what a good and a bad answer looks like.

In addition to those principles, we have fundamentals that we truly believe in:

We have different types of Alaners (care, product, engineering, etc.) who are involved in the process. This allows us to have a maximum amount of unbiased signal. We try to avoid having a single person involved in too many steps of each person’s process. This also gives candidates the opportunity to meet several Alaners and get a better picture of the company they consider joining.

involved in too many steps of each person’s process. This also gives candidates the opportunity to and get a better picture of the company they consider joining. Each team has a hiring owner and the Talent team is there to support them. Their goal is to distribute and own the process management .

. Each step of the process is testing for something different to keep the interviewer’s focus high and give clarity to the Alaner responsible for the candidate hiring process.

We pay close attention to the entire process. At any point, important flags may surface requiring the stopping of the process.

We know that our hiring process is demanding. We believe it’s important to be able to assess candidates on multiple criteria: technical skills, cultural fit, growth mindset, etc. We believe it needs to be thorough. We want to continue building a strong company culture, that our way of working will fit the candidates, and build a great team that can reach our goals.

A key of our process is that in the end, we want to find out if we want to work with you, but most importantly to help you know if you want to work with us.

All of this makes us trust our process to hire the best candidates for Alan. It also allows us to fully trust any new hire from day one. From day one, you are considered as any other Alaners: with trust and confidence. That way you can focus on learning and ramping up rather than proving yourself.

The specificities of the engineering process

That being said, our engineering process is split like this:

Screening, 30 min. Focused on getting to know each other. It’s divided between us, Alan, asking some probing questions to the candidates. And roughly 30% of the interview, for the candidate to ask us questions. Written questions, as long as you need. This is the only step in the process that is done asynchronously. We ask five written questions to our candidates, and they have to answer us in English. We have a culture that is centered around asynchronous, written communication. This step is to assess this ability. Technical, 1 hour. The goal is to assess the programming skills of the candidate. It is composed of an exercise to do online on coderpad.io. This is not an algorithm challenge or a puzzle. We will ask you to implement a small service that is as close as possible to the daily work of an engineer. Past Project, 1 hour. Focused on one or two past professional experiences of the candidate. This interview is meant to test the candidate’s understanding of a previous project that they worked on, and their ability to speak clearly about technical detail. Reference calls, varies. We believe in a thorough interview process, and our ability to make the right assessment of candidates. However, in certain situations we recommend seeking outside feedback in order to make a more informed decision. We ask the candidate for a list of people to contact. We do not do any backchannel. The reference calls step is optional. Full-day, 1 day. The full day comes with many objectives in terms of signals that can be summarized as: additional ”sharpness” signal, cultural fit, personal fit, real-life coding ability, and product sense. It’s split in multiple interviews, with the high point being an exercise in our own code base.

The full day is split like this with:

Arrival/Introduction to the day , 15 min. Introduction to the team, briefing on full-day, presentation of our tools.

, 15 min. Introduction to the team, briefing on full-day, presentation of our tools. Behavioural , 1 hour or more. It is to uncover the patterns of a career and follow up with more behavioural questions. We dig deeply. We consider that the interviewer will be the person who knows the candidate’s best by the end of it.

, 1 hour or more. It is to uncover the patterns of a career and follow up with more behavioural questions. We dig deeply. We consider that the interviewer will be the person who knows the candidate’s best by the end of it. Co-founder/Senior Alaner interview , 30 minutes. We believe it’s important for candidates to be in contact with someone who started the company!

, 30 minutes. We believe it’s important for candidates to be in contact with someone who started the company! Architecture , 1 hour. This interview is similar to the engineering brainstorms we often do when starting a new project. It is meant to be a discussion on how to implement a new feature that the candidate will implement later in the day. The feature is the same for every candidate: we don’t reuse what was created by candidates during the interviews at Alan!

, 1 hour. This interview is similar to the engineering brainstorms we often do when starting a new project. It is meant to be a discussion on how to implement a new feature that the candidate will implement later in the day. The feature is the same for every candidate: we don’t reuse what was created by candidates during the interviews at Alan! Lunch/Break , 45 min

, 45 min “Coffee” with the Team , 30 min. The goal is to give them a better feeling for Alan’s culture while making some personal connections. This is not an interview, and candidates are not assessed during this time. It’s a time to chill and make informal connections.

, 30 min. The goal is to give them a better feeling for Alan’s culture while making some personal connections. This is not an interview, and candidates are not assessed during this time. It’s a time to chill and make informal connections. Ask Me Anything , 30 min. We switch roles with the candidate just after lunch by letting them ask us any questions they may have about Alan. It’s not an interview, but rather a way to allow the candidate to be clear on how it would be to work at Alan.

, 30 min. We switch roles with the candidate just after lunch by letting them ask us any questions they may have about Alan. It’s not an interview, but rather a way to allow the candidate to be clear on how it would be to work at Alan. Pair Programming 1 , 1h15min. The purpose of this interview is to place the candidate in a real-life situation of implementing a feature in our codebase in order to evaluate the following abilities: transcribe a framed feature into actual code, navigate and insert new code into an existing codebase, cast a critical eye on an existing codebase and suggest improvements

, 1h15min. The purpose of this interview is to place the candidate in a real-life situation of implementing a feature in our codebase in order to evaluate the following abilities: transcribe a framed feature into actual code, navigate and insert new code into an existing codebase, cast a critical eye on an existing codebase and suggest improvements Pair Programming 2 , 1h. Same as the previous one, but with another engineer.

, 1h. Same as the previous one, but with another engineer. Debrief, 15 min or more. It’s the time for us to get feedback from the candidate about the day and our hiring process.

The feedback loop

We believe the hiring process is an assessment on both sides and that we expect candidates to give us feedback at any moment. Nonetheless, we have organised times dedicated to feedback. Those three moments are not interviews and are not there to assess the candidate in any way.

Pre-full day call . It’s a time dedicated to answering the candidate’s questions, giving actionable feedback before the full-day, and showing them how to succeed during this day.

. It’s a time dedicated to answering the candidate’s questions, giving actionable feedback before the full-day, and showing them how to succeed during this day. Full-day debrief. A moment, at the end of the full day to gather the candidates feelings and feedback about this intense day!

A moment, at the end of the full day to gather the candidates feelings and feedback about this intense day! Anonymous survey. When the process is over, we send an anonymous survey to get feedback from candidates. This survey is sent whatever the reasons, being the candidates saying no, or us. And whenever it stops, being the technical interview or the full-day.

How do you assess engineering skills?

As you can see, we assess multiple engineering skills:

Pure coding skills with the technical and pair programming interviews.

Architectural and system design in the architecture interview and the past project

Leadership and mentoring with the past project.

Coding is one of the core skills of any software engineer. We need to assess it. And for now, the best way we have found is face-to-face exercises. We know that we do not want our hiring process to take more time than necessary for our candidates, and it is already quite long! Not everyone has 6–7 hours available to work on a home assignment. We want to make sure our process is fair, and inclusive. Being inclusive also means respecting the personal life of candidates, and their private constraints. That is why we prefer to have a one hour long face-to-face interview for assessing skills.

Live coding during the hiring process is an endless debate among engineers. Nonetheless, our experience shows that it has been a great way to assess coding skills. We are not interested in the fact that the candidate writes perfect or clever code but rather in their way of thinking and approaching the problem.

How do you assess soft skills?

We have a very strong culture. This implies soft skills are key for us. To assess those we dedicated a full interview on it — the behavioural. Almost all of the other interviews also assess some soft skills; like leadership in the past experience. As mentioned above each interview is backed with a grid of evaluation. This helps us mitigate biases and assess any candidate on the same grounds.

How do we mitigate biases?

We constantly assess potential candidates, and evaluate their performance, both formally and informally. These evaluations lead to forming an idea (as individuals and as a group) of who is “impressive” and how we define “talent”.

Research shows that stereotypes can introduce bias into the process, inflating or lowering the evaluation of people’s potentials, despite them having the same qualifications, skills or levels of accomplishment.

It’s ok, we all have those biases whether we are conscious of it or not. Understanding and managing unconscious bias can help us build a more inclusive and better hiring process.

The first step is to be more aware of them and watch out for them. From that, they are less likely to blindly dictate our decisions.

Here are a few resources and ideas that we use internally:

How can I negotiate my salary and perks?

We believe that transparency comes with trust, and that’s one of the key reasons for us to work so much on it. Open salaries are one of the steps towards trust and transparency. Levels are defined during the interview process and shared with the offer after the full-day. There is a premium depending on years of professional experience that is calculated year by year. This means, we don’t strictly offer salary negotiation. We may offer a degree of flexibility between salary and stock options.

As we are a work-from-anywhere company, you can also have local perks or differences, depending on the city/country you will work in.

I am a XXX engineer. Do you have a position for me?

Whatever your current job title or seniority, we do have a position for you. In fact, we don’t have titles. We want to hire people not roles. Our one and only job offering is named “Software Engineer (Junior, Senior, Staff, Principal)”. We hire software engineers that match Alan culture, and leverage their full potential. We have plenty of technical and product challenges to serve all appetites! We also don’t have quotas on the seniority. Our level repartition is like this at the time of writing this piece, but we are not attached in any way to it. We only ensure a good repartition of C-levels compared to the others. This is to make sure they are set up for success, with enough support from more senior engineers.

In the following graph, “G” is the most senior level we currently have. But it could go higher! The level “E” is equivalent to Senior Software Engineer at Google or Facebook. You can find more on our levels in this article.

Are you hiring?

Of course 😉.

We’re also discussing hiring more junior entry-level software engineering positions. If you’re interested, stay tuned!

See you around! 👋