How to Interview Remote Software Developers

How to Interview Remote Software Developers 

Knowing how to interview remote engineers effectively is a critical step in choosing the right candidate to join your company. Hiring the wrong candidate can set your project back, eat into your bottom line, and frustrate your team. Shannon Shaper, who helped fine-tune Google’s recruiting process, says that “hiring is the most important thing you’ll do as a business.” We couldn’t agree more. Yet, the people put in charge of hiring rarely have specific experience in conducting remote software interviews! This makes the hiring experience stressful (for them and the candidates) and ineffective (for the company).

So it’s really no surprise that many companies have jumped at the idea of handing over the hiring process to an algorithm. Unfortunately – to date anyway – no algorithm can consistently choose the best candidate for your role. Algorithmic methods do not factor in enough variables. In many ways, we wish they could. We’re a tech company first and foremost. We’ve built all our internal systems from the ground up, including our own skills test app and task and project planning platforms. A 100% algorithmic solution would be cheaper and faster.

But it would be less effective.

Right now, the single most powerful option you have for finding the right candidate is a  one-on-one remote interview. In this article, we’ll dive into what the initial interview screening should look like in order to be successful. We’ll explain the interviewing process that allows us to determine if someone is suitable for a role, as well as how they stack up against other candidates. It’s a process we’ve developed over the last 10 years, and it’s the one our talent team still uses day in and day out.

Our Interviewing Process

There are many ways to interview a remote candidate. And while we strongly believe the interview is the ultimate hiring device, we have a very specific philosophy about how to do this – one that differs from many other big players in technical recruiting. Google, for example, is a proponent of the standardized interview process where all candidates answer the same questions and are scored the same way. This makes it easy to compare and contrast candidates. At first blush, it sounds fair since everyone is judged on the same criteria. But standardized testing has many drawbacks. For example, Google candidates study for the interview, rather than for the role. This way you hire great test-takers, but not necessarily great developers. More importantly, for us anyway, standardized tests don’t provide a full picture of a candidate’s unique skills, motivations, and experiences that make them a great fit for the role. We believe that these qualities are integral to a candidate’s success in a role.

Unstructured interviews, on the other hand, generate qualitative data through the use of open questions. A respondent can talk in-depth, choosing their own words. This helps the interviewer develop a real sense of a person’s understanding of a situation. The problem interviewers often face with this approach is the long-form responses make it hard to compare candidates.

That’s why our philosophy sits somewhere in between both of these approaches. Let’s pick up the interview process from the Candidate Shortlist. This is the list of remaining applicants after our team has filtered for skills, location, and budget. We start by scheduling interviews with the top 3-5 candidates.

Step 1: Ensure the Candidate has Everything they Need

Start by making sure candidates have everything they need to prepare for a virtual interview. It’s important to start with this because candidates may be nervous. Showing them the entire process ahead of time will enable them to assess what needs to be done, ask questions, and feel more confident.

Send the candidate an email with instructions (will the interview be video or audio, do they need a coding environment setup) and a calendar invite with the date, start time, max end time, and the conferencing software that will be used (as they might need to install it). Also take this opportunity to discuss how many total interviews there will be, how spaced out they will be, what each one will focus on, and if any will be purely technical.

At Scalable Path, we have three interview phases: two internal interviews and one client interview. The first interview focuses on a candidate’s language abilities, experience, skills, and personality – it’s an initial screening to ensure they meet our basic requirements. This is the interview we will focus on today. The second interview is where we verify a candidate’s technical skills, and the third and final stage is where the client interviews the candidate.

Only successful candidates move forward through each stage. Because our vetting is strict, less than 30% of candidates make it through each phase. This means we offer roles to about 3% of applicants.

Body Language 

Half of human communication is through body language. Many people understand how vital body language is, yet they are happy hiring with just a phone interview! As a remote recruitment agency, we can rarely interview in person. So we use video conferencing to make sure that we don’t miss vital visual cues while interviewing. In fact, we do not hire candidates unless we can video interview them. The reasons for this go beyond body language – video interviewing is also a way to verify a candidate’s identity as well as ensuring they have a stable Internet connection.

Interview Duration 

We try not to enforce arbitrarily short time periods in our remote interviews, as this can result in candidates feeling time-pressured. This is particularly true in coding interviews.

We’ve noticed that processing speed is a separate characteristic of intelligence. Some people simply need more time to produce great work than others. By adding an arbitrary limit to a test you are potentially filtering out great candidates. This phenomenon was elegantly explained by Malcolm Gladwell with a Chess analogy. There are many types of chess games that are played. In the more popular version, you are granted significant time to think through each move. This is the version where Magnus Carlsen reigns supreme. But, if you look at the rankings for speed chess, he is no longer number one. That’s because in speed chess, time is a constraint, and players that can process patterns faster are advantaged.

If a role specifically requires someone to perform under tight time constraints, then – of course – we suggest you test their ability to process information quickly. But this is rarely a role requirement.

On average, our non-technical interviews last around 30 to 45 mins and our technical interviews which involve live coding exercises can go up to 1.5 hours. We record all our virtual interviews, that way we can share them with other members of our team if the candidate applies for a role later down the track.

