Commit’s peer-to-peer bot helps community members tap into the vast expertise of our peers and colleagues, asking questions that span the spectrum from technical to personal. Here’s the latest question and answers.
Christian Arab: In a recent technical interview I was asked: What are the downfalls of Rails? It felt like a vague and open-ended question to me (I am seeking my first junior role). I had asked in my follow-up if they could provide me with an opinion, or answers their team might see as relevant. Two days passed with no response. I’d be curious if anyone in our P2P community could share their thoughts.
Ricky Lee: I’m not much of an expert in Ruby, but for the second part, the follow-up, I have run into many companies not responding to interviewees after an interview. Whenever I experience these situations, I’ve used it as a source of motivation to understand or study more about it.
Phong Thieu: I’m not much of an expert in Ruby, but generally when a question like this is asked, you’re looking at a few standard items, like:
- Raw performance speed, especially at scale
- Structure, like abstraction, ability to refactor, ability to catch errors during compile time, runtime, etc.
- Complexity, like if you have to do crazy things for multiple I/O or multi-threading, memory management (i.e., C++)
- Ease of learning, ease of mastering, std lib, support from community and existing libraries, testing capabilities
- Opinionated vs flexibility
Most of the time they’re just want to see if you’ve looked into a language beyond just how to write some code.
Alex Gogan: I’m not a Rails dev myself, but I would love to provide some thoughts as an interviewer asking an open-ended question.
When asking a question like this I’m mainly looking at:
- Does the person know said framework/tool/pattern/concept?
- Are trade-offs clearly explained?
- Is there an understanding of when to use it and when not to (close to tradeoffs)?
- All of the above that Phong mentioned
What shows me a lot of character during an interview is:
- Being open about what you know and what you assume
- Stating your assumption and provide an answer based on it. E.g. “I’m not deeply familiar with Rails, but I know it is a popular, opinionated framework in Ruby. I can imagine that being very opinionated means that you will need to learn and understand the framework to achieve tasks and deviating from it might be challenging.”
With this, you show how you approach it without having a direct answer (yet).
Fábio Miranda: I found this article and I can share some experience.
- One of the worst criticisms is the high coupling with ActiveRecord (database). This is debatable, if you like the framework it won’t hurt that much, if you dislike it it will be tough to live with.
- The performance is usually mentioned as a downfall, but as the article explains, it won’t be a problem unless your application becomes very popular.
- Ruby and RoR maintainers have been working to improve the performance, and there are many caching or database approaches to overcome the challenges. But cache and database scaling is something you have to learn independent of the language or framework.
- RoR is an opinionated framework, and if you are comfortable accepting the architectural patterns and decisions of the authors, you’ll probably be very productive in your work.
- Some of the hardest legacy systems I had to maintain were a result of attempts to overhaul Rails, building other layers of abstractions on top of the standards. This is the worst scenario: you have to learn the framework and the project-specific abstractions.
- Ruby is powerful and flexible, which means it’s a sharp weapon. If your application is not well covered by tests (at least 90%), even naive things like adding a gem can cause side effects, memory overhead, etc.
Thiago Araujo: These types of questions can have good intentions when the interviewer really wants to know if you understand the downsides of using a specific technology. But they can also be leading questions when the interviewer has a negative view of a technology and just wants you to say something bad about technology X because they would agree with that. So it’s hard to tell from our side.
Just adding to the points others have made above:
- Trying to fit any application into the MVC model can be challenging, specially if you need a more service-oriented architecture. In that case, Rails might not the best choice.
- Although the community sees the excessive use of active record callbacks as a bad practice, there is nothing stopping you from abusing them.
- The recent changes on the asset pipeline (from Sprockets to Webpacker, and now the introduction of esbuild) still cause a lot of confusion.
- Any of the criticisms against monolithic applications could be applied to Rails.
- It’s very hard to find experienced Rails developers in the current market, which can cause trouble with recruiting, if you need to grow the dev team really quickly
- Legacy Rails codebases tend to attract a lot of cruft, and I often hear about many of the so-called “Rails rescue projects” that are usually old Rails codebases (Rails pre-4.0) that were never properly maintained or updated. That’s not a criticism of Rails per se, as this happens everywhere. This is more a problem related to development teams not following good practices and conventions, not writing enough tests and not being careful. But that’s one thing you could mention.
There’s also the “Rails doesn’t scale meme” you might hear sometimes, but I wouldn’t mention that in an interview, as this is not really true and it can make the interviewer angry.
Christian Arab: Hey everyone! Thanks for answering my question and sharing your opinions. I will keep them all in mind for my (many more to come) interviews.
✅ ✅ ✅