RESOURCES

An Agile Recruitment Process for Businesses with Small, Remote Teams

About this Publication

The recruitment process can be time consuming and making the wrong hire can be very costly. A well-structured recruitment process makes a huge difference, allowing us to find better candidates that will stay longer in less time.

1.     INTRODUCTION

OmbuLabs is a growing, distributed, fully remote software boutique. As a specialized shop, projects are carefully selected, and team members need to be highly skilled and specialized. The OmbuLabs team faced several challenges in the recruitment process and realized early on we needed an “unconventional” process to find the best candidates not only in terms of expertise but also in terms of cultural fit.

A process was developed to assess both technical and cultural fit and give the candidate a good sense of the company. However, this brought a new set of challenges, the biggest one being how long it took to hire a new team member.

I joined OmbuLabs as an Integrator. The company consisted of developers and an office administrator and the founder would serve as a technical lead and project manager. My role was to serve as a Scrum master to the development teams as well as help manage company operations, optimizing workflows and existing processes, including recruitment.

Shortly after I joined the company in 2019, we needed to hire a Junior Developer and were looking for a Senior Developer. The recruitment process was then headed by one of the Senior Developers together with the Founder, and they had to balance recruitment with their other responsibilities, which generated some challenges.

Looking at the process with a fresh set of eyes and previous experiences in mind, I took over managing recruitment and started proposing a few changes to overcome these challenges. The team was receptive and helpful, contributing with valuable feedback and input based on strategies previously tried.

Building on the existing process and our collective experience, we have found good solutions to overcome most of the challenges faced and are testing solutions to a couple remaining ones; and we are seeing very positive results.

2.     Background

OmbuLabs started as an office-based company but, a few years ago, went fully remote. The process of becoming a remote team brought a set of challenges, and the recruitment process was no exception. However, it also brought several advantages, the biggest of them being the access to a much larger talent pool, distributed across several countries.

As a small software boutique specialized in Ruby and Rails development, we work on multiple projects at a time with different clients, including Rails upgrades, minimum viable product development, staff augmentation, product development, and consultancy, among others. Our developers also work on internal projects developing tools to be used within the company when needed.

Due to the nature of the work and the business, team members need to not only be able to work with each other, since teams rotate a lot, but also be able to easily plug into a client’s team when needed. Additionally, as a small business, we cannot afford waste time and resources hiring and training someone who cannot work with this kind of culture and will only stay with the company a few months. As such, the recruitment process is a crucial part of the business and ensuring we make the right hiring decision at the right time is pivotal.

In addition, as a fully remote team, we hire candidates from all over the world. This means the entire process is virtual, which brings its own set of challenges since we don’t meet candidates face-to-face.

3.     Developing an Agile Recruitment Process

Even when it was an office-based company, OmbuLabs didn’t have a traditional recruitment process. The idea of having a different process came from the founder and his desire to do the right thing. When I joined OmbuLabs, we already had a non-traditional 5-step process in place.

That was the process I went through. I remember noticing, however, how long it took (a few months at the time). My first contact with the recruitment process from the company’s side came shortly after I joined, when we needed to hire a senior and junior developer. The process was, at the time, headed by one of the senior developers together with the founder. Since they had to juggle it with other responsibilities, the process could take some time to be completed.

I was coming from previous experiences experimenting with different processes at companies frustrated with “traditional processes” not yielding positive results.

Some of the most common issues I had encountered included candidates with great experience and skill slipping through the process because they didn’t have very good resumes; time and resources being wasted on candidates with great resumes but not the right skills or not a good fit for the team; inability to hire fast and emergency hires leading to the wrong people being added to the team, among others.

Therefore, I was pleased there was already a good process in place at OmbuLabs that we could just tweak and perfect.

3.1        The Original Process

The process was structured in the following 5-steps:

Figure 1. 5-Step Process

 

Each step serves a different purpose and allows us to learn more about the candidate.

