Interviewing Ruby Software Engineers Is Easier Than Ever in 2025!

My team's approach to interviewing Ruby Software Engineers involves giving a candidate a small-size Rails web app project to complete over a week (some finish it in much less time), reviewing the solution to check if it follows good Software Engineering principles and practices, and conducting a follow-up interview meeting to ensure that the candidate did solve the project themselves and can answer follow-up questions that test their general Software Engineering skills and specific Ruby on Rails skills.

Regarding the follow-up interview, new developments in recent years have made it super-easy to interview Ruby Software Engineers and tell the good ones from the bad ones in 2025:

1. AI: Just ask a Ruby dev to tell you what they think of the Gen AI movement (e.g. Chat GPT) and its effects on Software Engineering. If they respond with anything other than stating facts like solving the right customer problems has a lot more effect on productivity than generating code, human interactions are more important for producing the best work possible than actually increasing machine interaction by replacing humans, or generating code isn't the bottleneck, yet maintaining it for years to come, then you have a dud on your hand, and you can safely eliminate that candidate from your hiring pool. In other words, even if AI was perfect, it's still better to have more human interaction as it brings new fresh ideas due and connects devs with their humanity, which yields a better understanding of customer needs and more creative solutions for their problems. Additionally, a smart candidate would recognize that using AI can be a bug in the requirements because Gen AI is fuzzy by nature while Software Engineers seek sure answers, so attempting to use a Gen AI is the wrong strategy from the get go as it doesn't satisfy the requirements, regardless of what sort of technical proficiency it has. AI can be great for gaming or art with its fuzzy nature, but terrible if a sure correct answer is needed. Furthermore, good candidates would recognize that AI is only as good as its input, so it often learns the answers that the average masses come up with, and even if it learns to provide good answers one day, after it ingests some more bad input for a while, it would unlearn what it learned and yield bad output. AI only provides the most common average solutions, but excellent Software Engineers come up with top-level solutions that are better than what's common, so again, AI limits top-level Software Engineers with that regard. I have observed that top-level engineers in the Software Engineering industry like Linus Torvalds, the creator of Linux, don't really care for AI. Only average devs care for AI. Many devs don't get this, making it easy to rule them out to find out the Software Engineers who are truly the best.
2. Microservices: Just ask a Ruby dev about their opinion of the Microservices architecture. If they claim it is necessary since day 1, you can safely deny the hiring candidate from further steps in your hiring process. If they completely dismiss Microservices and claim that everything can be solved by a Monolith, you can safely reject the candidate as well. The right answer would be a pragmatic "it depends on customer needs", and would describe adopting Microservices incrementally if needed only, while describing the pros, cons, and trade-offs for using different approaches, such as a Monolith, Rails Engines, and Microservices, clarifying that it is OK to adopt a hybrid approach instead of a black and white approach. Bonus points if the candidate recognizes that  "Microservice" is just a silly buzzword for what is more properly called "Web Service", which has been around since the early 2000s. 
3. New Programming Languages: Just ask the Ruby dev what they think of new programming languages like Elixir, Rust, Golang, TypeScript, Scala, and Clojure. If they respond with anything other than noting that the benefits of immutable FP are overhyped by people who have skill issues with OOP and aren't truly useful/necessary in a practical sense given that OOP, the more modern paradigm (FP is 70's style programming), operates just like how we naturally and intuitively think of the real world without having to go through a translation layer that maps everything into "functions", which loses half the battle, then you have a dud on your hand, and you can easily reject that candidate in your interviewing process. They still need to know what FP is useful for, numerical computing, like any sort of mathematical algorithms that truly represent functions in real life mathematics. Also, any sort of iteration over collections, which Ruby supports with its hybrid OOP/FP approach (e.g. using `reduce` or `map`, etc...). That said, also, if they respond with anything other than noting that in about 90% of Business App Development, dynamic typing enables better focus on business domain concerns (kinda like what Matz called driving auto in a recent RubyConf keynote speech) while static typing provides the illusion of better Software Development while actually making you work harder, take longer to finish features, and write more code overall while being distracted by types instead of focusing on business concerns, then you have a dud on your hand. Of course, they should still note where static typing is useful (kinda like what Matz called driving a stickshift at a recent RubyConf keynote). That's in optimizing algorithm performance when needed. Also, the candidate should demonstrate an open mind about being able to follow a polyglot's hybrid approach that relies on a dynamically typed OOP language for most basic features while calling out to a statically typed language for algorithms that need extra optimizations. That's kinda like how Ruby relies on C extensions or JRuby relies on Java. Candidates that fall easily for the hype of new programming languages without having the skills to discern what the pros, cons, and trade-offs are in each can be skipped in the hiring process.
4. React: Just ask a Ruby dev point blank what they think of React.js. If their reaction is anything but disgust and absolute dismay, you're interviewing a dud that can be rejected safely in the hiring process. That means they don't really understand Ruby well enough to notice all the ways React.js contradicts the Ruby way and destroys Rails productivity, and they don't really know Software Engineering principles and best practices enough to notice where React breaks them, which makes maintainability very complicated and expensive and lowers productivity as a result. Another question that immediately reveals frauds with this regards is "How would you feel if someone invents a better Frontend technology than React that doubles productivity, improves readability, and halves code?" If you notice complete lack of interest or excitement in the candidate, you know you have a dud as well, someone who is attached to technologies for purely emotional non-rational reasons instead of rationally choosing technologies to serve customers in the best way possible.
5. Glimmer DSL for Web (2025 Fukuoka Award Winning Ruby Frontend Framework for Rails): Just describe Glimmer DSL for Web to a hiring candidate and explain how it completely eliminates the need for all JS Frontend Frameworks by enabling Software Engineers to leverage the same great benefits of Ruby that they always loved, but in the Frontend, doubling productivity, improving readability/maintainability significantly, halving Frontend code, halving the workforce (Backend devs can now do Frontend development), and halving Frontend Development costs. If the Ruby dev doesn't jump up and down with excitement or doesn't at least show some curiosity to learn more about the library's possibilities for the customers' benefit, then you know you have a dud on your hand that can be safely dismissed in the hiring process.

The good news is that those same recent developments also help truly skilled Ruby Software Engineers maintain job security very easily. It's ironic that AI didn't actually decrease job security, yet increased it for proper Software Engineers who are the real deal in their profession. Rejoice in these times! Our jobs have gotten much easier while the market got worse as a whole. 

One last note is hire devs with the backbone to say no when the masses are heading in the wrong direction. If a dev who might have noticed that a technology like React was bad at first later on changed their mind and approved of it just because the majority started using that technology, then they are exactly the wrong kind of dev to hire. Never hire spineless pushovers. Even if they come up with very smart solutions sometimes, the quality of their work can always be compromised by their lack of spine to push back against popular yet bad solutions.

I'm happy one of my team's recent hires volunteered to help me with Glimmer DSL for Web open-source work, and another actually complimented me on winning an award for that project and expressed great excitement about joining my team because of that accomplishment and our use of a Ruby Frontend library in our Rails web app.