How To Hire Remote Developers Successfully

There are many aspects to consider when you want to hire remote developers: the candidate’s technical and soft skills, the region where you hire, how to find a developer, hiring format, and many more. Here, we’ll talk about what a developer needs to work efficiently in the remote format, as well as how to check if this work is efficient. 

Ask an HR manager about what is important for a remote developer and most likely you will hear that this person should be independent, organized, self-disciplined, structured, etc. That sounds reasonable, but what hides behind these names in reality? Let’s take a thorough look at the candidate requirements from a practical perspective. 

Essential Skills for Remote Work

It is important how a person deals with the given task: how a person accepts it, informs about intermediate results and issues faced within the accomplishment, how they manage the terms and timeline, and how they present the result of work.  

Let’s focus on each of the stages in detail.

Task Acceptance

It is a bad sign when a person asks no questions, nods, but starts asking questions in the chat half an hour after the initial meeting.  An ideal situation is when a developer says “everything is clear” and gives back the results of work; however, it is a rare case.

A good sign is when a candidate tries to digest the task, expressing the understanding of the task to be addressed in his own words and modeling it in his mind.

The main focus should be on understanding: the ability of a person to comprehend the task and chances to fulfill it in due time. Forecast the potential obstacles and inform about them beforehand without making the process of further communication a nightmare. 

Informing About Progress and “Impediments”

It is important to analyze and evaluate the actions of a developer when issues and obstacles are faced within the fulfillment of the assigned task. We can divide the developer’s reaction to emerging difficulties into three categories below.

1. A person stops doing anything and waits.  
2. Working outside of the development team he starts to address issues at his own discretion stepping aside from the initial assignment and spending a lot of time.
3. The developer starts asking thousands of questions.

All three cases are bad. 

The worst-case scenario is when a developer attempts to resolve the situation without discussing it with the team. Much time is spent and you are given the results you don’t need, and everything should be done from scratch. 

The second one in terms of severity is the case when a developer doesn’t undertake any action and soon you understand that nothing has been done. It happened because he was blocked by the absence of backend, API, or anything else that doesn’t eventually matter at all. The developer decided that the best he could do would be to flag the issue during the next daily meeting. By doing so, he wasted time and put the project’s timelines at risk. 

As for the third story, objectively, it is not that terrible. It occurs when a developer starts throwing plenty of minor questions to the team, which may force the key team player (lead or architect) to micromanagement. This provokes micromanagement which is always harmful. 

These are the three foremost things to beware of, and we haven’t yet discussed a developer’s performance, qualification, knowledge, etc. We are simply evaluating a person in terms of soft skills and some understanding that in the future he needs to work in a team but not in isolation.

Reporting the Results Obtained

Pay attention to how a remote developer hands over the results of his work:

• A person accomplishes the task and keeps silent until he is asked.
• A person accomplishes the task and informs you about it, you start checking and it appears that “everything is done, but …” meaning a number of minor things that should have been clarified independently.
• A person accomplishes the task and schedules a short call to demonstrate the results, informs about the minor issues if there are any, and prepares a short integration manual if needed.

The third variant is preferable. For you, it will save time on management, for developers – on the integration of the work outcomes, especially within the remote collaboration. 

How We Can Evaluate This

Unlikely we can evaluate the above-mentioned traits of developers at the interview level. However, the test task will clearly reveal all of them.  A test task is a great example of goal setting. If at the goal-setting stage, a developer doesn’t ask additional questions, most likely he is inexperienced. You will face issues with this developer.

For example, if giving a task to a developer, you tell him, “Any questions, talk to me.”  He doesn’t but instead returns with something you don’t need, declaring that “I haven’t understood,” and makes it pretty straightforward what person you are dealing with.

Another situation could be if a developer made a list of questions to a coding task, got back to you, and got the answers. As a result, he fulfilled the task and informed us that it couldn’t be done in the way you required. The thing here is that people make coding tasks for one another, and someone could accomplish the tasks for your candidate. To be on the safe side, it is better to ask a candidate to present his task.

Attention should be paid to how communication is held, not a code quality itself. We are talking about task acceptance, comprehension, and giving back the result. This is something you can fake and the person will do everything by himself.  Mind that this shouldn’t be live coding, but a test task for 4-6 hours. It contains a work statement: description, followed by a call when a developer can ask questions, and a handover–work presentation. 

Important note: don’t mix a test task and a wish to get a piece of work for free. Test assignments should aim at revealing certain features of a developer, nothing more. Why would you need a cobbled-together piece of a project?

What Else To Pay Attention To

Level of a Developer

Middle developers and developers of the lower levels of seniority can face issues with remote work. In practice, everything depends on the inner character of a person. It is worth keeping in mind that not only qualification but also experience differentiates a middle developer from a senior.

