Bad Ruby/Rails interviews

A few of my colleagues from a previous project were recently laid off.

I won’t go into the absurdity of the fact that their company was bought out and the new owners decided they didn’t like the project the developers were working on and showed them the door the very next day with no severance (seriously, who ever negotiated a buyout where the employees are left completely unprotected from the new owners?!).

What I’d like to talk about is what makes a good interview.  One of the guys recently went to an interview for a Rails job with a big-name magazine.  Here is the account of what happened (as told to me).

First, no Rails specific questions were asked, they were all Ruby questions.  That’s a little off-putting, but not a big surprise considering the unique boat that Rails is in.  The nature of the questions, however, were equally confusing.  Here’s an example:

Make a method that reverses a string…without using reverse

Okay, I’d say that this is a relatively easy question, and is probably something that a prospective candidate should know.  But this question still has some major problems when being used to gauge a developer.  Here are my issues with it:

  1. Arrays, Enumerables, and Strings have huge numbers of helper methods.  I would want any Ruby developer to instantly to be able to tell me uses for map, inject, etc, but each_char is not high on the list.  I can’t even recall the last time I used each_char.  Should an interview really hinge on such a random request?
  2. There is no good way to write a replacement for reverse, so why are you asking someone to do so? This question was obviously asked by someone with a C/Java background and formal CS training (don’t yell at me yet…I’m a former C programmer with formal CS training too!).  The point is that this question clearly shows a mindset that doesn’t truly apply to Ruby.  If this were C, there would be an in-depth discussion here about manipulating the char array and the most efficient way to do so.  In Ruby, you don’t really have a choice without access to the underlying representation of the string.  You have to iterate through the object and then stuff it into a new string.
  3. Ruby 1.8 has weird string handling.  If I couldn’t immediately remember each_char, my next approach would be to just iterate backwards with a more normal C style loop.  However, as we know, doing some_string[i] returns an integer, not a single char string.  Great.  Now I have to remember how to convert that int back into a string (ah yes! chr!)
  4. Ruby 1.9 changes the whole game.  String iterators are changing.  As I recall from Matz’s keynote last year at RubyConf, there are so many ways to iterate through a string (char, word, line, etc) that a new paradigm is needed.  How much do you want to bet the interviewer didn’t even know that things were changing?
  5. This question doesn’t tell you anything about the person’s knowledge of Ruby.  Get into some procs, send, mixins, alias chains, or some meta programming if you actually want to test for an understanding of the language.

Unfortunately, our story doesn’t have a pleasant ending.  Not only were his chances at the job ruined because of this one question, it turns out that this is the process for all applicants.  They are progressively given a series of questions throughout the interview process.   Each question has exactly one right answer (yea right!) and the applicant must get every one right in order to be offered the position.  They stopped the interview right there and showed him the door, no chance for any other questions.  I think they’ll be looking for quite awhile.

Leave a Reply

Your email address will not be published. Required fields are marked *