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.
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.
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.
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.
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:
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).
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.
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.
Hiring is not easy, and even less so for a remote-working company. Here's how we did it.Read full article
Competition to hire developers for all sorts of companies is at an all-time high. We've had no problem hiring in our three years running the company. Here's our opinion on the matter.Read full article
Having a strong company culture sets the expectations for future hires and lets them know in advance how's your day-to-day like in your company. In this post, we explain how our company culture has helped us to hire faster and better.Read full article