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 a couple of days only), 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.
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. 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 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. That's in optimizing algorithm performance when needed. Also, they 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. 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. 

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.