How to Hire a Rails Engineer When AI Writes the Code

To hire a Rails engineer for a startup, define the product and maintenance work the person will own. Then ask each candidate to make one bounded change in an existing Rails app. Look for sound scope, protected data boundaries, useful tests, and a deployable plan. Use the same questions and behavior-based rubric whether the candidate writes code by hand or with AI.

The question feels sharper after Jared Norman’s September 24 essay, “What About Rails?”. He questions what the Rails World keynote said about Rails itself while AI-written code and a flagship product’s new stack drew attention. A Hacker News discussion brought competing practitioner views. Neither an essay nor a comment thread tells you whom to hire. Your existing application, its risks, and the work ahead do.

What does a Rails engineer own at a small startup?

A Rails engineer at a small startup owns a working product over time, not merely a stream of commits. The job can cross requests, data, user interfaces, jobs, integrations, tests, releases, and production failures. Write down which of those surfaces this hire will actually touch.

Imagine a two-engineer team with a live Rails application. A customer asks for an export. The visible feature may be a button and a file. The engineering work includes who may request it, what records belong to that account, how a large request behaves, what happens when the request fails, and how the feature rolls out. A candidate who builds a button but cannot explain the data boundary has missed the expensive part of the work.

Rails gives that engineer a common map. The Rails Doctrine favors conventions, integrated defaults, and the option to substitute components when needed. A good hire can follow the application’s established path from controller to model to view or job, then explain a deviation. They do not need to insist that every Rails application look identical. Team conventions are choices made within a framework, not universal rules imposed by it.

The owner also keeps the application supportable. As of September 27, 2026, the Rails release record lists 8.1.4, released September 24. The Rails maintenance policy lists bug fixes for 8.1.x through October 10, 2026, and security fixes through October 10, 2027; 8.0.x security support runs through November 7, 2026. Those dates will change. The durable hiring question is whether someone can inventory the app’s version and dependencies, plan an upgrade, test the change, and recover if a release goes wrong.

If you have no Rails application and the work needs a different platform, do not turn Rails familiarity into a hiring filter. The founding engineer hiring guide covers broader first-hire ownership.

Has AI changed the case for hiring Rails expertise?

AI changes who may type the first draft of a change. It does not remove the need for somebody to decide whether that change fits the product, protects users, and can survive deployment. Assess the workflow you expect the hire to use.

Norman argues that the keynote offered little Rails direction and challenges the idea that generated code need not be read. That is his interpretation of a talk and of AI-assisted development, not the Rails project’s support policy. The project’s own Rails and AI page says standard names, folders, commands, and patterns help agents write idiomatic changes. It also publishes task-based evaluations, including feature tickets in Fizzy and small Rails API tasks. These are first-party, bounded tests. They do not show that an agent can maintain your application without review or that a candidate who uses one is better or worse.

The HN comments disagree about the value and maintainability of generated code. They are anecdotes, not a hiring rule.

Instead, ask to see the candidate’s decisions around generated code. Which assumption did they check? Which suggestion did they reject? Can they trace the authorization path without asking the agent to explain its own diff? Could they cut the change in half and still meet the user need? These questions also work for a candidate who did not use AI. Review practice is observable; a claimed number of lines written is not a useful substitute.

If choosing Rails is still open, examine required client surfaces, performance, integrations, existing assets, team capacity, and maintenance horizon. Another product’s stack change cannot decide your architecture. For an established Rails app, “owner of this Rails codebase” is a clearer vacancy than “AI builder.”

Which Rails skills belong in the job description?

List the skills needed on day one, then separate the conventions a capable engineer can learn after joining. This keeps the job tied to actual work and keeps the interview from rewarding memorized framework trivia.

Start with a concrete inventory. Which Rails version runs today? Where do tenant checks happen? Are changes primarily server-rendered pages, APIs, jobs, or integrations? Who deploys and investigates incidents? What does the next quarter’s roadmap require? Put the answers into a short role brief. The full-stack hiring guide can help if the role spans frontend and backend work; a Rails title alone does not define that balance.

For a maintainer of a multitenant app, day-one competencies might be:

• Trace a request or background task to the data it reads and writes.
• Explain how authorization and account scope apply to the exact change.
• Add or adapt a useful regression test, including a failure path.
• Read a migration and describe rollout and recovery risk.
• Use the existing codebase’s conventions, and explain a simpler alternative when one exists.
• Communicate uncertainty before changing a customer-facing behavior.

You may require deeper Rails fluency if the person will be the only engineer maintaining that codebase immediately. State that expectation plainly. For a team able to mentor a strong engineer from another stack, favor evidence of transferable reasoning over recall of a particular helper method. A familiarity requirement should reflect the job, not interview habit.

This distinction follows U.S. OPM job-analysis guidance, which connects assessments to job tasks and required competencies. OPM’s work-sample guidance likewise cautions against testing skills a person is meant to learn after hire. These are general selection principles from a U.S. public-sector source, not a validated checklist for a Rails startup.

How do you test Rails judgment without a trivia quiz?

Give candidates a small, synthetic Rails app and one change that resembles the job. The sample should let them show where behavior belongs, how they protect data, and how they verify the result. It should not be a disguised request to finish your product backlog.

Here is an original example to pilot, not a proven assessment. A fictional two-account app already has users, report records, and a background job. An account administrator asks to export that account’s reports. The repository includes setup instructions, seed data, schema, existing tests, and a single command to run them. Give every candidate the same packet and an explicit policy on AI and outside resources.

