How to design a technical interview for Ruby/Rails programmers?

Posted on Updated

I have learned the most about how the interviewing process could be improved by reading Thomas Ptacek’s blog post on hiring. I first read it years ago and I still re-read it every couple of months. It is that good!

I wanted to take some time to show how you can take some of the principles outlined in that post and translate them into a specific Ruby/Rails technical interview.

I think interviews should test candidates for skills that they may use in the job they are applying for.

This means that I avoid brain-teaser like questions like “What is the angle of a clock at 03:05?”. Some may argue that these types of questions assess a candidate’s reasoning skills. I think you can assess a candidate’s ability to think with more relevant questions.

I also avoid questions for topics you can easily memorize even if you don’t have experience/knowledge of the area. An example would be a question like “What is the difference between a proc, a lambda and a block?”. The problem with these questions is that you can simply go through an “bank of interview questions”, see the common questions everybody asks, memorize the answers and ace the interview. The ability to answer that question tells you nothing about the candidate’s ability to work on the problems your business faces.

My approach to interviewing is to create a mock problem which deals with issues one would normally face at work.

My favorite interviews can take different forms:

  • A take home coding assignment;
  • A pairing programming session where I and the candidate solve a problem together;
  • A session where the candidate reviews a piece of code; The design process for any of these interview types is similar. Below I will outline my process for designing the “code review” exercise. I often do “code review” exercises as part of phone call technical interviews because:
  • They can easily be done during a 45 minutes call;
  • They allow focusing on a specific subject without being distracted by accessory things like development environment setup;
  • They mimic an activity that programmers do as part of their job;

My process for designing a coding review exercise has the following steps:

  • Pick the interview goals
  • Design an exercise that fulfills the interview goals
  • Define the evaluation criteria for the exercise

Designing a mock interview may require some creativity but it is quite straightforward.

Pick a few interview goals

What do you want to assess? You need to have a very clear idea of the type of skill set you are trying to hire for.

The challenges in an application with a 100 daily active users are different from the challenges of an application with 1 Billion daily active users. Even within the same large company, the skills required may vary depending on the particular domain you are working. Does the candidate need to know a lot about performance? Does the candidate need to know about memory/Rails internals? Does the candidate need to work mostly with CRUD actions? Will the candidate interact with multiple stakeholders?

The more honest you are with the skill set, the easier it will be to fill the role.

Setting the goal is the most important part because if you know what skills you want to test, it becomes trivial to come up with mock exercises to assess the skills.

A few example goals may be:

  • Assess the candidate’s ability to clearly explain his technical choices
  • Assess the candidate’s ability to write performant Rails code;
  • Assess the candidate’s ability to write safe Rails code;

Design exercises that match the interview goals

A goal tells you what is important. An exercise is the means through which you achieve that interview goal. Let’s imagine the goal was to assess the candidate’s ability to write safe Rails code.

One could devise an exercise as the one outlined below.

Imagine you had to do a code review for the controller action below. Can you tell me about what thoughts you would share?

class PostsController < ApplicationController
  def by_category
    Post.find_by_sql(“SELECT * FROM posts WHERE category = ‘#{params[:category]}’”)
  end
end

The code above has a SQL injection vulnerability which the candidate is expected to identify, explain why it is a problem and how to fix it.

I took a very simple example inspired by what the Brakeman static analysis tool validates for. But it is fair to assume that a Security focused Rails programmer should be aware of common security issues when working with Rails and how to fix them.

Naturally, you would change the exercise to be as long and/or complicated to match the skills you want to assess or the types of problems you regularly deal with.

The advantage of this type exercise is that it is related to the type of work the candidate is being hired to do – so you are sure the person can actually do the work.

I’ve also found out that candidates enjoy these exercises because they are relevant to their work.

Define the evaluation criteria of the exercise

We want to evaluate different candidates objectively. Defining the evaluation criteria gives us a benchmark upon which we can compare the abilities of different candidates (after the interview).

The evaluation criteria also helps ensuring you don’t forget to ask something during the interview.

For the exercise above we could have the following criteria:

  • The candidate is able to identify the SQL injection;
  • The candidate is able to explain what a SQL injection is;
  • The candidate is able to provide a fix for the SQL injection;

You may want to assign different levels of importance to different criteria.

Some may go further and use the criteria to grade the candidate’s performance (e.g. from 1-5) on each criteria and then compute a final score for each candidate.

Prepare a script for the interview

Preparing a script for the interview is useful so you can think clearly about how you will ask the questions about the multiple aspects of your exercise.

You want to frame questions in a way that they don’t make the solution too obvious. At the same time you want the questions to be as clearly as possible to the candidate. You don’t want your questions to create an adversarial experience for the candidate.

You may also have to consider of multiple ways to frame the same question. A candidate may only understand the question when you put it in a different way.

You want the questions to allow you to evaluate the depth of knowledge of the candidate, instead of just leading to a yes/no reply. You want your questions to allow you to learn as much as you can about the candidate.

I can send you my posts straight to your e-mail inbox if you sign up for my newsletter.