25 Ruby on Rails interview questions
Structure the Rails interview loop around evidence, not trivia. Start with a short screening call to confirm recent Ruby, Rails, SQL, testing, and remote collaboration experience. Follow with a technical interview that uses real Rails situations: debugging a slow endpoint, modeling data, handling background work, and reviewing a small pull request. Add a practical exercise in Rails 7.2 or 8.x using Ruby 3.3 or 3.4, PostgreSQL, Active Job, and either Hotwire or a JSON API. For senior candidates, include a system design round focused on boundaries, data integrity, operations, and trade-offs. End with a collaboration interview covering ownership, incidents, mentoring, and product judgment.
Junior Ruby on Rails questions
Fundamentals, learning speed and how they debug.
01A user reports that creating a record sometimes succeeds but the confirmation email is not sent. How would you investigate and fix this in a Rails app?
Listen for: A strong answer separates database writes from side effects. They should check logs, Active Job adapter behavior, retries, queue health, and whether email is sent inside or after the transaction. Listen for use of after_commit, idempotent jobs, clear error handling, and tests that cover both success and failure paths.
Red flag: They suggest sending the email directly in the controller and treating missing logs as proof the code works.
02You are reviewing a Rails controller action that has several conditionals, creates records, and calls an external API. What changes would you consider?
Listen for: Look for practical refactoring judgment, not automatic service-object dogma. Good candidates keep controllers thin, move business rules to models or small application objects, preserve validations, and make external calls retryable or asynchronous when appropriate. They should discuss tests, transaction boundaries, and keeping the flow readable for the team.
Red flag: They say every controller action should always become a service object without explaining why.
03How would you debug an endpoint that works locally but returns a 500 in production?
Listen for: They should start with the production error, request ID, logs, exception class, deploy diff, environment-specific configuration, credentials, database state, and background dependencies. Strong junior candidates know how to reproduce safely, avoid changing production data blindly, and add a regression test after finding the cause.
Red flag: They immediately guess the bug is a missing gem or propose restarting the server as the main fix.
04A Rails model has validations, callbacks, and a few scopes. How do you decide what belongs in the model versus somewhere else?
Listen for: Listen for an understanding that models can own persistence-related rules, associations, scopes, and invariants, but should not become dumping grounds for workflows, API calls, or presentation logic. A good answer mentions cohesion, testability, callbacks used carefully, and moving multi-step use cases into explicit objects when complexity grows.
Red flag: They treat Active Record models as either the place for all logic or as purely empty data containers.
05What would you look for in a failing request spec for a Rails JSON endpoint?
Listen for: Good answers cover the HTTP status, response schema, authentication, authorization, validation errors, database changes, and side effects such as jobs being enqueued. They should know how to use factories responsibly, avoid over-stubbing the app under test, and write assertions that describe behavior rather than implementation details.
Red flag: They only check that the response body includes one string and ignore status, permissions, and persistence.
06A page lists projects and shows each project owner. In production it is slow. What Rails-specific issue might cause this, and how would you fix it?
Listen for: They should identify an N+1 query risk and know how to confirm it through logs, Bullet, query counts, or APM traces. Strong answers mention includes, preload, eager_load trade-offs, indexing foreign keys, pagination, and not loading more columns or associations than the page needs.
Red flag: They propose caching the whole page before checking the SQL being generated.
Mid-level Ruby on Rails questions
Independent delivery, trade-offs and code quality.
07How would you model account, user, membership, and role data for a multi-tenant Rails application?
Listen for: A strong answer uses explicit memberships rather than a single account_id on users when people can belong to multiple accounts. They should discuss uniqueness constraints, foreign keys, role representation, authorization checks, tenant scoping, invite flows, and database-level protections so bugs do not leak data across tenants.
Red flag: They rely only on a before_action setting current_account and do not mention database constraints or authorization.
08A Sidekiq or Solid Queue job calls a payment provider and sometimes runs twice. How should the job be designed?
Listen for: Listen for idempotency keys, persisted operation records, safe retries, provider response reconciliation, timeout handling, and clear job arguments. They should avoid passing full Active Record objects, account for jobs running after records change, and know when to use unique jobs or database locks carefully.
Red flag: They disable retries because duplicate execution is inconvenient.
09You need to add search to a Rails app. When would you use PostgreSQL search, and when would you introduce Elasticsearch, OpenSearch, or Meilisearch?
Listen for: Good candidates compare complexity, relevance needs, typo tolerance, faceting, operational cost, data freshness, and failure modes. They should know PostgreSQL full-text and trigram indexes can go far, while dedicated search engines add power and operational burden. Listen for background indexing and graceful degradation.
Red flag: They choose a search service by default without understanding the product’s query patterns.
10Describe how you would safely add a non-null column to a large PostgreSQL table used by a Rails app.
Listen for: Strong answers mention phased migrations: add nullable column, deploy code that writes it, backfill in batches, validate data, add default carefully, then enforce NOT NULL. They should know Rails migration helpers can lock tables and may use strong_migrations, disable_ddl_transaction, concurrent indexes, and observability during rollout.
Red flag: They add the column with a default and NOT NULL in one migration on the hot table.
11A Rails app uses callbacks heavily and tests are brittle. How would you improve the design without a rewrite?
Listen for: Listen for incremental change: mapping callback side effects, keeping essential invariants, moving workflow steps into explicit commands, using after_commit for external effects, and adding characterization tests before refactoring. Strong candidates avoid blanket bans and explain how to reduce surprising behavior while preserving production behavior.
Red flag: They propose deleting callbacks broadly and fixing whatever breaks afterward.
12How do you approach authorization in Rails beyond simple authentication?
Listen for: They should distinguish authentication from authorization and describe policy-based checks with Pundit, CanCanCan, or a similar approach. Strong answers include scoping collections, testing denied access, protecting background jobs and admin paths, avoiding client-side-only checks, and ensuring tenant boundaries are enforced consistently.
Red flag: They say hiding buttons in the view is enough authorization.
13Your Rails API is returning inconsistent validation errors across endpoints. How would you improve it?
Listen for: A solid answer defines a consistent error contract, status codes, field paths, and messages without leaking internals. They should discuss serializers, shared error rendering, ActiveModel::Errors, internationalization if relevant, request specs, backward compatibility for clients, and documenting the API behavior.
Red flag: They standardize errors by rescuing every exception as a 200 response with an error field.
Senior Ruby on Rails questions
Judgement, architecture and raising the team's bar.
14You join a Rails codebase where deployments are risky and releases are infrequent. What would you change first?
Listen for: Look for a measured plan: understand failure history, improve test reliability, add deploy smoke checks, feature flags, database migration safety, rollback paths, and observability. Strong senior candidates prioritize small, reversible changes and work with product stakeholders instead of starting with a broad rewrite or tooling migration.
Red flag: They recommend replacing the deployment platform before diagnosing why releases fail.
15How would you decide whether a complex workflow belongs in a Rails monolith, an engine, or a separate service?
Listen for: Strong answers weigh team ownership, deployment coupling, data consistency, operational maturity, scaling needs, and domain boundaries. They should know Rails engines can modularize without distributed systems costs, while services require contracts, observability, retries, and data ownership. Listen for avoiding premature microservices.
Red flag: They equate senior architecture with splitting the monolith into services.
16A high-traffic endpoint has slow database queries and intermittent timeouts. Walk through your diagnosis and remediation plan.
Listen for: They should use traces, logs, pg_stat_statements, EXPLAIN ANALYZE, query plans, indexes, lock analysis, object allocations, and cache hit rates. Strong answers separate immediate mitigation from durable fixes, consider pagination and response shape, and verify improvements with production-like measurements.
Red flag: They add Rails.cache around the endpoint without understanding query patterns or invalidation.
17How do you handle data integrity when Rails validations are not enough?
Listen for: Listen for database constraints: NOT NULL, foreign keys, uniqueness indexes, check constraints, exclusion constraints, and transaction isolation where needed. They should explain race conditions, upserts, locking options, and how model validations improve UX but do not replace database guarantees in concurrent systems.
Red flag: They trust validates_uniqueness_of to prevent duplicates under concurrent requests.
18Describe your approach to upgrading a mature app from Rails 6.1 or 7.0 to Rails 7.2 or 8.x.
Listen for: Strong candidates propose incremental upgrades, reading release notes, fixing deprecations, updating Ruby and gems, running rails app:update selectively, testing Zeitwerk autoloading, credentials, asset pipeline changes, Active Job adapters, and framework defaults. They should plan staged deploys and avoid changing unrelated behavior during the upgrade.
Red flag: They run bundle update and rails app:update, then manually fix failures until tests pass.
19How would you make a Rails application observable enough for on-call ownership?
Listen for: They should cover structured logs with request IDs, error tracking, metrics, traces, job queues, database health, external service calls, and deploy markers. Strong answers define actionable alerts, dashboards tied to user impact, runbooks, and instrumentation in business-critical paths rather than only infrastructure-level signals.
Red flag: They consider observability complete once exceptions are sent to an error tracker.
20Tell me how you would mentor a team that overuses mocks in Rails tests and has low confidence in refactors.
Listen for: Look for technical and leadership judgment: demonstrate better test shapes, preserve fast unit tests where useful, add request/model/system coverage around critical flows, reduce brittle implementation assertions, and pair on refactors. Strong candidates create conventions and examples rather than simply criticizing previous choices.
Red flag: They suggest deleting the test suite because it is unreliable.
System design Ruby on Rails questions
Designing real systems end to end.
21Design a Rails-based subscription billing system that supports trials, plan changes, invoices, payment failures, and webhooks from a provider.
Listen for: A strong design separates local billing state from provider state, uses idempotent webhook handling, durable event records, background reconciliation, and clear state transitions. They should discuss transactions, auditability, customer support needs, retry behavior, and how to avoid granting or revoking access based on an unverified client request.
Red flag: They make the browser callback the source of truth for payment success.
22Design multi-tenant access control for a Rails SaaS app with account switching, roles, invitations, and audit logs.
Listen for: Listen for tenant scoping at query and authorization layers, membership models, role policies, database constraints, invitation lifecycle, audit event design, and safe account switching. Strong answers address background jobs, admin tools, analytics queries, and tests that prove one account cannot access another account’s data.
Red flag: They rely on a global Current.account without discussing how it can fail or be tested.
23Design a Rails notification system that sends email, in-app, and Slack notifications without spamming users.
Listen for: Good answers include notification preferences, deduplication, batching, quiet hours if relevant, templates, delivery records, retries, and provider failure handling. They should separate event creation from delivery channels, use background jobs, track idempotency, and provide admin or support visibility into what was sent and why.
Red flag: They trigger all notification sends synchronously inside model callbacks.
24Design an import feature for large CSV files in a Rails app, including validation, progress reporting, and partial failures.
Listen for: Strong designs upload files directly or safely through the app, parse in background jobs, validate rows, store import state, report progress, and handle partial success with downloadable error reports. They should discuss batching, memory usage, transactions, idempotent retries, authorization, and protecting the database from bad input.
Red flag: They read the entire file in a controller action and insert rows one by one.
25Design a Rails API used by mobile clients that must support offline sync and conflict handling.
Listen for: Listen for stable resource IDs, updated_at or version tokens, change feeds, pagination, soft deletes or tombstones, conflict policy, idempotent writes, and backward-compatible contracts. Strong answers mention authentication, rate limits, request tracing, serializer versioning, and operational tools for diagnosing client-specific sync issues.
Red flag: They assume last write wins is always acceptable and do not expose conflict information.
Build a Rails Project Activity Tracker
Create a small Rails 7.2 or 8.x application using Ruby 3.3 or newer and PostgreSQL. Users can create projects, add activity entries, assign each entry to a category, and view a project activity feed with filtering by category and date range. Add authentication with a simple session-based flow or document how to run with seeded users. Include background processing for a weekly summary job using Active Job with Solid Queue or Sidekiq. Provide request or system tests for the main flows and a short README explaining setup, trade-offs, and what you would improve next.
How to evaluate it
- Clear domain modeling with database constraints, indexes, and readable Active Record associations.
- Correct behavior for authorization, validation errors, filtering, and edge cases.
- Practical use of background jobs with idempotent behavior and test coverage.
- Maintainable Rails structure without unnecessary abstraction or controller bloat.
- Readable tests, setup instructions, and explanation of trade-offs.
Rather skip the interview loop?
Every Octogle Ruby on Rails engineer has already passed a technical assessment, system design and a live interview with an engineer who has shipped Ruby on Rails. Send a brief and get 3–5 scored profiles in 48 hours.