Step 2: Ensure You, the Interviewer, Are Prepared

Being prepared means applying a uniform framework to all remote interviews, but also doing specific research on each candidate. Let’s look into these two aspects.

Uniform Framework

The #1 goal of an interview is to determine if a candidate is suited to and capable of fulfilling a role. Yep, I know that is obvious, but many software developer interviewers behave counter to this goal.

Common mistakes we see, are talking too much about yourself or the role. It’s hard to find out if someone is suitable if you don’t let them speak! This behavior often stems from the interviewer not being sufficiently prepared and nervously talking to fill time.

This is why we suggest creating a list of questions (the aforementioned framework) to keep you on track. In the case of a Scalable Path interview, we assess a combination of the following:

• Logistical suitability (right time zone, availability, price)
• Technical capability
• Seniority and leadership qualities
• General cognitive ability
• Core values match
• Communication ability (post-interview)
• English language fluency (post-interview)

We go in with this list in front of us, and make sure we cover every item during the interview.

Candidate Research

There are several reasons to carry out (and reference in the interview) research on your candidate. It shows you are taking them seriously and that you are a diligent professional, which reflects well on the company as a whole.

We like to look at a candidate’s GitHub, StackOverflow, LinkedIn, resumes, work samples, references, and results from coding challenges. (You’ll need to ask for all of this ahead of the interview of course). These platforms are a great way to build up a composite of your candidate’s technical background.

Start with how long they have been a developer, note their relevant experience and roles. You don’t want to waste time in the actual interview covering data points already collected. Instead, look for areas that are ambiguous or need more clarification. For example, we might ask: “I noticed on your LinkedIn account that you worked as a Senior Fullstack JavaScript Developer with Z-Corp for 3 years. At what stage was the project when you joined? How did your role and responsibilities evolve throughout your time there? Can you give me an example of a complex problem that you had to solve in that job?”

A large part of the interviewer’s role is to read between the lines to identify if a candidate is honest and press for detail when in doubt. Properly researching a candidate beforehand will help you to do just this!

Step 3:  How to conduct a remote interview

Introduction

Take the time to let the candidate settle into the interview by introducing yourself, the project, and what you’re looking for. We’re aiming to make the candidate feel comfortable enough to open up and act naturally.

To help set this up, we’ll start with some easy questions:

1. What are you currently working on?
2. What attracted you to this project?
3. What are you looking for in your next role?
4. What technology or area really excites you at the moment?

From this point on we will start following the framework we previously put in place to make sure we tick off everything we need.

Logistical Suitability

It’s good practice to (re)check that a candidate is a good logistical fit – because circumstances change quickly. To do this we’ll ask questions like “How much notice do you need to give to your current client?”, “How many hours per week do you have to devote to this project?”, “Do you have any other projects on the horizon?” and “Can you work within the business hours of this time zone?”

Technical Capability

Next, we determine if the candidate is technically capable of doing the role. Here are a series of questions that help to determine this:

1. What are your main areas of expertise?
2. How much experience do you have with this client’s stack?
3. Have you had any clients in the same industry?
4. Have you worked on any similar projects?
5. Have you solved a similar problem before?
6. What has been your favorite or most challenging ‘insert tech’ project?
7. What do you like about this tech and what do you dislike?
8. What is better ‘insert tech’ or ‘insert tech’?
9. Are you stronger on the frontend or backend?
10. What are you most excited about at the moment?

WHAT SHOULD A GOOD ANSWER INCLUDE?

A great answer would be an explanation of how their previous experience, problem-solving, and skills are relevant to your project, and the challenges your project is facing. We are looking for how well the candidate understands the business needs, and what knowledge and experience they can draw upon to meet these needs. Sometimes a strong candidate will explain how they solved a completely different problem but how a similar approach could be applied to this project.

Answers to the more abstract questions on our list will help you get an idea of what technologies really excite the candidate, what they are interested in learning, and their technical strengths and weaknesses. What is good or bad will depend on the role, but it’s a great way to get candidates to open up. Who doesn’t like talking about their passion? We find that when someone has a strong opinion about a topic, it’s a good indicator they are passionate about it.

SENIORITY & LEADERSHIP QUALITIES

While leadership skills may not be required for all roles, it’s important to be sure that the candidate has the experience and character to fit into the hierarchy of the hiring company.

Here are a series of questions that will help you determine this:

1. When have you had to manage a client’s expectations of cost, time, and quality?
2. Is there a time when you have had to step up into a leadership role?
3. Has there been a time when you’ve had to get your client or team on board for an idea to solve a problem?
4. You need to deliver a task, and you don’t have the time to do it – what do you do?

What Should a Good Answer Include?

A good answer should demonstrate how the candidate could step into leadership roles, contribute, and step back once the need for their specific skills has passed.

The answer should also show how the candidate cares about the projects they work on and has the initiative to speak up when they have ideas. Being afraid to ask questions is not a trait you want to miss as it can be indicative of a poor team player.

GENERAL COGNITIVE ABILITY

