How we interview developers

Every week, we're approached by ten or fifteen different companies who need to hire developers.

After having serviced dozens of different companies, ranging from big corporates to one-man startups, we can share a bit of our secret sauce. In this blog, we will talk about how we interview them.

All these companies find us through recommendation, through our blog, or even attending events. We receive lots of cold introductions from people we barely know but seem to hold us in high esteem for our development knowledge.

And, of course, we're developers, we hire developers and help our clients do it. We have been growing a development consultancy for five years now, so it's only natural that people entrust us with this, or at the very least, they want to know how we do it to learn from us.

A first screening call

Before I jump into the hiring process to interview a candidate, we have someone else from the team, usually our Office Manager, Bego, to screen the candidates for us.

We schedule a first conversation with them over a videocall platform, such as Google Meet or Skype, because we're a remote-first company, and because we want the candidates to be comfortable wherever they are, at a convenient time for both of us.

We conduct an initial conversation with them to make sure they've read and understood everything from our company and the job offer itself. You'd think everyone who applies has read the actual job offer, but you'd also be wrong!

In this conversation, usually shorter than 30 minutes, we explain what kind of company we are, how we work and what's expected of the person we're trying to hire. Usually, we also go into detail of the benefits & salary right off the bat, because, again, that's also on the job offer, and some people might not have read it.

The interview is conducted in English because we're an English-first company. This way we also assess the candidate's level of spoken English.

Throughout the conversation, we bounce some questions off the candidate to make it more dynamic and to have them speak often, as it might help to relieve the stress and the nerves.

If we see that the candidate is a right fit for the company, we invite them for a second chat.

A second call to talk about tech

The second interview, the technical one, is also conducted through a videocall.

Before starting the technical interview, I explain to the candidate how the process is going to be. I inform them that it will take around 45 minutes, but can be stretched to one hour.

I start by summarising the most important points. I make sure they understand that if they have questions they can interrupt me at any time, and I also tell them that I will evaluate those questions positively.

I honestly believe that making the right question is sometimes better than giving the right answer.

During the whole interview, I do not only listen to their answers but, from time to time, I also give them the answers that I would have given.

This makes the process less aggressive and more conversational. We too start building a relationship of trust. During the interview, you need to both impress the candidate and to make him/her feel comfortable.

These are the steps that I follow - grouped by the most important areas.

Ask about their life experience as a developer

• Ask them why and when they decided that they wanted to be software developers.
• Ask them what have they done before their studies / first work experience as a developer.
• Review one by one all the jobs that they had done as a developer. Only those relevant to the position we are offering. For example, if we want a Ruby developer, we focus on the Ruby experiences.
• What kind of tasks they were doing in the company: bug fixes, big features, code refactor, etc.
• How big was the team they were working with and how were they organised.
• Ask them the most challenging task that they had performed in that job position.
• Ask them to imagine that they were back in the job position, and ask them what things they were doing terribly wrong (from the tech point of view) and how they would improve them with their current knowledge.
• Ask them why they left the company:
  • Pay special attention to the amount of time they worked for a company. Only staying a few months in each company reveals that they don’t have long-term commitment. Having worked for the same company during all his work life means that they haven’t seen enough.

Really important: we give extra points if the developer has worked as a freelance or has created his own business.

Freelancers and entrepreneurs need to learn how to manage their time, have worked in different projects with different companies and might have experience working in a remote position.

Also, they don't take their job for granted and are more accountable if things go south.

Knowing how to do remote is essential to us. That's why we prefer this kind of profiles, as the chances of freelancers/entrepreneurs having worked remotely are usually higher.

Having worked in an agency like MarsBased gives extra points, too. Agencies allow you to work on several projects and see more tech stuff that you wouldn't otherwise see.

I see it like this: when you build your own stuff or work in a product company, there are less technical constraints and you've got a greater degree of freedom regarding technological decisions. This isn't the case when working for clients, where they might be restricted to using old versions of Ruby, might not be able to upgrade certain libraries because of incompatibilities or have other restrictions not related to strictly purely technological reasons.

Ask about technology

In our case, we usually ask things related to the programming language we want him/her to do. I'm sharing an example of questions list I've got for Ruby developers:

• Ask them about frontend / backend preference. Try to guess what do they like.
• Ask them why do they love Ruby. And ask them if they would like to continue their career with Ruby and why.
• Ask them what they consider that are the strong points versus the weak points of Ruby and Ruby on Rails.
• Make them compare their knowledge with Ruby with their knowledge of other languages / frameworks.
• Automatic testing. What’s their experience with it. Have they done it in the past?
• Do they participate in Open Source projects?
• What is their weakest point in technology that they need to improve (for example, in my case is functional programming).
• Ask them about their experience with Databases and Search Engines (like SOLR or Elastic Search).
• Ask them about their experience working with Background Job queues in web applications and ask them to give me examples of these in their past jobs (I ask this to know if they have faced asynchronicity).
• Ask them about their degree of experience with deployment systems. We are especially interested in knowing if they have designed distributed architectures in the cloud. We also value if they have experience with AWS.
• Ask them if they have ever done code reviews and how they do it.
• Ask them what's the most important thing that he/she values from well-written code. Possible answers are: understandable, good naming, good performance, etc.

In your case, feel free to tailor the list above to meet your needs.

Then, I ask them some questions regarding code architecture. They are related to specific problems that we find when auditing Ruby code from other companies. We describe the problem and we ask for solutions (eg: fat models, bloated views with logic, etc).

Ask about Ruby specifically

In this section, I enumerate all the tools, external libraries, and other useful resources that we are using at MarsBased. I want to know if they have used the same tools and if they know them, in order to know how fast will it be their onboarding process, or they will require more time to adapt to our tools of choice.

I ask them about the most relevant Ruby libraries that we use and where they use them. Based on their answers, we try to determine their Ruby knowledge.

Personal life and final questions

If the interview goes well, I achieve a certain degree of confidence with the candidate. I usually can ask them about their hobbies and personal life without sounding too nosy.

I like candidates with similar hobbies to the rest of our team members. This will make company communication and day to day life easier. These small things and provide useful ice-breakers for their first weeks in the company.

Remember that we're a 100%-distributed team, and we only meet once every two months. In the worst case, we hire someone right after our last meeting, and we don't meet him in person until two months later.

On a similar note, I also value developers with their own family: living with their partner/spouse or with kids. They tend to have a more stable life and I find that they are more responsible with their time and commitments. But hey, that's just an unsolicited opinion!

I am also interested in how they keep updated with technology. What feeds they are subscribed to, what tech Twitter accounts do they follow, and such. Technology evolves more and more rapidly nowadays, so it's easy to get lost on all the new trends and available tools out there.

Then, I ask them what they are looking for in a company like MarsBased. We speak about remote working at length, in this part. We're going to address this part in more depth in the coming blogs, to make sure the pros and cons, and the unspoken truths of remote working.

As I said in the beginning, I am always open to being interrupted, but in most cases, people like to hear everything first, before firing all the questions. In this case, I ask them to make me some questions now, to see what they are most concerned about.

Finally, I ask them about their salary expectations, if they are in other selection processes and, very importantly, I explain to them how the interview went from my point of view.

At the end of the interview, I explain them my conclusions of their profile - both the positive and the negative points -, and then I allow them to correct me if some of my impressions were wrong. I do this to remove the anxiety that produces to the candidate not knowing how the interview went, and I also give them the chance to point out some things that I could have perceived wrong.