I've seen programmers that were hired specifically for C++ positions struggle to move to J2EE projects, and it wasn't pretty. It's usually not a good idea to hire one trick ponies.
I've seen programmers that were hired specifically for C++ positions struggle to move to J2EE projects, and it wasn't pretty. It's usually not a good idea to hire one trick ponies.
If you are hiring for a position where the developer will work primarily with Ruby, it makes sense to ask Ruby-specific questions or have a Ruby coding exercise. That shouldn't be the whole interview of course; as you mention, an all-around strong candidate is preferable.
That said, the questions in the article don't require much Ruby experience. Anyone with a grasp of OOP concepts could probably get most of them right.
Of course there are exceptions where you need domain expertise, but I find these situations to be very rare. I'm actually thinking that asking the candidate to design the structure of his own interview might not be a bad idea - you can probably learn a ton about the candidate and avoid the trap of hiring clones of yourself.
It is not a buyer's market for Ruby devs. Any post that suggests you screen a candidate based on whether they know what the "||=" operator does is offering bad advice.
I find his answer to his own questions about proc/lambda/blocks unsatisfying since that would be IMHO a good question to identify people who know ruby well.