How to Interview a Ruby on Rails Developer

The obvious stage of hiring the web developer for your project is the technical interview. For the company, it is a way to find out if the technical background of the candidate suits the company’s needs. For the developers, it is an opportunity to check and demonstrate their skills, and find out their strong points and areas for improvement.

Are you going to conduct the Ruby technical interview with a developer in the near future? Then you will definitely find this article useful.

We will tell you about the main points to consider when preparing and conducting the meeting with an applicant. You will also learn about the different techniques of checking the candidate’s ability to cope with the practical task.

To code or not to code? That is a question. Of course, we mean asking the developer to write a sample code during the interview. You will learn about the pros and cons of this practice.

If you decide to check the candidate’s live coding skills, we will give you some tips on how to make this process less stressful and more efficient for both parties. If you’d rather avoid doing this, we will offer some good alternatives.

Since the technical interview is a really important and stressful experience, it is natural that both parties can make mistakes. Unfortunately, sometimes they lead to a wrong decision regarding the candidate. In this article, we will cover the most common mistakes and give some tips for you to avoid them.

The importance of the interview

In order to better understand the importance of the technical interview, let’s briefly consider the stages of hiring the developer:

• Request

The recruiting department receives a request from a project manager to hire a specialist for a certain scope of tasks. The project team defines the requirements of the developer: the level of seniority, knowledge base, practical skills, tasks on the project, etc.

The goal is to precisely define the requirements for the candidate.

• Search

This is the responsibility of the recruiting department. They create the description of the vacancy for the job sites, and look for the candidates in the communities, freelance marketplaces and social networks like LinkedIn. The recruiters handle communication with the developers by telling them more about the company and the project. If the candidate asks specific questions about the project that are outside the recruiter’s competence, they consult the technical specialist or the project manager.

The goal is to find the relevant candidates for the interview stage.

• Pre-screening

This is a stage of analyzing the potential candidates’ CVs to determine if they meet the basic requirements. The recruiters contact the developers in order to tell them more about the company and the project, and to determine their experience and competence. For the candidates who seem to be suitable for the position, the recruiter writes a brief summary for the technical interviewer.

The goal is to select the candidates with the most relevant skills and experience for the interview stage.

• Interview

This is the key part of the hiring lifecycle. During the interview, the candidate meets the technical specialist (usually it is a senior developer or team lead) who is to estimate his or her technical background.

The goal is to find out if the knowledge base and skills of the candidate meet the requirements of the project.

• Feedback

After the interview, the technical specialist gives the feedback regarding the candidate – his strong and weak points, areas for improvement, etc. – and defines if his hard skills meet the requirements.

The goal is to select the most relevant candidates for the further stages.

• Final decision

Having passed the technical interview, the client is invited to the final interview. Generally, it is handled by the C-level officers, or the heads of the department in large companies. Sometimes, the final interview can be handled by the client for whose project we are hiring the developer.

The goal is to assess if the client will suit the company or the team.

Now you are aware of the full lifecycle of hiring a software developer, and the importance of the technical interview becomes clear. It helps the company to save time and money by correctly assessing the developers’ levels and choose the right candidate for the project tasks.

How the interview is conducted

The technical interview is usually handled by a senior developer or a team lead. In some cases (for example, if it is a junior position), you may give this task to a middle developer. The main rule is: the interviewer’s grade should be higher than the candidate’s.

There are no general guidelines on how to interview a Ruby on Rails developer – each interviewer applies the different techniques or methodologies that seem most efficient for them.

For example, some interviewers ask the developers to write a sample code during the interview. Others find it useless, as the interview environment does not resemble the usual working conditions of the developer at all. Different interviewers choose different questions in order to test the applicant’s theoretical knowledge.

Preparatory stage

The interview requires some preparation, not only from the applicant but also from the technical specialist. The interviewer should study the information about the candidate in order to prepare the relevant Ruby interview questions and practical tasks.

If the company is looking for a developer for a certain project, the interviewer should work in this team and be aware of all the technical details. The practical task should also correspond to the candidate’s future project tasks.

The process of the interview

As we have already mentioned, the technical interview involves checking both the candidate’s theoretical background and practical skills.

Stage 1: Theoretical

In the theoretical part, we ask some questions to check the candidate’s general knowledge of object-oriented programming. For example, we may ask him to analyze some classes that comply with OOP single responsibility principle or violate it.

Then we move on to the more specific Ruby on Rails interview questions. We may check the applicant’s general understanding, or his syntax and knowledge of the basic library, or ask him to describe the uses of basic commands. In the Rails-related part, we may ask the candidate to analyze some gems and describe their possibilities.

We obviously check the applicant’s proficiency with database management systems, generally asking them to describe the process of performing the query.

One of our requirements for the Ruby on Rails developer is familiarity with the integration testing process and Git workflow. We check their knowledge of TDD concept and familiarity with the basic testing tools that we generally use in our work: Capybara and RSpec. Some questions are dedicated to managing the repositories in Git.

Stage 2: Practical

During the practical task, we always ask the candidates to demonstrate their ability to work with the code. This does not necessarily involve life coding – we may give the applicants a ready piece of code and to ask them to refactor it, or just to explain how would they improve it.

It is still a questionable point whether it is worth having the candidate write the code during the technical interview. There are lots of arguments for and against this practice, and now we will consider its pros and cons.

Should you ask the candidate to write a piece of code?

The main supporting points of this issue are that live coding allows you to understand the candidate’s way of thinking, see his programming style, and determine his ability to work under unusual conditions.

