Ruby on Rails (RoR) is sometimes referred to as the crown jewel in a developer’s resume, and for good reason: Knowing the popular open-source Web development framework can increase your value to your organization, as well as your annual pay. Milan Dobrota, solutions architect, team lead and Ruby on Rails developer for Tribune Media Company, has been using Ruby on Rails since 2008. When trying to establish a baseline for a candidate’s experience with Ruby on Rails, he asks intermediate-level questions such as the following: What's the purpose of Ruby’s modules?

• What Most People Say: “In Ruby, modules are used for namespacing.”
• What You Should Say: “Ruby’s modules serve two functions: namespacing and code reuse. Reusing code is more efficient because you can change things in one place in the code and it reflects in other places, while namespacing eliminates potential name clashes.”
• Why You Should Say It: Most programming languages don’t have modules, so being able to name all of Ruby modules' functions/applications and explain how they are used demonstrates greater experience and in-depth knowledge of RoR.

Check out the latest Ruby on Rails jobs. What are "before" filters? Give me an example of when you’ve used one.

• What Most People Say: “I’ve never used a filter in Ruby.”
• What You Should Say: “In Rails, a filter is a method that gets executed before, after or around certain controller actions. For instance, I generally use a "before" filter to authenticate users before giving them permission to execute an action in an application.”
• Why You Should Say It: A novice won’t be familiar with Ruby’s filters. An intermediate-level candidate may have noticed a filter when they copied and pasted code that contained a filter; an experienced pro, however, can explain the purpose of Ruby’s filters and when to use one.

How do you look at the source code of a gem that's installed in your app?

• What Most People Say: “I look up the source code on GitHub.”
• What You Should Say: “Sometimes, the full source code for a gem is housed in a public repository like GitHub, but you can open it in your editor, as well. If you use a bundler, then you can open the code for a gem by entering the following from the command line: bundle open <gem name>. You can also look at the source code manually by running: cd $GEM_HOME and finding the gem there.”
• Why You Should Say It: Internal gems aren’t open-source, so you need to know alternate ways to view their source code. Plus, there are faster, more efficient ways to view a gem’s source code than looking it up on GitHub.