A Technical Interview Guide for Rubyists

Originally written over two mornings, July 16–17, 2024.

I have been doing job interviews for almost a month. The process has made me think about what a technical interview should observe and how experience can be evaluated fairly.

A technical interview between Ruby programmers

At the same time, I understand that things aren't easy on the other side either. How do you determine whether the person you're about to hire is qualified for the job? It really isn't easy. So let me take the employer's or interviewer's side and ask the necessary questions: What should I pay attention to? What matters to me as an employer or CTO? Which qualities are non-negotiable, and which can be flexible?

Hiring programmers is a fascinating problem and deserves careful thought.

What does it mean to be a good programmer?

What does it mean to be a good Rubyist?

As usual, I will make my own list of important qualities:

Passion
Pragmatism and problem-solving ability
Knowledge of Ruby, or whichever language the role requires
Understanding the Rails stack and being able to explain it
TDD
SQL
Being meticulous about code
Linux, the shell, and shell scripting
Knowing your chosen editor well
Being comfortable in the terminal
Explaining HTTP in simple terms
Explaining how a web server works
Mastering Git
Knowing the different Rails and Ruby versions
Being conservative with dependencies
Having many ideas and expressing them quickly in code through spikes
Contributing to open-source projects
Writing a blog
Taking part in a community
Knowing how to install and configure a web server

Passion isn't innate

That's quite a list, isn't it? Let's take it one item at a time. Why does passion matter to me in a programmer? And is it non-negotiable? Those are two very good questions.

Passion matters. I don't know whether it is non-negotiable, but it matters a great deal. When you care deeply about what you do, you take ownership and want to improve. It becomes a thirst for knowledge and achievement. Passion is debating with friends whether Ruby is better than Python, whether we should practice TDD one hundred percent of the time, or whether functional programming is better than object-oriented programming. It is building something and wanting to show a friend the brilliant script you have just written, or entering a state of flow.

But is passion something you're simply born with—something you either have or don't? No. Passion is earned. You have to work, and work hard, to develop and experience it. In fact, working hard on something difficult that demands skill can create a state of flow and, with it, passion. To be passionate is to love what you do.

Back to the question at hand: can passion be detected? How can we recognize it in a programmer? Excellent question, my dear Gramos. A passionate programmer is a hacker, in the original, positive sense of the word: someone curious who enjoys challenges and looks for intelligent ways to solve problems.

Boredom is a hacker's number-one enemy. They enjoy interesting work and problems they have never solved before.

Recognizing passion

One way to learn what excites a programmer or candidate is to ask about a problem they enjoyed solving, something they learned recently, or a project they wanted to share with other people. The answers matter, but also pay attention to how they explain their decisions, what they learned, and the tradeoffs of the paths they chose.

The interviewer should be skilled enough to keep the candidate from feeling examined. It should feel like a conversation between peers, allowing the candidate to respond openly and genuinely. Recognizing passion isn't easy. If you have other ideas, write to me at ramos.gaston@gmail.com.

Pragmatism and problem solving

What does it mean to be pragmatic? It isn't so easy to explain. To me, it means learning something new every day, even if it is something small. It means taking responsibility, improving the project's code day by day, not being afraid of change, and being willing to adopt a new technology in a matter of days. It also means testing code automatically, automating repetitive work, communicating effectively, and trusting your team and colleagues.

I strongly recommend reading The Pragmatic Programmer.

Knowledge of Ruby

I plan to write a guide to language knowledge based on Ruby, although the same ideas can easily be applied to another language. Some areas to cover are:

Installation and version managers: rbenv, chruby, and ruby-install
Operations on collections: map, reduce, and iterators
String operations: gsub, tr, and regular expressions
Classes, objects, and modules
Tests with RSpec or Minitest

To avoid the common mistake of creating an enormous technical test, give the candidate one or two Ruby exercises whose solutions involve some or all of the items above. And pay attention: the goal isn't necessarily for the candidate to finish, although that would be nice. The goal is to see how naturally they approach the problem and write code.

Ideally, work through the exercise alongside them as a pair-programming session, either in person or remotely. This lets you observe how they use the tools discussed above: how they work in the terminal, use their editor, write the program, and test it. Prepare a list of what you want to observe and document the skills the candidate should demonstrate.

I'll probably continue this guide...

Gastón Ramos

Personal blog