Those who are against live coding say that the atmosphere of the interview does not resemble the usual working environment of a developer at all. The interview is generally stressful, and the applicant does not have time to think about the task or google some unclear points.

In our opinion, the practical task should always be included in the interview since the theoretical questionnaire may not reflect the real abilities of the candidate. We also practice live Ruby coding exercises.

Yet, in our technical interviews, we do not expect the candidate to produce a perfect code on the spot. For us, it is obvious that in order to produce his best work, the developer should have more time and a calmer environment. However, live coding helps our technical interviewers see the way the applicants think, work with their code, navigate the text editor, etc. If the candidate gets flustered, our interviewers may offer their help, or to complete some part of the task together. In this way, we may also see the developer’s ability to work in a team.

It is up to you to decide whether you will ask your applicants to code during the Ruby interview. Coding exercises are essential if you are seeking a Junior developer. For Middle/Senior positions, you may offer some alternative variants of coding tasks.

How do you avoid asking candidates to write code?

For example, instead of coding right now, you may ask your applicants to present a piece of code from one of their recent projects. However, usually, the projects are protected by NDAs and the developers cannot disclose any parts of the code.

Your candidate may have an account on some open-source platform like Github. If he can provide the code from the open repositories, you are welcome to discuss it during your interview.

Also, you may give the candidate the code yourself. Ask him to refactor or somehow improve it. The developers have to work with the code of their colleagues, and it is a good way for you to check their skill. For you, it is not even necessary to have the candidate actually refactor the code – sometimes it is sufficient for the developer just to explain how he would work with the code.

Feedback

Upon completing the meeting with the candidate, the interviewer makes a brief summary of the candidate’s skills. Here is a way you can do it:

• Define a grade

It’s not a secret that different companies have different criteria for defining the level of seniority of their developers. So, according to the standards of your company, how would you estimate the level of proficiency of this particular applicant?

• Define the strong and weak points of the candidate

Did the candidate reply perfectly to all the questions about the database management system, but have some blank spaces in their knowledge of the testing process? Say this in your feedback. According to their performance, define the areas for improvement – this will be particularly useful if you decide that the candidate did not pass the interview.

Let’s see an example of an interviewer’s feedback:

The applicant has answered all the questions for the middle level, and even some of the starred ones. He understands the basic principles of the architecture design. During the practical part, he demonstrated analytical thinking and the right approach to solving the task.

We recommend he improves his knowledge of databases; however, his average level is okay. There are also some non-critical blank spaces with Rails.

To sum up, I would recommend this candidate for the final interview.

The most common mistakes and how to avoid them

Since we are human beings and interview are generally stressful, both the interviewer and the applicant can make mistakes. Usually, the mistakes are minor, but sometimes they may lead to making a wrong decision regarding the candidate.

Generally, the mistakes during the interview may be subdivided into two major groups:

Psychological mistakes

Generally, they concern the interview forming a wrong opinion of the candidate.

• First impression

Generally, people form a first impression of a person during the first seconds of the conversation. Neither positive nor negative first impression should affect the way you conduct the interview or your final decision.

• Contrast

If one interviewer has several meetings with different candidates, he may unintentionally compare them with each other. This should only be done at the final stage when you need to choose one applicant from two or three people.

• Reality effect

The interview is a stressful situation and even skillful candidates may get nervous and make mistakes they would never have made in their ordinary working environment. The task of the interviewer is to lower the stress factor by creating a calm and friendly atmosphere.

The aforementioned mistakes are the result of the human factor and all of us can make them. Yet, when conducting numerous interviews, it is possible to minimize the effect of the psychological factor and create the appropriate environment.

Technical mistakes

These mistakes do not concern the technical background of the interviewer or the candidate, but the way the interview is conducted.

• Lack of planning

The interviewer should not improvise and should have a precise plan with a list of questions. Otherwise, there is a high possibility that something will be forgotten.

• Loss of information

If the interviewer does not take notes during the meeting, useful information may be forgotten or lost. This loss of information will make it impossible to thoroughly analyze the conversation later.

• Lack of criteria

In order to assess the candidate correctly, you need to have the criteria for assessing. This will help you to choose the most appropriate questions and to evaluate how well the candidate answers them.

• Hurrying

The interviewer should not assess the candidate straight after the meeting, even if the performance was perfect or obviously weak. After the technical interview, communication with the applicant is handled via the recruiter or HR specialist. Thus, they are the ones who will tell the candidate the final decision.

Conclusion

In our article, you have learned everything about conducting a Ruby technical interview with a developer. Let’s summarize the main points:

1. The interview is usually handled by the Senior developers. If you are seeking a Junior or Trainee developer, you may delegate this task to a Middle specialist. The general rule is that the interviewer’s grade should be higher than the applicant’s.
2. When preparing for an interview, you should pay close attention to the preparation. Find out or define the basic criteria, and choose the appropriate questions that will help you to reveal the applicant’s proficiency.
3. It’s up to you to decide whether you will ask the candidate to write the code or not. The proficiency of the interviewer will make the process of live coding less stressful. At the same time, there are lots of exercises that can help you to avoid this procedure – for example, you may give the ready code to the applicant and ask how he would improve it.
4. During the technical interview, both parties can make mistakes. We have described the most common ones. Hopefully, it will help you to avoid them.

Finally, we recommend you conduct the interview in the way that seems most appropriate to you. Applied professionally, each technique will help you to make the right decision.