I tend to ask, not how you use the framework, but rather how the framework works. How does routing actually work? How do named scopes work? How would you implement the {before|after} filters on models... etc.
It's actually somewhat more difficult to tell whether someone knows how to use Rails well. My only suggestion is to sit down in front of an editor with them and work through actually building something small but meaningful.
If someone asks me how Rails works, I wouldn't be able to answer. It's just something I don't care about. Sure, give me a few hours and I'll figure out everything you asked for, but right off the bat? No way.
In my opinion, that's a problem. If you don't understand what is actually going on under the hood, you're likely to get bitten when things don't go exactly as you expect.
ActiveRecord is the most obvious example of this. If you don't know what queries it's going to throw out for a particular call, it may work just fine in development but could easily bring down a site in seconds in production.
Routing is another example. If you have a particular action that needs to have as low latency as possible changing its position in the routing file is often one of the easiest and most effectual changes you can make. Someone who just codes in the framework and doesn't understand how it works is unlikely to realize that.
I'd ask the candidate to pair program with a developer for a week. You'll know immediately if the candidate can integrate with the team. Plus it'll reveal his knowledge during the session.
Could be wrong, but I think the question was "what interview questions?" The interview is, for argument's sake, the second screen (the first one being the review of the cover letter/email and resume/cv or whatever). The third screen might be an audition or trial, such as you've described.
I wish I had the time to sit down with every candidate and program with them for a week :) Unfortunately, none of us do, so I'm looking to come up with a handful of questions that can effectively weed out the inexperienced from the experienced as early as possible in the hiring process.
They don't necessarily have to be questions like "How does routing work in Rails?", they could be "interactive" questions that involve writing a relatively small amount of code (e.g. write a Generator to do X).
Ask them to develop something that involves caching the paginated search results of a double-nested resource with file attachments in as little time as possible. hehe
I generally find that asking specific questions about a technology or technique is not really valuable. My preferred method of interviewing is to sit down and talk with the candidate about "stuff", which should include said technologies/techniques. After a fashion you will get a good understanding of what they know about the subject; where they are strong and where they are just blowing smoke. You'll also know more about how they would integrate into your team.
So just relax and talk to the candidate and don't worry about asking the magic questions that will answer all your prayers. :)
Not only that, but a prospective rails developer should have at least a handful of released projects/plugins, so the last thing you should be talking about is Rails.
I might ask the interviewee about stuff from the future of rails. If answered correctly, it shows how someone can be in a continuous learning mode and eager to go the extra mile.
14 comments
[ 4.9 ms ] story [ 37.5 ms ] threadIt's actually somewhat more difficult to tell whether someone knows how to use Rails well. My only suggestion is to sit down in front of an editor with them and work through actually building something small but meaningful.
ActiveRecord is the most obvious example of this. If you don't know what queries it's going to throw out for a particular call, it may work just fine in development but could easily bring down a site in seconds in production.
Routing is another example. If you have a particular action that needs to have as low latency as possible changing its position in the routing file is often one of the easiest and most effectual changes you can make. Someone who just codes in the framework and doesn't understand how it works is unlikely to realize that.
Models, or controllers? :)
So just relax and talk to the candidate and don't worry about asking the magic questions that will answer all your prayers. :)