HOME
Blog
Projects
Heard-Read-Saw
Contact

17 October 2022

Please show me a Gemfile

"Elementary, my dear Watson. This file is a hidden gem!"

TL;DR: If you want to learn more about a company during an interview process, try getting your eyes on a Gemfile and save yourself some time for more targeted questions.

A Gemfile paints the big picture of a system's dependency; it's the identity card of an application. Programming is mostly about managing dependencies and inspecting a Gemfile can give you a feel for a system's overall health, technical debt and enforced engineering practices.

Take your conclusions with a grain of salt, as you'll make a lot of assumptions. This article outlines some things to look out for and questions to ask ourselves when reading a Gemfile.

5 minutes and counting

Have you ever been in a job interview with 5 minutes to learn about an employer's engineering practices? It often goes like this. An employer schedules a 1-hour technical interview, spends 55 minutes assessing your skills and then generously returns the favour asking, with a smile:

Wow, we're nearly at the end of the meeting, lmao. Do you have any questions?

Lots! Tell me about the company values, your engineering culture, your delivery process, your challenges, what you're looking for in a candidate, and … tell me your stack. Your possible options are asking one or two questions, going overtime, emailing more questions, or scheduling extra interviews with future team members.

With that in mind, asking to see a Gemfile during an interview is a quick way to screen a system and spark some interesting conversations. Here is why:

Alright then, keep your secrets

Let's tackle the elephant in the room. Interviewers might not want to show you a Gemfile. If they don't.

In this case, ask them to list gems they're using. This will tell similar insights without compromising any IP or security concerns. If this doesn't work, well move on and ask other questions.

In the case, you access a Gemfile here is what you can discover.

Readability

While you can argue that a messy Gemfile doesn't say much, a clean one, on the other hand, shows care and is, overall, a positive sign.

Dependency strategy

Understanding whether a codebase relies excessively on gems to solve problems is a good insight. The more Ruby gems an application has, the more complex an upgrade can be. The harder an upgrade is, the more vulnerable to security issues an application gets. Finally, the use of unmaintained gems shows poor motivation to be in control of the application design.

On the other hand, a small number of gems can show care given before introducing dependencies. It can also show that developers love to write their own solutions to common problems. A Gemfile alone can't give you all the answers but can lead to more interesting questions.

The tech stack

This is the most straightforward insight

Here is a list of the most popular gems in 2022, and another one to know more about popular gems.

Depending on your experience, discovering these gems will spark many emotions: excitement, curiosity or despair. This perfectly transitions to the next point.

Red flags

Gems can be clues to specific design patterns and often come with drawbacks. It can give you an idea of the work ahead, especially if you spot gems you don't particularly like. Here are some personal feelings towards gems:

Negative feelings Neutral feelings Positive feelings
  • react-rails
  • simple_form
  • haml
  • factory-bot
  • cucumber-rails
  • grape
  • paperclip
  • webpacker
  • rspec
  • devise
  • rubocop
  • mysql2
  • papertrail
  • pundit
  • -
  • -
  • minitest
  • rack-mini-profiler
  • hotwire-rails
  • packwerk
  • bundler-audit
  • -
  • -
  • -

Versioning

While it is hard to spot without thorough research, inspecting versions of the main libraries can tell you how up-to-date a codebase is. Here are two great resources to learn more about gemfile versioning: Understanding Gemfile and Gemfil.lock, bundler documentation.

Different gem sources

Defining custom sources like :path or :github is an advanced practice and, like any technique, the value depends on its implementation.

Custom sources pointing to other company libraries show a motivation to extract some logic and modularize part of the system.

On the other hand, sources pointing to forked Ruby gems should raise alarms. There are a few scenarios where this is acceptable, and it often comes down to whether the company is actively contributing to Ruby's ecosystem.

If the codebase uses path: a lot, the codebase is likely to be a mono repository while git: or github: tends to show a company with many repositories. I'm generally suspicious of a multi-repository setup as getting the boundaries wrong and adding more friction to development is easy.

Conclusion

The amount of information a Gemfile gives you is not to be taken lightly. It gives you a clear picture of the current application stack, like the database or the testing suite. It can spark curiosity and lead to exciting questions during an interview. It can also reveal some engineering approaches teams take to solve problems.

Be careful though, decoding a Gemfile is a highly subjective exercise and therefore needs to be taken with a grain of salt. Practice by inspecting gemfiles you have access to. What conclusions can you draw? Which conclusions are positive? Which conclusions are negative?