Experience gained by a senior developer helps him address typical issues faster, while a middle developer facing the same issues will spend an extreme amount of time (not only his but time of other team members). Middle developers need assistance. Providing this help remotely is more complicated rather than in-house.

We are talking not about qualification, but about experience. Namely production experience helps developers do some things with minor effort, and the right thing is to flag this.

However, experience doesn’t always come with the level of a senior developer. Senior developers differ. There are professionals who can work absolutely independently and perform the key project functions, and sometimes a senior is a good specialist. However, he can lack experience in terms of self-organization as he always played the role of developer only. In this case, he should better become a part of the team where he will demonstrate his maximal efficiency.  

Performance

Performance is the accuracy of meeting the planned production estimates for a certain developer. If a person implements the features 30-50% faster compared to an average senior in a vacuum, this is a good, no, amazing performance. 

The remote format of work is tightly connected with performance because for some people, remote work results in performance increase and for some vice versa. Why? Some people have enough self-discipline and some don’t. People from the first category don’t spend time preparing, commuting, having coffee chats with colleagues, and they are not distracted from their work “to take a look” or “for a piece of advice”. Working remotely, they show much higher performance compared to working in the office. The second category includes specialists with many parasite activities during the day and issues with time management, therefore their performance decreases. 

The bad thing is that it is quite difficult to define this at interviews. 

Screening and monitoring tools that track activities and time also don’t solve problems. Everything depends on mentality: some are ready to work under the tool supervision, some don’t. However, if a developer is not ready to work with these tools, it doesn’t mean that he is a bad developer. There are people willing to have a staggered schedule: freedom to have some rest right here and right now. They don’t want to be questioned why they didn’t work from three to four. They can easily work from six to nine in the evening and make this time really effective. 

You should learn to read between the lines. Give a developer a chance to reflect on what he considers to be good and evil; what is acceptable for him in working remotely. Learn what a person likes and dislikes. If a developer says: “I like that I don’t have to move around the town and spend time on this,” this is a normal reaction. If a developer declares: “Oh, I love complete freedom, I can work from any place where I have some horizontal surface,” be sure there is something tricky behind this. We wonder how he is going to work from picnics and beach beds.

Habits 

Martin Flower, one of the software development gurus and author says that there are no good and bad software developers, there are developers with bad habits. 

What is that supposed to mean? It means that if you have a methodology for how to arrange your work right, your result won’t be bad and outstanding. That is to say, if a developer clearly understands the task, properly communicates with the manager and the team, follows best practices, it is unlikely to expect many bugs and low performance from him. I practically haven’t seen such people.

Habit #1: Ability to Design Code

Software developers have dedicated literature describing how to design the code right. The important thing here is to design, but not simply write.  

Any task should be designed beforehand: decomposed to atomic parts (subtasks), understand what issues and problems might be faced. Accordingly, people who don’t do so and don’t foresee issues have no questions about a new task. They simply start implementation. The professionalism of a developer involves studying the given task and saying that something can’t be realized for certain reasons. 

Habit #2: Ability To Follow Best Practices

There is good code and there is bad code. All the professional literature teaches how to write the code right: following certain templates and rules: the so-called best practices. It is preferable to hire remote developers who are able to follow them. It can take much more time, but this code is easier to work with later on: easier to scale, easier to hand over to other developers, easier to review. Ultimately, writing is faster as well. 

It is similar to assembling IKEA furniture. There are people who start putting it together without the instructions. It is not always faster, and it is certainly not more reliable.

Habit #3: Ability To Interact With Others’ Code

This habit includes reading, integrating, making commits, waiting for a commit from somebody else, reusing code written by other developers while solving the tasks, and giving back the results of work in the form of clear components and modules. All of this is extremely important for you not to waste time debriefing afterward. 

The developer’s habits make him a highly qualified specialist. Say you hire two identical software developers: one follows the rules taught by the whole industry and the second one doesn’t. It’s like wearing safety glasses at a production facility because it is required by safety regulations. Of course, you may not wear it, but there is a risk that eventually you will end up having less than two eyes.

Cheat Note

Now you know how to hire remote developers. Let’s recall what we have discussed.

The essential skill in remote work is how a developer approaches the given task:

• How he accepts: Does he analyze it before implementation and ask additional questions?
• How he communicates progress: When and how flags issues, does a developer offer alternative solutions
• How gives back the results of work: Whether he informs about the details worth paying attention to, degree of readiness of the results for use/integration.

All this can be checked with a test task. It is better not to make it a long one: a 4-6 hour task should be enough.

Also pay attention to:

• Seniority level of a developer: Candidates of middle and lower levels can face problems due to lack of production experience.
• The motivation of a developer to work remotely and how it will impact the efficiency of work
• Habits of your developer: How close are they to the habits of the “right” software developer? 

Good luck hiring your best remote developers.