Do not require a queue merely to see whether the candidate knows one. In this example a job already exists, so the candidate may use it if the app’s behavior calls for it. A candidate who explains why a synchronous path suffices for a tiny bounded export may show better judgment than one who adds several moving parts. Conversely, a candidate who ignores a known large-data constraint should explain that choice.

Pilot the packet with an engineer, state the expected effort, and test a clean checkout. If setup becomes dependency repair, you are measuring patience with your environment. For frontend work, substitute a Hotwire state and error flow; for operations, a release or incident scenario. Sample the job you advertised.

The Rails security guide and Rails testing guide give technical context for reviewing the result. Framework helpers can reduce common hazards, but they do not answer whether this administrator can see another account’s records. Tests can exercise the behavior; the candidate must still select the dangerous path to test. The exercise is useful because a reviewer can discuss those decisions in a real diff. It has not been validated as a predictor of hiring outcomes.

For more on setting reasonable scope and candidate instructions, see the guide to code assignments.

What should reviewers ask and score?

Ask every candidate the same job-related core questions, then score the evidence against anchors written before anyone interviews. The debrief should reveal how they reasoned about their change, including any AI output, rather than invite a performance of favorite Rails vocabulary.

Use these five prompts for the export packet:

1. Where does this behavior belong in the existing app, and what made you put it there?
2. Which account or permission boundary worries you most? Show the path that enforces it.
3. What regression would your most valuable test catch? What does it leave untested?
4. What would you inspect before deploying, and how would you recover if the export failed?
5. If you used AI, which suggestion did you change or reject, and why? If you did not, what alternative did you consider and set aside?

Give every candidate the same hypothetical extension: exports now run asynchronously, and the administrator loses account access before execution. Ask what must change, including authorization when generating the export and when delivering or downloading it. There is no mandatory one-line answer. Look for whether they identify the time gap, the user consequence, and both places access must be checked. A candidate may also explain why the packet lacks enough information to choose a final policy. That is useful evidence if they state what they would need to decide.

The OPM structured-interview guidance recommends predetermined job-related questions and common rating standards. The prompts and anchors below are this article’s proposed design, not OPM-endorsed questions. Pilot them for your role.

Score observations, not polish. Reviewers should write what they saw before discussing a rating together. “Found the unscoped query and added a cross-account test” is an observation; “seems senior” is not. A candidate who proposes a different valid design should be able to earn a strong rating. For a role that explicitly allows Rails ramp-up, do not penalize someone simply for looking up an API.

Broad selection research, including Sackett and colleagues’ reanalysis and its follow-up, informs structured assessment generally. It does not validate this Rails rubric, AI policy, or debrief. Pilot and revise them. The guide to structured scorecards covers the wider decision process.

How do you make the assessment fair and maintainable?

A work sample only helps if qualified candidates can complete it under comparable conditions. Publish the task’s expected effort, tool rules, evaluation dimensions, and submission format. Then check whether real candidates can participate as intended.

The AI policy is part of the assessment design. If your team uses agents at work, allowing them in the sample can reveal review judgment. Give equal instructions about permitted tools, data handling, and whether paid services are necessary. Do not demand an AI-generated transcript as a proxy for authorship. Ask candidates to explain their decisions in the debrief. If you forbid AI for a particular role, state why that restriction reflects the job and apply it consistently.

Pilot the exercise before using it. Have an engineer complete it from a fresh checkout while recording setup friction and actual time. Revise an overlong task. Offer an alternative format or adjustment when the default format blocks a qualified applicant. For U.S. employers, the EEOC’s applicant guidance is a starting point for accommodation obligations; other jurisdictions have their own rules. Keep the practical promise simple: candidates should know how to request an adjustment without disclosing it to every interviewer.

Maintain the packet as software. Pin or state the Rails and Ruby versions, keep dependencies installable, run the test command in CI, and remove accidental clues in seed data. When your real role changes, revisit the sample and scoring anchors. Track whether candidates abandon the task or ask for the same clarification repeatedly; those signals may point to a broken packet, not weak applicants. Do not reuse a task indefinitely because it once worked.

Finally, give reviewers enough time to read the diff. If the process rewards only a passing test run, you will miss the choices this article asks you to assess. A brief, consistent debrief can expose a hidden assumption, but it cannot retroactively make a poor work sample job-related.

How can Kit run the process?

Kit can coordinate the candidate workflow while your team owns the assessment. Its Hiring pipeline has GitHub-backed code assignments, separate interview and team review stages, and scoring criteria on reviewable stages. Those pieces can carry a tested packet, a deadline, and a human discussion without pretending that a product can certify Rails judgment.

For a code assignment, Kit creates a private repository from a GitHub template and sets a deadline. Put your synthetic app and instructions in that template. Use a subsequent review or work-sample stage for the scoring criteria and evidence from the diff. Do not treat the assignment step itself as an automatic architecture or security judge. Kit does not generate this rubric, prove who wrote a line of code, or run the debrief for you.

Kit itself is a Rails application. Its human-facing Hiring pages use Hotwire, while authenticated remote MCP tools provide agent-facing hiring operations through a separate path. That is a concrete example of offering both a user interface and agent access. It is not evidence that Rails is the right stack for every startup, or that the agent path replaces human review.

The practical next step is small: write a one-page role brief, pilot one bounded Rails change with your own team, and agree on the anchors before inviting applicants. If you want a place to organize the assignment and subsequent reviews, explore Kit. The judgment about what a good engineer does in your application stays with you.