ben vandgrift · on living the dream

ruby / rails interview questions

i've been digging around lately for interview questions to use when interviewing a ruby and rails candidate.

there are few good resources for this:


joe sniff

i'm adding a few more with some solutions, designed to test the breadth of someone's knowledge.

what do you not like about ruby on rails? identify its weak points.

the answers i expect here are fixtures, routes, scalability. bonus points for identifying the weakness in using multiple databases.

a good followup on scalability is: how have you in the past dealt with the scalability problems, and what does your preferred deployment environment look like?

what is the difference between a symbol and a string? when should they be used?

a symbol has a shorter reference number, which makes it faster to look up. if you're using something as a reference string, a symbol is a good idea. if you're planning on a string being editable, then a string is a better idea.

good information on this here: 13 ways of looking at a ruby symbol

when would you use request.xhr?

to test for an XmlHttpRequest, if you were writing a single method to deal with each request type. bonus: this has been dusted somewhat in rails 2, wherein you deal with the response where it belongs, in the response:

def action
  # .. some code
  respond_to do |format| do
    format.html { ... }
    format.js  { ... }
    format.xml  { ... }

when would you use has_many :through?

to create an association without creating a new table, if the information can be related through an existing table.

when would you use a polymorphic association? is there a better method?

the better method is has_many_polymorphs. generally, you want to use a polymorphic association when you want to treat a group of objects uniformly from a parent's point of view.

when is it appropriate to use a helper method? where should that helper method live?

helper methods should generate markup. that is all. the helper method should live in the controller of a particular object if that markup is particular that object, especially if it is similar or has the same method signature across a number of objects, and each is handled differently (but share partials). generally applicable helpers should live in the helpers directory as modules:

  def clean_date_url(date)
    url_for :controller => 'home', 
      :action => 'list_by_date',
      :year => date.year,
      :month => ("%02d" % date.month), 
      :day => ("%02d" %

explain the use of modules in controllers, and give an example?

modules can be used across several controller which have the same functionality. if your controllers are divided differently than by object, you might include a modules for a particular type of object. say you wanted to post a blog entry into a number of different controllers, you might write a module which handled blog posting and validation, associated with a particular editor partial, and include it in every controller that wanted that functionality. partial/module pairings are very nice ways to keep things DRY.

when should namespaced controllers be used? describe the effect this has on routes.rb.

this is often a common way to organize functionality, or to create different before_filter scenarios. creating a namespaced subdirectory from the controllers directory to contain the namespaced controllers keeps the routes file fairly clean. your routes file might end up looking something like this:

map.resources :whatsits, 
  :controller => 'manage/whatsits',
  :path_prefix => '/manage'

when would you use multiple databases in a single rails app? explain.

for an app which shares a database with another (perhaps non-rails) app, using that database directly might be the thing to do, especially if the data occurs only for reference (say, zipcode mapping information), and is read-only. this is something of a weakness in rails, but is accomplished as follows:

class Location < ActiveRecord::Base
  establish_connection :locations

  # more methods, etc.

:locations is, in this example, a database configuration in database.yml.

when is it appropriate to use the following to modify data in the application? rake task, console, db client such as mysql?

rake tasks are appropriate for a long-running and complex data modification (say, calculating everyone's distance from the home office, after that functionality has been added into a live database.). console is appropriate for limited changes which require validation. db client works when bypassing validation is required, and broad swaths of information want to be changed mercilessly. (though this should probably be in a migration, with execute.)

. how many ways are there to generate path information for a helper, such as 'link_to'?

the answers I look for are url_for(hash), hash, named_route, string. there's no real difference between url_for and hash. named_route is useful for making things readable and intuitive:

link_to @post.title,
  post_permalink_path(:permalink => @post.permalink)

where might you find information such as HTTP_REFERER and HTTP_ACCEPT_ENCODING?

in request.env["HTTP_REFERER"], etc.

what plugins do you use most?

any answer here is a good answer. the longer the list, the better i like the candidate, as it expresses breadth.

what are the pros and cons of using config.gem in environment.rb? when is this easy/difficult?

main pro: your app becomes more portable across many hosts. the main con: gems which require compilation can be difficult to manage and import.

give an example of using metaprogramming in a view or partial?

look for code here. to have a content element render a partial for its type, for instance?

pname = "shared/#{content.class.to_s.downcase}"
render :partial => pname, :object => content

when is STI an appropriate solution to a problem?

for similar models that have identical storage, but which express themselves or validate varyingly. different types of post in a blog spring to mind, different types of pets (Dog, Cat, Fish) and similar circumstance.

those are just a few thoughts. some of these are inobvious, and they are clearly meant to test the breadth of a developer's knowledge. i also like to ask a questions about jars and beans, but since that's not really ruby-related, i'll let it go.

written: Sep 20 2008