The application form includes a set of questions designed to help us learn more about the candidate and their interests. We do not ask for a resume, instead, we ask for links to LinkedIn, GitHub and any other social media links they want to share with us. That is a great way to learn about their interests and also how they interact with the community.

The candidates whose applications were selected are invited to a non-technical interview. This is our first contact with them and also their first contact with us. We have a 30 to 60-minute long interview via video conference that is focused on their background, expectations and experiences. We have a set of questions we like to ask but the interviewer can ask any other questions at their discretion. The goal is to learn as much as possible about the candidate but also to make the conversation as relaxed and friendly as possible. It is also an opportunity for the candidate to ask any questions they have.

The video call allows us to see how the candidate acts during the interview. Are they focused? Do they seem uninterested? Does it look like they have too many distractions on their screen? Or do they seem too nervous? Those are some of the things we need to look for during the non-technical interview.

Our process is “all hands-on deck”. What this means is the whole team can take part. As such, it is also important to make sure everyone gets a chance to provide their input and that every team member participating in the process gets all the information they need. In order to ensure that, all video calls are recorded and shared with the team on our Slack. They have the chance to watch and provide their input before we move the candidate to the next step.

If the team doesn’t express any concerns the candidate is invited to the technical interview. That is a 30 to 60-minute long interview with one of our senior developers, focused on their technical knowledge and experience. We also have a list of questions we have to ask in the technical interviews, but the interviewer can ask more questions at their discretion.

The recording of the technical interview is also shared with the team so they can give their input. The first two steps of the process allow us to evaluate the candidate’s technical ability and overall attitude, but the next two steps are what will really allow us to see how they would fit in with the team.

After the technical interview, we invite the candidate to two 2-hour long pair programming sessions where they work with two different senior developers on a test project. Since we ask for a longer time commitment (4 hours in total) we pay the candidate for this time at a previously agreed hourly rate. Both sessions happen remotely and are also recorded and shared with the team.

Both pair programming sessions also happen through video conferencing. This allows us to evaluate, in addition to their technical skills, how well they work with others in a remote environment. Even if the candidate has never worked remotely before, this will give as a good idea of how hard the change will be for them.

Video conferencing brings its difficulties though. Having conducted multiple online recruitment processes over the years, I have encountered a multitude of “creative” ways to try to take advantage of the recruitment process.

One situation that, unfortunately, happens quite often is candidates looking up answers to questions on their phones or on a different window on the computer. Depending on the candidate’s webcam setting, this is tricky to identify. Some cues we look for are candidates with a front-facing webcam looking to the same side as they speak or moving their eyes through the screen indicating they are reading out of something. Taking too long to respond to a question is also a good indicator. It might be that the candidate is just nervous or trying to remember something, but it might also be that they are stalling while looking for the best answer on the internet. One strategy we employ to help identify that is to start with non-technical questions that focus on the candidate’s background so that if when we move on to technical questions they deviate from the candidate’s speech pattern too much, we can look for specific sentences on our end and identify whether they are reading from a web page or not.

Another situation that has happened on a few occasions is candidates having someone else in the room helping them with the interview. This is a trickier situation to identify but, in an effort to prevent it, we ask candidates to wear headsets / earphones versus using the computer audio. Paying attention to whether the candidate is looking, and their speech pattern also helps identify this. Additionally, even if the candidate manages to pass the technical interview employing such a strategy, they will fail the pair programming sessions.

One extreme example of the above involved a candidate who did not speak English interviewing for a position that required fluency in the language. The candidate was invited to an interview but, a few minutes in, it was clear there was a “delay” between the audio and video. Suspecting something was wrong, I mentioned, since it was a remote position, we needed to make sure they had a fast internet connection. The network speed test revealed there was no slowness that could cause this kind of delay. I then started asking questions that would require longer, more elaborate answers and the delay increased. It was clear there was something wrong, so I expressed my concern and asked the candidate directly if they had someone helping them. It turns out the candidate didn’t speak any English and had a friend in the room “dubbing” them for the interview.