In this section, you are looking for how well a candidate learns and adapts to new situations and technologies. Great remote developers are usually excellent self-learners, so being able to identify this quality in a candidate is important.

“The best are generally the best because they aren’t typical. Because they came at things from a different angle that gave them a unique perspective, which happens to provide more insights than the widely-distributed approaches.”

– DHH

As the interviewer, you are trying to look for specific desirable characteristics. Every programmer will experience a situation where he or she doesn’t know the answer. Great programmers will find relevant resources, talk to the right people, and find solutions on their own. A great way to see if your candidate has these characteristics is to ask for examples of how they have solved hard problems in previous roles.

1. Is there a time when you’ve had to pick up new technology quickly or solve a difficult problem?
2. Has there been a time when you have had to think of an out of the box idea in order to solve a challenging problem?
3. What’s the biggest challenge you’ve had to solve?
4. Are you working on any personal projects?
5. Are there any new skills you are working on?

What Should a Good Answer Include?

Someone who has created interesting solutions to difficult problems will share details about the problem, the solution, and why it worked. If someone is just implementing solutions that they didn’t come up with, they will struggle to share these details.

Great developers often learn new coding languages by practicing on side projects, try to dig into these side projects to get an insight into how the candidate chose them and how far they got with them.

Core Values Matching

It used to be commonplace to assess candidates for character or cultural fit. However, this has fallen out of favor because selecting candidates based on an undefined notion of culture can lead to a tribal mentality. In other words, interviewers hire people that they feel a kinship towards. This approach hinders diversity in the workplace. There are a whole host of wider societal reasons why this is not recommended. But, if we stay focused on business reasons, a diverse workplace is a more creative workplace.

Instead, we assess how a candidate matches our core values:

1. Honesty
2. Caring
3. Competence
4. Transparency
5. Work-life balance

Now, of course, directly asking someone about their core values isn’t an effective approach. “Are you honest?” “Yes”…

We find these more general questions to be more effective:

1. What has been your favorite workplace and team dynamic?
2. Do you prefer startups or more established businesses?
3. What has been your favorite client to work with?
4. Do you have much experience working on projects with a lot of ambiguity?
5. How have you dealt with difficult clients and team members?
6. What are you looking for in your next role?
7. Where do you see your career in 5 years?
8. Has there been someone you looked up to in your past roles?

What Should a Good Answer Include?

This is what we look for in a candidate for a Scalable Path role:

• They are happy and comfortable working in a startup with a moderate degree of ambiguity.
• They are looking for the opportunity to lead projects, take responsibility, and accept accountability.
• They appreciate honesty and teamwork in their peers.
• They have shown competence in difficult situations.

Interview Wrap-Up

The last part of the interview is an opportunity for the candidate to ask the interviewer questions. It’s important to remember that this is not an interrogation. The candidate is interviewing you as well. So, not leaving any time for candidate questions is a good way to frustrate the candidate. We like to set aside 5-10 minutes for these questions.

Step 4: Post-Interview Analysis

Once you have ended the call with the candidate, it’s important to make notes while everything is still fresh in your mind.

Communication

It takes strong communication skills to understand problems clearly, break them down into hypotheses, and propose solutions in a coherent manner.

To assess this post-interview, it’s helpful to ask the following questions:

1. Did they answer the questions clearly?
2. Did they need regular prompting?
3. Did they understand the client’s needs, and could they frame their answers to meet those needs?
4. Did the candidate ask questions? If so, did they listen to answers intently or interrupt?
5. Was their body language and presentation appropriate?

When answering these questions, consider whether your understanding of the role may have had an impact. For example, did you explain something poorly because you didn’t understand it?

English Skills

We require all candidates to speak fluent English. Our clients speak English and it’s the defacto language in the tech world. Most documentation and developer interactions are in English. So if your candidate does not speak and understand English they’ll require interpreters and translators – which is problematic.

We categorize the levels of English into the following:

1. Basic
2. Might be problematic
3. A few little problems but acceptable
4. Fluent with an accent
5. Native

Final Thoughts

Phew, that was a long article! But hopefully, we’ve given you some helpful tips on how to conduct an interview effectively to hire remote software developers. Interviewing and hiring people is the most important thing you do at a company so it’s important to be prepared. Our final piece of advice – before you go and make your best ever hire – would be that conducting a job interview is nuanced. It’s going to take you a while to get the hang of it, no matter how many articles you read.

Let’s quickly recap the key takeaways:

• Ensure your candidate has all the information they need a couple of days ahead. A prepared candidate is a more relaxed candidate.
• Make sure you have done your own research on the candidate so you don’t spend time asking easy questions, but instead can dig deeper.
• Create a framework for all your interviews and stick to it. This will make sure you cover all required areas, giving you not just a complete picture but one that can be used to compare and contrast candidates.
• Remember the interview is not an interrogation. Allow time so that the candidate can ask questions.

Are you looking to hire a remote developer? You’ve come to the right place, every Scalable Path developer has been carefully handpicked by our technical recruitment team. Contact us and let us know what your needs are.

Editor’s note: This article was originally published on September 3rd, 2015, and was updated on March 31, 2021.