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. Senior: architecture, trade-offs, mentoring, and decision-making.
Assume the table is locked for as long as the statement takes, and shape the change so it is not. Add columns as nullable without a default, backfill in batches outside the migration, add indexes concurrently, and only then add the constraint. Renaming and dropping are the dangerous ones because old code is still running during the deploy — do them in two releases with a dual-write in between.
Draw the boundaries before extracting anything — usually along the parts of the domain that change together. Enforce them inside the same codebase first, with modules or engines and no cross-boundary database access, which is where you learn the boundary was wrong at almost no cost. Extracting a service is the last step, not the first, and it is only worth it when a team or a scaling need actually demands it.
It pays off in a small library where it removes a large amount of repetition — define_method over a list of attributes is fine. It costs at the point where someone greps for a method name and finds nothing, or where a typo becomes a silent nil because method_missing swallowed it. If you define method_missing, define respond_to_missing? with it, otherwise the object lies about what it can do.
Cache what is expensive and stable, and only after the query is already as good as it will get — caching is not a fix for an N+1, it is a way of hiding one until the cache misses. Decide the invalidation before the caching: a key that includes updated_at expires itself, whereas a manual sweep is the thing that will be forgotten. Cached wrong data is worse than a slow page.
Get the test suite honest first, because the upgrade is only as safe as what it can tell you. Then go one minor version at a time, deal with deprecation warnings before they become errors, and keep the app running on the old and new versions in the same branch where the framework allows it. The part people underestimate is gems: the blocker is usually an unmaintained dependency, not Rails itself.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Ruby on Rails interview →