It is important to keep an eye on the details and adjust your questions accordingly to properly assess the situation.

After these five steps, all team members who took part in the process hop on a video call to discuss the candidate and make a decision.

The process was yielding positive results. However, there were some pain points for the OmbuLabs team. The main ones included:

  • Lengthy process leading to good candidates abandoning the process, sometimes at the final stages;
  • Large number of applications leading to candidates who didn’t get selected for an interview never hearing back from us;
  • Lack of a strategy to reply to candidates not selected for the initial, non-technical interview leading to negative feelings on candidates (shared with us over email and social media); and
  • Long waiting periods between two different steps of the process leading to negative feelings for the candidate and internal issues for the company.

These were the issues we needed to solve. And solving them led to a new set of challenges, some of which we have overcome and some of which we’re still working to overcome.

 

3.2        The Refinement of the Process

The first thing I did was talk to the senior developer previously in charge of the process. She was happy to share all the strategies they had tried, information on the process as well as the pain points. The same was true for the founder.

One point that became clear was that we needed to add a bit more structure to the process. Ideally, we would have two or three candidates reaching the end of the process so we could make a decision. However, we strive to make sure the experience is focused on the candidate and, keeping candidates waiting too long for a response was not a very good experience.

Therefore, I decided to approach the process in an iterative way. I would select three candidates to interview and start the recruitment process with. And, when a candidate dropped out of it, a new one would be added. This allowed us to be honest about our timeline and better manage expectations. When would they hear back from us? Would it take us longer to give them a response?

Additionally, we could tweak the process as needed. If we needed an urgent hire, we would add more people to make sure we got three to the final step to make a decision. If we didn’t have an urgent need, we could have each iteration with one candidate. Either way, we would be able to tell the candidate exactly what our timeline and needs were and manage their expectations accordingly.

After our first iteration, another change was made. We needed to ensure we weren’t overloading the team to keep the experience enjoyable and not harm the quality of the process. We needed to keep in mind the senior developers taking part in the process were also assigned to client and internal projects. Therefore, we decided to space the steps in a way that no more than two technical interviews or pair programming sessions would be scheduled with a single developer during a particular week to allow them to better prepare for it and also so everyone could have time to review the recordings and give their input.

Another modification that came after our first iteration was ensuring at least one of the senior developers taking part in the process had contact with more than one of the candidates. This way, they felt more comfortable to provide input in case we need a “tie-breaker” as they didn’t just see the candidate through recordings.

We have had three processes since I joined the company and, after our second one, a new challenge appeared. Although we made sure every candidate going through the process got a response, even if it were a negative one, candidates who applied but weren’t selected for a non-technical interview never got a response from us.

This was mainly due to the large number of applications we received, but also due to the fact that we receive applications even when there isn’t a process in progress. After we received feedback from an applicant on that matter, we came up with a strategy to better manage expectations and ensure everybody got an answer from us.

We weren’t able to manually email every applicant to make sure they got a confirmation that we received their application, but we wanted to make sure they got a personal response from us regarding our decision. To solve that, we set up an autoresponder to be sent when they submitted an application and set up a system on our end to alert us when an application reached thirty days with no activity. That ensures every applicant gets a response from us regarding our decision.

3.3        Virtual Process Setup

In order to achieve the desired results and overcome some of the challenges we faced, we had to find a way to better integrate the tools we use to manage the recruitment process.

Currently, we use Typeform to create and manage application forms, Trello to keep track of where candidates are in the process, and Slack to communicate internally.

Figure 1. Internal Recruitment Process Trello Board

Our Trello board is the main place to keep track of candidates and where they are in the process. Figure 1 shows how the Trello board is structured so it shows us where each candidate is in the process.

The first two columns show new applicants, separated according to whether they are applying for a junior or senior position. The following three columns indicate where they are in the process, while the last two indicate whether we need to notify them of a negative response, or they have already been notified / abandoned the process.

