Hiring a developer when you’re not technical is one of the harder things a non-technical founder has to do. You can’t evaluate the code. You don’t know if the answers you’re getting are good ones. You’re basically trying to hire a surgeon without being able to read an X-ray.
I’ve helped a few clients work through this. Here’s what actually works when you need to hire a Rails developer but don’t know Rails yourself.
Get Clear on What You Need First
Most businesses hire a developer before they’ve defined the problem clearly enough to know what kind of developer they need. That’s backwards.
Answer these before you start looking:
Is this greenfield or maintenance? Building something new from scratch is completely different from improving something that already exists. Some developers are great at one and terrible at the other.
How much complexity is involved? A simple marketing site is not the same as an order management system with third-party ERP integration. Be honest about what you’re building.
Do you need someone long-term or for a project? Permanent hire versus contractor versus project engagement — these are different people.
What’s your budget? Good Rails developers cost real money. Junior developers cost less and can be valuable, but they need mentorship. If you’re hiring a junior developer to build your production application without technical oversight, you’re setting yourself up to rebuild the whole thing in two years.
Where to Find Rails Developers
Rails-specific communities. The Ruby on Rails subreddit, the Ruby community Slack, Ruby Central’s job board. These are where Rails developers actually hang out.
Toptal and Gun.io for vetted freelancers. They screen candidates, which helps when you can’t. More expensive, but the quality floor is higher.
Referrals. If you know anyone in tech, ask who they’ve worked with and trusted. A genuine referral is worth ten cold applications.
Upwork — with serious caution. The quality range is enormous. You can find excellent developers on Upwork, but you can also find people who look great on paper and disappear after the deposit clears. Do not hire someone on Upwork for a large project without a small paid test first.
Direct outreach. Find Rails developers with public GitHub profiles, look at their work, reach out directly. Time-consuming but you’re filtering for people who write real code in public.
Interview Questions That Work When You’re Not Technical
You can’t ask coding questions and evaluate the answers. But you can evaluate how someone thinks.
“Tell me about the last application you built in Rails. What was hard about it and how did you handle it?”
Good developers have clear answers. They can explain what they built in terms you can follow, identify what was genuinely challenging (not just “it was complex”), and describe how they made decisions. Watch for specificity — vague answers about “complex architecture” without details are a warning sign.
“Walk me through how you’d approach building [specific thing you need].”
You’re not evaluating technical correctness — you’re seeing whether they ask clarifying questions, think about trade-offs, and have a coherent approach. Good developers don’t immediately start describing implementation. They make sure they understand the problem first.
“What’s something you built that you’d do differently now?”
This separates developers who think critically about their work from those who believe their code is always right. The answer doesn’t need to be technical — the key is whether they can reflect honestly on their decisions.
“How do you handle it when you disagree with a client’s direction?”
You need someone who’ll push back when something doesn’t make sense, but who respects that you’re the decision-maker. The right answer involves expressing the concern clearly, explaining why, and then ultimately respecting your choice.
The Paid Test Project
Before committing to a big engagement, do a small paid test. Give the candidate a well-defined task — something real but small — and pay them their standard rate. Then evaluate:
- Did they understand the requirements or ask good clarifying questions?
- Did they deliver what was asked or something adjacent to it?
- Is the code readable and structured reasonably?
- Did they communicate during the process or disappear and surface with a finished product?
- Did they finish within the estimate?
A paid test isn’t foolproof but it’s much better than interviews alone. Most good developers are comfortable with this.
Get a Technical Advisor
If you’re hiring for a significant role or project, pay someone technical for a couple hours to review candidates’ code samples, sit in on technical interviews, and give you a second opinion.
This doesn’t need to be expensive. $500-$1,000 in consulting fees to validate a hiring decision on a role that will cost you $80,000-$150,000 annually is extremely good ROI.
Green Flags
- They talk about the problem before the solution
- They’re honest about what they don’t know
- They have examples of production code they can share or discuss
- They ask about your business goals, not just the technical requirements
- They have opinions and can back them up with reasoning
- They’ve maintained systems, not just built them
Red Flags
- They promise fast delivery on everything without scoping it
- They can’t explain technical decisions in plain English
- Their references are vague or unavailable
- They avoid talking about past failures or mistakes
- They quote significantly below market rates for senior-level work (this usually means you’re getting junior work at senior-looking rates)
Hiring is hard. If you want a direct conversation about whether I’m the right fit for what you’re building — or if you’d like a technical advisor perspective on a candidate you’re evaluating — reach out. I’m direct about what I can and can’t do, and I’ll tell you if what you need isn’t what I offer.