The Subtle Art of Interviewing an Offshore Developer

As part of my business, I get to interview offshore developers regularly, for all kinds of positions and projects. These interviews definitely have some quirks to them that you won't necessarily find when interviewing in-house candidates.

Most interviews usually take place over Skype and the like. By their nature, virtual communication forms tend to limit human interaction and hurt the flow of the conversation. Not to mention technicalities like delays and bad connectivity, which, combined with language and cultural differences, allow plain conversations to lose a lot of their effectiveness for evaluating candidates.

Additionally, the position requirements are quite different. Communication and time management skills are given much more weight when it comes to evaluating an offshore developer. You do not have the luxury of constant interaction and supervision over what's going on; you need someone who you can "unleash" without them going rouge. You need someone who can communicate his progress, raise a red flag when needed and have the decision-making ability to switch tasks when appropriate.

In the next few paragraphs I'll share tips, methods and the steps I take when interviewing. Hopefully you'll find some useful information that will help you avoid the pitfalls of recruiting an offshore developer.

Pre Interview

Before the actual interview, it's worth it to take a few minutes to go over the candidate's CV again (assuming you already did that for the initial screening). I usually don't take CVs too seriously, at least, not for the obvious reasons. By reading between the lines, a CV can tell you a lot about the candidate and help you to get the initial feel for what this person is about.

One thing I've noticed is that there's an obvious correlation between the "textual clutter" in the CV and the quality of the candidate. Some common "tell" signs I usually see in CVs are, for example, repetition of sentences, specifying minor technologies as skills (html, css…), and redundant or insignificant information.

This does not only point out a general lack of experience but also reflects a lack of crucial personally traits such as attention to detail, professionalism, and thoroughness.

I also like to check their social accounts (Github, Stack Overflow…), it gives me a general overview of their expertise and what type of projects and technologies they're into.

Conducting the Interview

As a software developer myself, I am familiar with how stressful it can sometimes be to be interviewed, so I always try to create a relaxed and fun atmosphere. Making the candidate feel comfortable is key for having an effective interview.

I usually start off by introducing myself and asking the candidates a few questions about themselves. This takes a bit of the pressure off and helps them to open up. If I get the chance, I always try to slip some jokes in.

Being in this relaxed state of mind and friendly environment usually leads the candidates to share their background and some interesting facts about themselves.

Once I have a better idea on the candidate's background, I usually follow up by asking about their last project, or one that they're proud of. In case I have a particular interest in a project they listed in their resume, I will ask about that.

Asking about previous projects is helpful to get an understanding of their roles and responsibilities in the project. The definition of Senior, Middle and Junior developer seem to be pretty loose and often varies depending on the country and who you talk to. It's important to establish the level of experience as soon as possible as it will determine whether you should cut the interview short or continue to the more technical stuff.

Once we've established that experience on paper, my favorite way to continue the interview is by having the candidate share their screen and walk me through the code. This method has proven to be quite effective when dealing with offshore developers, as it helps minimize the language barrier and places focus on practical experience.

I'll ask the candidate questions about the project, it's propose, the architecture of it, and why he chose to implement some parts the way he did. Occasionally, I'll ask him to choose a section or a class and explain it to me, line by line.

Where this is an opportunity to test their knowledge of the particular technology in question, it is also aimed at helping me understand their technical communication skills. How clear they can pass on an idea? How well can they communicate their thought process? These are things that are crucial to look for when dealing with offshore developers. This is unlike our chat at the beginning of the interview, which its main goal was to break the ice.

It is not unlikely that we'll reach a part of the code that the candidate is not able to explain. This is a priceless opportunity to test their problem-solving skills, and I'll suggest them to see if they can Google their way to the solution. Watching them research and trying to wrap their head around the issue, live, has an immense value and gives you a glimpse to a real world scenario.

Common "Mistakes"

I'd like to point out a couple of common concepts that I find to be non-effective and can even sabotage your goal of finding the perfect offshore developer.

The test project is a commonly used method to screen potential candidates by giving them a "home assignment" to complete before the interview. Firstly, by requiring a test project, you are risking being perceived by developers as disrespectful of their time. Many accomplished developers that think highly of themselves (which are the ones you're after) are likely to turn down a job offer just for that reason alone. Secondly, in order for a test project to be effective, it needs to be rather complex, which would inherently take quite a long time complete — too long to be fair. A better way to evaluate the developers' level of work on a real-life-like project is to use a project, the one that you are aiming for them to work on. As in just start working together and roll from there. Which leads me to the next point — probation peiod.

The probation period is a predefined scope of work that once complete, would be used to determine the future of your engagement with the developer in question. The probation period itself, as a concept, isn't a bad idea — communicating it to the developer is. There is no real reason to let the developer know that he's on probation. As with the test project, it can lead developers to turn you down, amongst other things. A much smarter way is to approach this legally, and have a contract that is flexible enough to let you end the engagement at any time if either of the parties aren't happy. After all, being bound to work together, isn't good place to be for anyone.

Conclusion

Interviews are your chance to test the waters before hiring and investing crucial time in training. Hence, you want to lower the surprise factor. This is even more emphasized when it comes to offshoring. In order to make the most out of your interviews, know what you're looking for and to have system in place to help you test it out.

• Use the CV as a tool to predetermine the candidate's personality. Watch out for "textual clutter" and common "tell" signs.
• Create a relaxed and fun environment to make the most out of the interview.
• Establish the level of experience as soon as possible, It'll have an immediate effect on how you choose to continue the interview.
• When testing technical skills, favor the practical approach over conceptual discussions, it'll help you minimize the language barrier and technical difficulties.
• If you can, create a scenario where the candidate would need to use his problem-solving skills - It'll produce some priceless insights.
• Drop the test projects and probation periods, they might cause you to miss on some talented developers.

Find more about me at maketech.io.

~ Yohai Rosen