Initially, the process was setup so that candidates would be screened in Typeform and, if selected for a non-technical interview, a card would be created in Trello to keep track of their progress through the process. This was not ideal as it was easy to miss new applications since we were looking at a list of responses to the form and candidates who never made it to an interview ended up “forgotten”.

In order to make sure all team members had access to all the information they needed, and all candidates got a response from us, I used Zapier to better integrate our tools. Zapier is a tool that allows us to integrate other applications using an “if this happens then trigger this” format. Both Typeform and Trello are supported by Zapier, so I created the following integration: When an application is submitted, a card is automatically created in Trello in the proper column with all the form information and the proper label and a due date for the card is set.

Trello also integrates with Slack, so every time a new card is added a notification is sent to a Slack channel, and everyone on the team knows we have a new applicant.

Additionally, we use Zoom to conduct and record the interviews and pair programming sessions. Those recordings are shared with the team on Slack but also added to the Trello card. This way, each card has all the process information for a candidate and, if we need to reference it in the future, it is easy to do so.

3.4        Results

The modifications we made to the process resulted in very positive results. In summary:

  • Faster process without loss of quality;
  • Better management of expectations on both sides to avoid negative feelings and reduce the number of candidates abandoning the process;
  • Proper balancing of the workload on the team’s side;
  • Reduced onboarding time for new hires; and
  • Hiring of candidates that are truly good cultural fits.

 

First of all, we are able to have a much faster process without losing quality. Ensuring we always have more than one candidate going through the process ensures we can hire the best fit but structuring it in iterations and setting clear expectations ensures we can complete it within four weeks and bring it down to two weeks if we need to hire urgently.

Being able to know how long the process would take also allowed us to better manage everyone’s expectations: the team’s and the candidates’, which led to a much better experience and positive feedback from both sides. Additionally, a faster process and better management of expectations ensured fewer candidates abandoning the process.

After our first iteration, we adjusted the process to ensure no more than two technical interviews or pair programming sessions happened on the same week with the same senior developer. Ideally, the same senior developer would only handle one per week. This made the process a little lengthier, but also ensured we kept the high quality of the process and made the best possible choice.

With a better overall experience, both team members and candidates were happier. This helped ensure new hires were good cultural fits and also reduce the overall onboarding time. When a new team member was added, several different team members had already interacted with them and we had already seen how well they’d work with others in a remote environment. They were welcomed right away and could get comfortable with the new environment quickly.

Furthermore, ensuring the candidate feels welcome and fits in well, in addition to being truly qualified, ensures they will stay with us longer and a new process will not be needed soon, which is good for the overall atmosphere and also saves time and resources invested in recruiting.

We are able to onboard a new senior developer in a week, which is much less than the average onboarding times I experienced at previous companies, which used to be anywhere between three to six weeks.

Finally, a main benefit of this process is it truly introduces candidates to the company’s philosophy from the very first step. We are a very open-minded company that puts a lot of focus on helping people grow and contributing with the community. Having a process that allows us to place the focus on the candidate and be open from the beginning, sharing as much information as we could. This makes candidates to feel more comfortable and prompts them to share more about themselves with us too.

We do, however, still have challenges to face.

Since all our interactions happen online, both internally and with the candidates, we are still working on a better way to document the process internally and share the knowledge. Currently, I am the only person on the team that knows how the integrations are setup and where the information is stored. The idea is that any team member should be able to start and lead the process and the knowledge should be transferable, so we don’t create bottlenecks in the process.

We also need an improved way to share information during the process internally. We currently use Trello to keep track of where candidates are in the process and keep a record of the recordings. However, the discussions and feedback currently happen through Slack, the tool we use to communicate internally. When we have multiple candidates going through the process at the same time, this has proven ineffective as it can be hard to gather all the information when needed and things might get lost.

Finally, we would like to improve the application form. Even though the current questions give us a good idea of who the candidate is, we still have room for improvement to ensure the best fits get to the non-technical interview.

4.     What We Learned

