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. Middle: deeper understanding, optimization, and real-world situations.
Ruby looks in the object's singleton class, then prepended modules, then the class itself, then included modules in reverse order of inclusion, then up to the superclass, and repeats. SomeClass.ancestors prints the actual order, which settles most arguments faster than reasoning about it. super continues along that chain from wherever you are.
preload loads the association in a second query. eager_load uses one LEFT OUTER JOIN. includes chooses for you, switching to a join when you reference the association in a where. Reach for includes by default, and name the other two when you need to force the strategy — usually because the join is duplicating rows or the second query is cheaper.
Start from the logs and the query count, not from reading code — most slow Rails endpoints are query problems. Look for N+1, for a missing index behind a where on a large table, and for work that does not need to be in the request at all. EXPLAIN tells you whether the index is actually used. Caching is what you do after that, not instead of it.
You index the columns you filter and sort on, and for a multi-column index the order matters — it can serve a prefix of its columns, not any subset. An index does not help when the query touches most of the table anyway, and it costs on every write, so indexing every column is its own problem. A LIKE '%x' with a leading wildcard cannot use a plain B-tree index at all.
Because a job can run twice — a retry after a timeout, a crash after the work but before the acknowledgement. If running twice charges the card twice, that is a bug in the job rather than in the queue. You make it safe by keying the effect: check whether the charge already exists, use a unique index, or make the operation naturally repeatable.
Move behaviour that is not about the record's own state out — a service object for a multi-step operation, a query object for a complex scope, a form object when a form spans two models. The failure mode in both directions is real: a 900-line model nobody can change, or forty single-method classes with no obvious home. The test is whether a new person can find the code by name.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Ruby on Rails interview →