Ruby interviews go two layers deep: the language itself — blocks, modules, the method lookup chain — and then Rails, where most questions are really about ActiveRecord and the database underneath it. Below are the questions asked most often, each with a model answer.
Every question comes with a model answer you can compare yours against.
Only nil and false are falsy. Everything else is truthy — including 0, an empty string and an empty array, which is where developers coming from other languages get caught. So if items.empty? and if items mean completely different things, and the second is almost never what you wanted.
A string is a mutable object and every literal creates a new one; a symbol is immutable and the same symbol is the same object every time. That makes symbols the right choice for identifiers — hash keys, method names, statuses — because they are not reallocated on every use. Strings are for data you display or modify.
A block is a chunk of code passed to a method, written with do...end or braces. yield calls it from inside the method, and block_given? checks whether one was passed. Blocks are the reason Ruby code reads the way it does — each, map, open and transaction wrappers are all methods that take a block and control what happens around it.
Two differences that matter. A lambda checks its arity and raises on the wrong number of arguments; a proc silently fills the rest with nil. And return inside a lambda returns from the lambda, while inside a proc it returns from the enclosing method — which is how a proc can end a method you did not expect it to.
include adds a module's methods as instance methods, extend adds them as singleton methods on that object — so extend inside a class body gives class methods. prepend inserts the module *before* the class in the lookup chain, so the module's method wins and can call super to reach the original. Checking ancestors shows exactly what happened.
One query loads a list, then touching an association inside the loop fires one more query per row — 1 + N. The fix is loading the association up front with includes. preload always uses a separate query, eager_load forces a single LEFT JOIN, and includes picks between them depending on whether you filter on the association. The bullet gem points them out in development.
Not when you build the relation. User.where(active: true) returns a relation and touches nothing; the query runs when you need the data — each, to_a, first, count, or a template rendering it. That laziness is what lets you chain scopes, and it is also why a where that looks slow is often innocent and the real cost is somewhere down the chain.
A validation lives in the model and runs in Ruby; a constraint lives in the database and holds no matter who writes. Validations give friendly per-field errors, but they are skipped by update_column, by insert_all, by another application, and they lose races between two concurrent requests. Uniqueness in particular needs a unique index — the validation alone is a check, not a guarantee.
Hooks that fire around a model's lifecycle — before_save, after_create and the rest. They earn the reputation when they grow side effects: creating a record saves it, which sends an email, which enqueues a job, and a test that only wanted a record now needs a mail stub. Anything that is not about the record's own state is better as an explicit call in a service object.
Bundler resolves the gem versions that satisfy your Gemfile and installs them. Gemfile.lock records exactly what was resolved, which is why it is committed: bundle install on another machine reproduces the same versions instead of picking up whatever is newest. bundle update is the deliberate act of moving them.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Ruby on Rails interview →