Senior Ruby Developer Interview Questions and Scorecard
Six question sets for the owner or lead running the interview: Ruby and Rails depth, an inherited codebase, performance and data, testing and production, seniority, and a weighted scorecard. Every question comes with why it is worth asking and what a strong answer sounds like. Download as DOCX.
The hardest part of hiring a senior Ruby developer at a small company is that the person best placed to judge the answers is usually the person you are trying to hire. If you have written the job description yourself and you do not write Ruby, an hour of technical conversation can feel like an hour of being told things you cannot check.
You can check more than you think. Almost every question worth asking has a memorized answer and a reasoning answer, and the gap between them is visible without knowing the language. At FirstHR we build for owners who make this hire themselves, so every question below arrives with why it is worth asking and what a strong answer actually sounds like.
These six sets cover Ruby and Rails depth, judgment inside an inherited codebase, performance and data, testing and production ownership, seniority, and a weighted scorecard with a red-flag checklist. Take the sets that match your situation and skip the rest.
TL;DR
Interview a senior Ruby developer on five things: Ruby and Rails depth judged by reasoning rather than definitions, judgment inside an inherited codebase, performance and data work, testing and production ownership, and seniority you can verify. Ask every candidate the same questions, score each area from 1 to 5, and download six sets as DOCX.
What a Senior Ruby Developer Owns
At a small business, a senior Ruby developer usually owns the application rather than a slice of it: the codebase, the framework version, the deployment path, and the phone call when the site goes down. That is a wider scope than the same title carries at a large company, and it should change what you interview for.
The second thing that should change your questions is the shape of the work. Ruby hiring at small companies is mostly maintenance and modernization of an application that already carries the business, not greenfield building. The candidate who interviews best on language internals is not always the one who can walk into an unfamiliar app, resist rewriting it, and ship something useful in week one.
So the interview has to cover two things at once: whether they know Ruby deeply, and whether their judgment holds up in code they did not write. Our guide to finding developers for a startup covers the sourcing side; this page covers the hour you spend in the room.
Which Question Set to Use
Use two or three sets, not all six. Pick them from your situation: an older application makes the inherited-codebase set the highest-signal hour you will spend, and a sole-developer role makes testing and production ownership more important than language trivia. If the hire is broader than Ruby, our general technical interview questions cover the same ground without the framework specifics.
Core Ruby and Rails Depth
Reasoning, not definitions
Modules versus inheritance, blocks and lambdas, metaprogramming regrets, monkey patching, and where logic belongs. Every question is graded on the reason, not the definition.
Inherited Codebase and Upgrades
The actual job
First two weeks in an unfamiliar app, upgrade sequencing, changing untested code, abandoned gems, and the refactor they abandoned. Weight this heaviest for an older app.
Performance, Data, and Jobs
Measure before fixing
A six-second page, N+1 queries, when an index is wrong, zero-downtime migrations, and what makes a background job safe to retry twice.
Testing and Production
Your 9pm phone call
A forty-minute test suite, what to mock, flaky tests, the first thirty minutes of an incident, secrets, gem patching, and the rollback path.
Seniority and Communication
Scope, not years
Decisions owned end to end, arguing and losing gracefully, explaining a tradeoff without jargon, mentoring evidence, and ranking technical debt.
Scorecard and Red Flags
Score, do not guess
A weighted six-area rubric, a mid-level versus senior answer guide, and a red-flag checklist so the decision rests on written evidence.
Weight the Sets Before You Meet Anyone
Decide which areas matter most while you are still thinking about the job rather than about a person. Once you have met a candidate you liked, it becomes very easy to quietly re-weight the scorecard toward the things they happened to be good at. Write the weights down first, in the scorecard file, and then interview.
6 Question Sets to Download
Download all six as a single Word document, or copy individual sets. Each question lists why it is worth asking and what a strong answer sounds like, with space for notes. More question sets by role sit in the hiring templates library.
Download All Six Question Sets and the Scorecard
Five question sets plus a weighted scoring rubric, a seniority guide, and a red-flag checklist. All in one DOCX.
Set 1: Core Ruby and Rails Depth Questions
Modules versus inheritance, blocks and lambdas, metaprogramming, monkey patching, and where logic belongs. Each question is graded on the reason, not the definition.
Core Ruby and Rails Depth Questions
CORE RUBY AND RAILS DEPTH QUESTIONS
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Ask five or six of these. Every question below has a definition answer and a
reasoning answer. The definition answer is memorized and tells you almost
nothing. The reasoning answer explains when the thing matters, what it costs,
and what the candidate does instead. Grade the second half of the answer, not
the first. If you do not write Ruby yourself, listen for whether the reason is
specific and consistent rather than whether the terminology is correct.
QUESTIONS
1. When do you reach for a module instead of inheritance?
Why ask: composition judgment is the clearest senior signal in Ruby, because
the language makes both easy and lets you regret either one.
Strong answer: inheritance only for a real is-a relationship, modules for
behavior shared across unrelated classes. Mentions the ancestor chain,
include versus prepend versus extend, and warns about a module that quietly
depends on the host class internals.
2. Explain blocks, procs, and lambdas, and tell me when the difference bit you.
Why ask: it separates people who read about Ruby from people who debug it.
Strong answer: lambdas check argument count and return to the caller; procs
do neither, so a return inside one exits the enclosing method. The best
answers arrive with a real bug attached.
3. Where has metaprogramming earned its keep, and where did you regret it?
Why ask: seniors have both stories. Juniors only have the first one.
Strong answer: names a specific use (a generated set of similar methods, an
adapter over a messy external payload) and then names the cost honestly:
stack traces that lead nowhere, methods you cannot search for, a new hire
who takes a week to find where behavior comes from.
4. What does monkey patching cost, and how do you contain it?
Why ask: reopening a core or gem class is global and permanent until someone
finds it, which is a real risk in a codebase one person maintains.
Strong answer: contains it in one documented place, prefers a wrapper, a
refinement, or an upstream patch, and can say when it was still the right
call anyway.
5. How do you decide whether logic belongs in the model, a service object, or
a background job?
Why ask: every Rails codebase drifts, and a senior hire sets the rule.
Strong answer: applies a consistent rule rather than a fashion, and can
defend it against the alternative.
6. How do you find where a method is actually defined in a large app?
Why ask: a cheap, honest test of practical fluency.
Strong answer: source_location, ancestors, and the tooling they use daily.
7. When should a Rails app stop being one app?
Why ask: an expensive answer given casually is a warning.
Strong answer: pushes back at small scale, names the specific pain that
would justify a split, and treats extraction as a last resort.
WHAT TO LISTEN FOR
•A reason attached to every definition
•Named tradeoffs, including what the candidate gave up
•Preference for boring code that the next person can read
•Willingness to say a past choice was wrong
NOTES
__
__
Set 2: Inherited Codebase and Upgrade Questions
The closest thing to a job simulation you can run in an hour: first two weeks in an unfamiliar app, upgrade sequencing, untested code, abandoned gems, and an abandoned refactor.
Inherited Codebase and Upgrade Questions
INHERITED CODEBASE AND UPGRADE QUESTIONS
Candidate: __
Interviewer: __
Date: _
WHY THIS SET MATTERS MOST
Most senior Ruby hiring at a small company is not greenfield work. The person
is walking into an application someone else wrote years ago, with gaps in the
tests, gems nobody has touched, and a framework version that is one or two
behind. This set is the closest thing to a job simulation you can run in an
hour, and it is the set that most generic interview lists leave out entirely.
Weight it heavily if your app is more than three years old.
QUESTIONS
1. Walk me through your first two weeks in a codebase you have never seen.
Why ask: it is literally the job for the first month.
Strong answer: reads before changing, gets the app running locally on day
one, ships something tiny and safe in week one, and maps the parts of the
system by following a real request end to end. Weak answers open with a
rewrite plan.
2. How do you sequence a Ruby and framework upgrade, and which goes first?
Why ask: an out-of-support version is a security decision, not a taste
decision, and someone has to own it.
Strong answer: one step at a time, deprecation warnings driven to zero
before the next step, the test suite as the safety net, and a preference
for many small merged upgrades over one heroic branch that never lands.
3. You need to change code that has no test coverage. What do you do first?
Why ask: this is the most common real situation in an older app.
Strong answer: writes characterization tests that pin the current behavior
before touching it, so the refactor has something to fail against.
4. A gem you depend on has been abandoned. Walk me through the options.
Why ask: it happens to every long-lived Ruby app.
Strong answer: measures how much of the gem is actually used first, then
chooses between vendoring, forking, replacing, or deleting the dependency,
and treats an unmaintained dependency as a security exposure.
5. Tell me about a refactor you started and then abandoned.
Why ask: it is the single best senior question on this page.
Strong answer: describes noticing the cost overtaking the benefit, stopping
deliberately, and leaving the codebase no worse. Candidates with no such
story either have not owned enough or will not admit it.
6. How do you delete dead code safely?
Why ask: guessing is how outages happen.
Strong answer: instruments the suspected code in production first and waits
for real evidence before deleting.
7. After reading our codebase, what would you tell me to stop worrying about?
Why ask: prioritization is the scarce skill, and this question cannot be
rehearsed.
Strong answer: names something real, explains why it is survivable, and is
comfortable disagreeing with the person paying them.
WHAT TO LISTEN FOR
•Reads first, changes second, rewrites almost never
•Small reversible steps instead of one large branch
•Treats old dependencies as risk, not as personal insult
•Can rank problems, not just list them
NOTES
__
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Performance, Data, and Background Job Questions
A six-second page, N+1 queries, when an index is the wrong answer, zero-downtime migrations, and what makes a background job safe to run twice.
Performance, Data, and Background Job Questions
PERFORMANCE, DATA, AND BACKGROUND JOB QUESTIONS
Candidate: __
Interviewer: __
Date: _
WHAT THIS SET TESTS
Almost every Rails performance problem at a small company is a database
problem wearing a costume. This set checks whether the candidate measures
before changing anything, understands the data layer, and can move work off
the request safely. Ask four or five, and follow every answer with "how would
you know that was the cause?"
QUESTIONS
1. Our slowest page takes six seconds. Walk me through your first hour.
Why ask: it reveals whether they measure or guess.
Strong answer: reproduces it, then splits the time into database, view
rendering, and external calls before touching anything. Anyone who starts
proposing fixes before measuring has told you how they will work here.
2. What is an N+1 query, and how do you catch them before customers do?
Why ask: it is the most common Rails performance bug by a wide margin.
Strong answer: explains it plainly, names eager loading and the difference
between the loading strategies, and adds a detection step in development or
in the test suite so the next one gets caught automatically.
3. When is adding an index the wrong answer?
Why ask: it is the reflex fix, and the reflex is sometimes wrong.
Strong answer: writes get slower, low-cardinality columns barely help, and
the query plan should be read rather than assumed.
4. How do you add a column to a very large table without downtime?
Why ask: this is where a careless senior takes the site down.
Strong answer: knows which operations lock, backfills in batches, and
separates the migration from the deploy that starts using the column.
5. What makes a background job safe to retry?
Why ask: retries are automatic, so a job that is not safe to run twice will
eventually charge a customer twice.
Strong answer: idempotency, passing record IDs rather than serialized
objects, a retry limit, and somewhere for permanently failed jobs to land.
6. Where do you start with caching, and how do you avoid serving stale data?
Why ask: caching is often used to hide a query problem instead of fixing it.
Strong answer: fixes the query first, then caches with expiry tied to the
record so nothing has to be invalidated by hand.
7. How do you decide whether work happens in the request or in a job?
Why ask: it is a daily judgment call that shapes how the app feels.
Strong answer: ties it to whether the user needs the result to continue.
WHAT TO LISTEN FOR
•Measures first, every single time
•Comfortable at the database layer, not just in Ruby
•Thinks about the second run of a job, not only the first
•Explains cause, not just cure
NOTES
__
__
Set 4: Testing, Deployment, and Production Ownership Questions
Weight this heavily if the hire will be your only developer: a slow test suite, mocking discipline, flaky tests, incident response, secrets, gem patching, and rollback.
Testing, Deployment, and Production Ownership Questions
TESTING, DEPLOYMENT, AND PRODUCTION OWNERSHIP QUESTIONS
Candidate: __
Interviewer: __
Date: _
WHAT THIS SET TESTS
If you have no separate operations team, the senior Ruby developer you hire is
also the person who gets called when the site is down at 9pm. Weight this set
heavily for a sole developer or a two-person team, and lightly if you already
have people who own deployment and on-call.
QUESTIONS
1. Our test suite takes forty minutes. What do you actually do about it?
Why ask: a slow suite quietly stops being run, and then it stops protecting
anything.
Strong answer: measures the slowest tests first, cuts unnecessary database
setup, moves coverage down to faster levels, and parallelizes last rather
than first.
2. What do you mock, and what do you refuse to mock?
Why ask: over-mocking produces a green suite that proves nothing.
Strong answer: mocks the external boundary such as third-party HTTP calls,
and refuses to mock the domain objects the test is supposed to be checking.
3. Tell me about a flaky test you fixed and what was actually causing it.
Why ask: the answer separates people who fix causes from people who add a
retry and move on.
Strong answer: names the real cause, usually time, test ordering, or shared
state, and fixes it there.
4. Walk me through your first thirty minutes of a production incident.
Why ask: it is the highest-stress part of the job and it is rehearsable.
Strong answer: stabilizes first, communicates early, keeps a rollback within
reach, and saves the root-cause work for after the bleeding stops.
5. How do you handle secrets and credentials in a Rails application?
Why ask: a small team is exactly where credentials end up in a repository.
Strong answer: encrypted credentials or a secret manager, nothing sensitive
in version control, and a plan for rotating a leaked key.
6. How do you keep gems patched without breaking the application?
Why ask: security patches arrive whether or not anyone is watching.
Strong answer: automated dependency updates, a security advisory check that
runs on every build, and continuous small upgrades so the large ones stay
possible.
7. Describe your deployment process and how you roll back.
Why ask: if the rollback is theoretical, it does not exist.
Strong answer: has done it, knows how long it takes, and knows which
migrations make a rollback dangerous.
WHAT TO LISTEN FOR
•Has been on call and does not romanticize it
•Treats the test suite as a tool with a maintenance cost
•Security handled as routine hygiene, not as a project
•Rollback described from memory, not from theory
NOTES
__
__
Set 5: Seniority, Ownership, and Communication Questions
Decisions owned end to end, disagreeing and committing, explaining a tradeoff without jargon, mentoring evidence, and how they would rank technical debt against business impact.
Seniority, Ownership, and Communication Questions
SENIORITY, OWNERSHIP, AND COMMUNICATION QUESTIONS
Candidate: __
Interviewer: __
Date: _
WHAT THIS SET TESTS
Seniority is scope and judgment, not years. This set looks for evidence that
the candidate has owned a decision through its consequences, changed their
mind with new information, made someone else better, and can explain a
technical tradeoff to an owner who does not write code. At a small company
that last skill is not optional, because you are the person they have to
convince.
QUESTIONS
1. Tell me about a technical decision you owned end to end, including what it
cost you.
Why ask: ownership includes living with the result.
Strong answer: a real decision, the alternative that was rejected, and an
honest account of what went wrong afterward.
2. Tell me about a time you argued against a feature and lost. What did you do?
Why ask: a senior hire will disagree with you eventually.
Strong answer: made the case once, clearly and in writing, then committed to
the decision and built it well. Sulking or quiet sabotage shows up here.
3. Explain a technical tradeoff to me as if I do not write code.
Why ask: you will be relying on these explanations to make decisions.
Strong answer: plain language, an honest cost on both sides, and a
recommendation. Jargon used as a shield is a real warning sign.
4. Who have you made better, and how do you know it was you?
Why ask: senior titles are often given for tenure rather than for impact.
Strong answer: names people, describes what changed in their work, and
claims credit modestly and specifically.
5. What is the most recent thing you changed your mind about technically?
Why ask: it is difficult to fake and reveals how they take in new evidence.
Strong answer: something specific and recent, with the reason attached.
6. How would you decide which technical debt we pay down first?
Why ask: it tests whether they can rank against business impact.
Strong answer: connects the debt to something the business feels, such as
slow shipping, outages, or security exposure, rather than to personal taste.
7. What would you need from me in the first ninety days to succeed here?
Why ask: the answer tells you what the candidate thinks the job is.
Strong answer: asks for clear ownership, access, and a named first project.
WHAT TO LISTEN FOR
•Owns outcomes, including the bad ones
•Disagrees openly and then commits
•Explains without jargon when asked to
•Ranks work by business impact
NOTES
__
__
Set 6: Scoring Rubric, Seniority Guide, and Red Flags
A weighted six-area rubric, a mid-level versus senior answer guide, and a red-flag checklist, so the decision rests on written evidence instead of on who spoke most confidently.
Scoring Rubric, Seniority Guide, and Red Flags
SENIOR RUBY DEVELOPER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: _
Score each area from 1 to 5 and write one line of evidence from the interview.
A score with no evidence next to it is a gut feeling wearing a number. Set the
weights before you interview anyone, so the role decides them rather than the
candidate you liked most.
SCORING AREAS
Ruby and Rails depth (reasoning, not definitions) Score: [ 1 2 3 4 5 ]
Performance, data, and background jobs Score: [ 1 2 3 4 5 ]
Weight: ____ Evidence: __
Testing, deployment, and production ownership Score: [ 1 2 3 4 5 ]
Weight: ____ Evidence: __
Seniority, ownership, and communication Score: [ 1 2 3 4 5 ]
Weight: ____ Evidence: __
Fit for a small team with no CTO above them Score: [ 1 2 3 4 5 ]
Weight: ____ Evidence: __
MID-LEVEL VERSUS SENIOR: WHAT THE ANSWERS SOUND LIKE
Ruby depth
Mid-level: correct definitions, few tradeoffs.
Senior: definitions plus when it matters and what it costs.
Inherited code
Mid-level: wants to rewrite the confusing part.
Senior: reads first, pins behavior with tests, changes in small steps.
Performance
Mid-level: proposes a fix immediately.
Senior: measures first and can say how they would confirm the cause.
Failure
Mid-level: the failures were caused by other people.
Senior: owns a specific mistake and what it changed in their practice.
Scope
Mid-level: describes tickets that were completed.
Senior: describes decisions that were made and defended.
RED FLAGS
•Proposes a rewrite before reading the codebase
•Every previous codebase and team was terrible
•Cannot name a single decision they got wrong
•Recites definitions with no reasoning underneath
•Falls back on jargon when asked to explain plainly
•Describes a rollback they have never actually performed
•Dismisses testing entirely, or demands total coverage regardless of cost
SUMMARY
Weighted total: ______
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Interviewer signature: __
Note: if more than one person interviews, everyone scores independently before
the group talks. Otherwise the first opinion spoken becomes the group opinion.
How to Judge Answers If You Do Not Write Ruby
Grade the shape of the answer rather than the syntax. A strong answer attaches a specific reason to every definition, names what the choice cost as well as what it gained, and describes measuring something before changing it. That pattern is recognizable whether or not you know what a lambda is.
The most useful follow-up on this page is four words long: how would you know? Ask it after any diagnosis and any recommendation. Rehearsed candidates have prepared the answer, not the reasoning behind it, and the difference surfaces immediately.
What is an N+1 query, and how do you catch them before customers do?
Strong answer: Explains the idea plainly, that one query to fetch a list turns into one more query per item, names eager loading as the fix and knows the loading strategies differ, then adds a detection step in development or the test suite so the next one is caught automatically rather than found by a customer.
Weak answer: Recites the textbook definition and stops, or jumps straight to caching the page, which hides the extra queries instead of removing them.
You need to change code that has no test coverage. What do you do first?
Strong answer: Writes tests that pin down what the code currently does before changing any behavior, so the refactor has something to fail against. Says plainly that these tests describe the existing behavior rather than the correct behavior, and that the difference gets sorted out afterward.
Weak answer: Starts changing the code and says they will be careful, or insists the whole area needs a rewrite before any work can begin.
Tell me about a refactor you started and then abandoned.
Strong answer: Has a real story: what looked simple, where the cost overtook the benefit, when they decided to stop, and how they left the codebase no worse than they found it. Treats stopping as a decision they made rather than a failure that happened to them.
Weak answer: Has no such story at all, or tells one where every problem was caused by other people, other teams, or the previous developer.
One more habit worth borrowing from structured interviewing: write the candidate's answer down in their words before you score it. Scoring from memory an hour later quietly turns into scoring how the conversation felt.
What Separates Senior from Mid-Level
Seniority is scope and judgment, not years in the language. A mid-level developer completes the work assigned to them and answers correctly about Ruby. A senior developer makes decisions, defends them, owns the consequences, and can rank problems against what the business actually feels.
Situation
Mid-level answer
Senior answer
Asked about a language feature
Correct definition, few tradeoffs
Definition plus when it matters and what it costs
Handed unfamiliar code
Wants to rewrite the confusing part
Reads first, pins behavior with tests, small steps
Given a slow page
Proposes a fix immediately
Measures first, can say how to confirm the cause
Asked about a failure
Other people caused the problems
Owns a specific mistake and what it changed
Describing past work
Lists tickets that were completed
Describes decisions made and defended
Asked to explain a tradeoff
Reaches for jargon
Plain language, honest cost on both sides
Titles inflate, so treat the word senior on a resume as a claim to be tested rather than a fact. The question about a refactor they started and abandoned does more work here than any other on the page, because it requires having owned something long enough to watch the cost overtake the benefit.
Follow-Ups, Signals, and Red Flags
The prepared questions open the door; the follow-ups are where the evidence is. Push for the specific number, the actual outcome, and the decision they personally made, and watch for the patterns below across the whole hour rather than in any single answer.
Diagnosis signals
Measures before proposing a fix
Can say how they would confirm the cause
Separates database time from everything else
Inherited-code signals
Reads the code before judging it
Small reversible steps, not one giant branch
Pins behavior with tests before refactoring
Ownership signals
Has been on call and speaks about it plainly
Rollback described from memory, not theory
Treats old dependencies as security risk
Red flags
Rewrite proposed before reading anything
Every past codebase and team was terrible
Jargon used instead of a plain explanation
No single red flag is disqualifying. A rewrite proposal before reading anything is the one worth probing hardest, because at a small company the job is mostly the opposite of that.
Scoring the Interview
Score each of the six areas from 1 to 5 with one line of written evidence, immediately after the interview while the answers are still fresh. A score with no evidence beside it is a gut feeling wearing a number, and it will not survive a disagreement two days later.
If more than one person interviews, everyone scores alone before anyone speaks. Technical debates anchor hard, and the person with the strongest vocabulary usually wins the room regardless of the evidence. Our interview evaluation form works as a general-purpose version of the same discipline.
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
There is no federal wage series for Ruby developers, because occupations are classified by role rather than by programming language. The nearest classification is software developers, SOC 15-1252, and the honest way to use it is the percentile ladder rather than the headline median.
Software Developers, National Wages
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers (SOC 15-1252) had a national median annual wage of $135,980, with the 25th percentile at $105,210, the 75th percentile at $171,980, and the 90th percentile at $214,670. The 10th percentile was $82,460 (U.S. Bureau of Labor Statistics, OEWS national estimates).
Percentile
Annual wage (BLS OEWS, May 2025)
How to read it
10th
$82,460
Early career, not a senior benchmark
25th
$105,210
Junior to lower mid-level
50th (median)
$135,980
Mid-level to early senior
75th
$171,980
The realistic senior anchor
90th
$214,670
Staff and principal scope
Anchor a senior individual contributor near the 75th percentile, then adjust for your market and for whether the role carries architecture ownership or delivery only. Read our guide to salary benchmarking before setting a band, and publish a good-faith range wherever pay transparency laws apply.
Two practical notes. The federal occupation profile for software developers covers a far wider population than senior Ruby specialists, so treat the ladder as a map rather than a quote. And most senior software roles are exempt from overtime under the Department of Labor computer employee exemption, which has its own salary and duties conditions. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
A fair interview and an accurate one are the same interview. Asking every candidate the same job-related questions produces comparable evidence, reduces bias, and keeps you away from the questions that create legal risk, which are collected in our guide to illegal interview questions.
Ask every candidate the same questions
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on-the-job performance better than a free-flowing technical chat, and it is also the simplest protection against a decision that rests on rapport. Technical interviews drift more than most, because a conversation about a shared favorite topic feels productive while producing no comparable evidence. Pick the sets that match your role, decide the order, and ask them the same way every time. Keep the follow-up questions open, so a candidate who takes a different route still gets credit for the reasoning.
Keep every question tied to the job
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they are asked as friendly small talk. In a developer interview the traps are usually casual: how long someone has been programming as a proxy for age, where they are originally from, family plans raised while discussing on-call, or a health question raised while discussing hours. Ask about the ability to do the work instead. Every question in these sets is written to stay on the job. This is general information, not legal advice.
Score independently, then discuss
When two people interview, both should score the rubric alone before either says a word out loud. Technical debates anchor hard: one confident opinion about a framework choice can move a whole panel, and the person with the strongest technical vocabulary in the room usually wins the discussion regardless of who has the better evidence. Compare written scores first, then talk about where they diverge. That single habit turns a debate into a decision, and it costs nothing but the discipline to stay quiet for five minutes.
Weight the sets before you interview anyone
A senior Ruby developer joining a three-person team with an eight-year-old application is a different hire from one joining a newer codebase alongside an existing engineering lead. Decide the weights first. If the app is old, the inherited-codebase set carries the most signal. If the hire will be your only developer, testing and production ownership matters more than language trivia. Setting the weights before you meet anyone stops you from quietly re-weighting them to fit the candidate you enjoyed talking to most.
Structure Beats Conversation
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation, and asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics. Technical interviews drift more than most, so the structure matters more here, not less.
Keep the small talk on the job as well. In a developer interview the traps usually arrive as friendly curiosity: how long someone has been programming used as a proxy for age, where they are originally from, or family plans raised while discussing on-call. This is general information, not legal advice.
Interviewing Without an HR Department
At a large company a senior engineering candidate runs a coordinated loop with a recruiter collecting scorecards. At a small business the owner usually runs the interview alone, between everything else, and then hands the entire codebase to whoever they choose. Here is how to make that one hour hold up.
You are hiring a senior Ruby developer and you do not write Ruby
This is the normal situation at a small company, and it is more manageable than it feels. You are not grading syntax. You are grading whether a specific reason sits underneath every answer, whether the candidate measures before changing things, and whether they can explain a tradeoff to you without hiding behind vocabulary. Each question in these sets comes with why it is worth asking and what a strong answer sounds like, so you can score the shape of the answer even when the content is unfamiliar. If you want a second opinion on the technical detail, pay a senior developer you trust for two hours to sit in on the final round.
The candidate will probably inherit code, not start fresh
Ruby hiring at a small business is usually maintenance and modernization work on an application that already carries the business. That changes what you should test for. The person who interviews best on language internals is not always the person who can walk into an unfamiliar app, resist the urge to rewrite it, and ship something useful in the first week. The inherited-codebase set exists for exactly this, and the question about a refactor they abandoned is the single most revealing one on the page. If your app is more than three years old, weight that set above everything else.
One interview decides who owns your entire application
With no CTO above them, a senior Ruby hire ends up owning the codebase, the deployment path, and the phone call when the site is down. That concentration of responsibility is exactly why the decision should rest on written evidence rather than on who was most enjoyable to talk to. Score every area, keep the notes, and check references specifically on ownership and follow-through. Once you choose someone, the work shifts to hiring them well: FirstHR handles the offer letter and e-signature, the new hire paperwork, the confidentiality and intellectual property acknowledgments, and the onboarding checklist that gets them access on day one. Applicant tracking is coming soon to FirstHR.
Two cheap additions raise the accuracy of the whole process. Pay a senior developer you trust for two hours in the final round if you want a second technical opinion, and check references specifically on ownership and follow-through rather than on general impressions. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
Once you choose someone, speed is the whole game. A senior developer is usually in two other processes, so a written offer letter that arrives the same day beats a better package that arrives next week. Then the job becomes making the first week feel organized.
Send the offer quickly
Confirm title, pay, remote expectations, and start date in writing with e-signature. A senior developer is usually in two other processes, so a slow week costs you the hire.
Sign the security paperwork
Confidentiality and intellectual property acknowledgments signed before any access is granted, not chased down three weeks later.
Have access ready on day one
Repository, staging, error tracking, database, and the deployment path, provisioned with least privilege before the first morning.
Keep the hiring record
Store the scorecards, the signed offer, and the standard new hire forms in one place so the file is complete and easy to find later.
Access is the part small companies get wrong most often. Nothing signals a serious employer faster than an engineer who can run the app locally and ship a small change in week one, and our guide to developer onboarding covers the sequence in detail.
Week one
Local environment running, one small change shipped to production, and a walk through a real request end to end with whoever knows the app best.
Month one
Owns one area outright, has written down what they found, and has named the two things they think are worth fixing first.
Month two
The upgrade or performance work they proposed is underway in small merged steps, with the test suite protecting it.
Month three
A written check-in against what you agreed at the offer stage, covering ownership, shipping pace, and anything still blocking them.
FirstHR connects the offer, e-signature, new hire paperwork, policy acknowledgments, and the onboarding checklist in one place, and keeps the signed documents and the hiring record on the employee profile. FirstHR is an onboarding and HR platform, not a payroll provider and not an engineering tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Score reasoning, not definitions: every question here has a memorized answer and a reasoning answer, and only the second predicts anything.
Weight the inherited-codebase set highest if your application is more than three years old, because maintenance is the actual job.
Ask how would you know that was the cause after every diagnosis; it is the follow-up rehearsed candidates have not prepared for.
Judge seniority by scope and owned decisions rather than years, and treat the title on a resume as a claim to be tested.
Anchor pay near the 75th percentile for software developers, $171,980 nationally (BLS OEWS, May 2025), then adjust for your market.
Ask every candidate the same questions, score each area 1 to 5 with written evidence, and score independently before anyone discusses.
Frequently Asked Questions
What questions should I ask a senior Ruby developer?
Ask questions that test reasoning rather than recall, across five areas: Ruby and Rails depth, judgment inside an inherited codebase, performance and data work, testing and production ownership, and seniority. Strong openers include when they reach for a module instead of inheritance, where metaprogramming earned its keep and where they regretted it, how they sequence a framework upgrade, what they do when the code they must change has no tests, what makes a background job safe to retry, and a refactor they started and abandoned. Every one of those has a memorized definition answer and a reasoning answer, and only the second is worth scoring. Follow each answer with how would you know that was the cause, which is the question rehearsed candidates have not prepared for.
How do I interview a senior Ruby developer if I do not write Ruby?
You grade the shape of the answer, not the syntax. A strong answer attaches a specific reason to every definition, names what the choice cost as well as what it gained, and describes measuring something before changing it. A weak answer is a correct definition with nothing underneath, or a fix proposed before anyone has established the cause. Ask the candidate to explain one tradeoff as if you do not write code, because a senior developer at a small company has to do that with you regularly, and jargon used as a shield is a genuine warning sign. Each question set on this page pairs the question with what a strong answer sounds like. If you want extra confidence, pay a senior developer you trust to join the final round for two hours.
What separates a senior Ruby developer from a mid-level one?
Scope and judgment, not years. A mid-level developer completes the work assigned to them and gives correct answers about the language. A senior developer makes and defends decisions, owns the consequences, and can rank problems against business impact rather than personal preference. The difference is clearest in three places. Faced with unfamiliar code, a mid-level candidate wants to rewrite the confusing part while a senior reads first and pins behavior with tests. Faced with a slow page, a mid-level candidate proposes a fix while a senior measures. Asked about failure, a mid-level candidate describes problems other people caused while a senior names a specific mistake of their own and what it changed in how they work. The scorecard on this page includes a side-by-side guide for these.
Should I give a senior Ruby candidate a coding test?
Give a short, paid, realistic exercise rather than a long unpaid project or a whiteboard puzzle. Senior candidates with options routinely decline multi-day take-home assignments, and algorithm puzzles measure interview practice more than they measure the job. Two formats work well at a small company. Ask the candidate to review a short file from your own codebase out loud and note what they find first, which grades exactly the judgment you are hiring for and works even if you cannot write Ruby yourself. Or give a small, time-capped task with stated evaluation criteria and pay for the time. Either way, tell the candidate in advance how it will be judged, and give the same exercise to every finalist so the comparison means something.
How many interview rounds should a senior Ruby hire have?
Two or three rounds is the right target for a small business, and more than that starts costing you candidates. A practical structure is a 30-minute screening call covering scope, compensation range, and logistics, then a 60 to 90 minute technical interview using two or three of the question sets on this page, then a short final conversation with the owner covering ownership expectations and the first ninety days. Decide within two business days of the final round, because a senior developer with options is usually deep in another process at the same time. Compressing rounds does not mean compressing rigor: the same questions, asked of everyone and scored on the same rubric, produces better evidence in two hours than five unstructured conversations produce in three weeks.
How much does a senior Ruby developer cost?
There is no federal wage series for Ruby specifically, because occupations are classified by role rather than by programming language. The nearest classification is software developers, SOC 15-1252. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a national median annual wage of $135,980, with the 25th percentile at $105,210, the 75th percentile at $171,980, and the 90th percentile at $214,670. A senior individual contributor generally anchors near the 75th percentile, so roughly $172,000 nationally before adjusting for your market. Read the ladder as a leveling map rather than a single number, and adjust for location, industry, and whether the role carries architecture ownership or delivery only. Most senior software roles are exempt from overtime under the federal computer employee exemption.
What are the red flags in a senior Ruby developer interview?
The clearest red flag is a rewrite proposed before the candidate has read anything, because it usually signals someone who prefers building new systems to owning existing ones, and at a small company the job is mostly the second. Others worth catching: every previous codebase and team was terrible, which is a pattern rather than bad luck; no answer at all to what decision they got wrong; definitions recited with no reasoning underneath; jargon deployed when you ask for a plain explanation; and a rollback process described in theory by someone who has never performed one. None of these is automatically disqualifying on its own. Treat them as prompts to probe harder, write down what you heard, and let the pattern across the whole interview decide.
Are these Ruby developer interview questions legal to ask?
Yes. Questions about technical experience, how a candidate approaches specific problems, decisions they have owned, and how they work with a team are job-related and permitted. The legal caution is general to all interviewing: avoid anything that probes characteristics protected under federal law, which the EEOC enforces, including age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In a developer interview those usually arrive as small talk, such as how long someone has been programming used as an age proxy, where they are originally from, or family questions raised while discussing on-call. Asking the same job-related questions of every candidate and scoring them on the same rubric is the simplest way to stay both fair and consistent. This is general information, not legal advice.