We have learned a lot from improving our recruitment process. The main lessons from this process were:

  • Being open to feedback and truly responding to it is important;
  • New challenges will arise as we tweak things, it is important to keep an eye out for them and tackle them in the right way;
  • Having at least one team member involved in the process have contact with more than one candidate was very important;
  • It is important to have balance and think through modifications to not move too quickly and make mistakes;
  • Communication is paramount. And although we want to focus on the candidate and make sure we are openly communicating with them at all times, internal communication is just as important.

 

First of all, it is important to keep in mind being open to feedback and input from all team members is very beneficial to us. It is something OmbuLabs has always had and valued, which is part of what made the whole experience of tweaking the process so easy. The team was open to my input and happy to give me feedback, which was incredibly helpful.

The first lesson we learned was that a step in the right direction meant we moved forward towards a better experience for everyone involved but also that we uncovered new challenges we needed to respond to.

After our first modification, we learnt that having a more structured process made it easier for us to manage it and manage the candidates’ expectations. Having multiple candidates going through the process at any given time also made it faster without compromising quality. However, we also had to balance it, so we didn’t overload the team. After all, we wanted feedback and input from everyone but, in order to give them a chance to weigh in, we needed to make sure they had enough time to review the recordings even if they were not interacting with the candidate directly.

Once that part of the process was implemented, a new challenge appeared. Structuring it so that we didn’t overload anyone was a good thing, but it also led to me thinking about the process as being organized in different paths that were thought of individually. As such, after our second process with the new modifications, when we had a call with all team members involved in the process to talk about the two candidates who had reached the end, it became clear they were both great candidates. However, none of the senior developers involved in the process with one candidate had had contact with the other. Therefore, they were a little concerned about sharing their input based solely on the recordings they had watched.

We learnt thinking of the process as individual paths was not effective and we needed to ensure at least one of the candidates involved in it had contact with both candidates, so they felt confident to speak up when we needed a “tie-breaker”.

Another lesson we learned was to respond quickly to feedback. While the feedback we got from candidates going through the process was very positive, at the beginning we neglected the fact that candidates not being selected for a non-technical interview were not hearing from us at all. However, after receiving feedback on that via social media, we responded by putting a strategy in place to ensure everyone receives an answer from us, even if negative. This is still at its early stages, but we have had a couple positive responses so far.

Feedback coming from the team was just as valuable as well. Even though we strive to address issues quickly, it is important to take time to make sure we are not moving too quickly. As the entire process is remote, it is easy to tweak it and implement changes. However, it is just as easily to make unnecessary changes and move forward with ideas that turn out to not be good. That ends up wasting time, which is never a good thing. Therefore, evaluating ideas and choosing the best ones before moving forward is important. This doesn’t mean there is no room for experimenting, but that it is important to take time to evaluate the options, choose the best ones and iterate. And it is also important to know when to decide an idea was not good and move on.

It also became even more clear that communication is extremely important specially in a remote environment. When all the communication happens in writing or over video conferencing, there are different things to look for and keep in mind. In my personal experience with this kind of process, I have seen a few different situations that wouldn’t happen in face-to-face interviews, like candidates looking up answers on Google or having someone else in the room helping them. However, it is also extremely important to be aware of how you communicate and act during a virtual interview, as it is harder to get candidates comfortable.

Additionally, how we communicate internally is also important. To make sure the process is a quality one, we need to ensure everyone involved has access to all the information they need and also that their input and feedback is taken into account. In order to do that, we must improve our current systems.

Finally, this experience allowed us to renew our faith in our core values as a company and as a team and to be more incentivized to contribute and keep striving to improve in other areas as well.

5.     Acknowledgements

I’d like to thank Ernesto, the OmbuLabs Founder, and Cleviane, the Senior Developer previously in charge of the process for the opportunity to experiment in an effort to improve and for the support provided, as well as the entire OmbuLabs team for the valuable feedback and support provided at all times.

I’d also like to extend a special thank you to Nathalie for her valuable input, insights and all the support and help provided to write this report. I could not have done it without you.

About the Author

No bio currently available.