5 ms·

Questions to Ask During a Ruby Interview

9 points by matt1 17y ago

onewland 17y ago
That gotapi.com link is sweet. Is it commonly known?
- carbon8 17y ago
  I think so. I've been using it in a fluid app for a long time now. http://railsapi.com/ http://railsapi.com/ is good for Ruby, too, especially since it's customizable.
coffeemug 17y ago
I think a good question to think about is why someone would want to design an interview to specifically hire Ruby on Rails programmers. Other than a few very rare situations when you want an expert fast, what would a rails programmer offer that a C++ and Lisp programmer with a solid grasp of data structures and algorithms wouldn't? Even in the few cases when specialization is important, I still wouldn't design an interview entirely around Ruby on Rails. Every framework has some gotchas that you only learn with experience, but beyond that there is a ton of other stuff a good programmer should know that's outside the realm of any given framework, or even any given language. 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.
- lonestar 17y ago
  These interview questions were about Ruby, not Rails. 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.
  - coffeemug 17y ago
    I don't completely disagree with you, but a part in me wonders. Ruby isn't a conceptually challenging language - it doesn't introduce any new ideas that you wouldn't have known by coding a combination, of say, Lisp, Perl, and Python. So if you have an all-around strong candidate on your hands that didn't write a line of Ruby in his life, would you pass? I generally prefer candidates that can reason about language design issues - if you can hold your own in a discussion about whether objects or closures are more primitive, can code well in one or two unrelated languages, and can reason about algorithms in the abstract, it's extremely likely you'll have no trouble picking up Ruby within a very short period of time. 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.
  - tptacek 17y ago
    Coffeemug beat me to my comment about this post. We're an all Ruby shop, and I don't think we've ever hired someone who (a) knew Ruby well coming in and (b) wasn't up to speed in under a week. If you're strong with Python, Perl, or Lisp, you will do fine in Ruby. 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.
    - oscardelben 17y ago
      Yes but if you are looking to hire people who already know Ruby, they should know at least those basic questions.
      - xtho 17y ago
        The precise semantics of ||= were subject to a longer discussion on ruby-talk. I don't think it's really that important whether it expands to 1.) a || a = b or 2.) a = a || b, is it? So all you would know about a person giving answer 1) is that he/she was subscribed to ruby-talk at that time. 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.
ghotli 17y ago
I wouldn't design an interview just for a specific programming language. If they can prove to me that they understand OOP and functional programming concepts up to my standards, then they should be able to write useful code given a week or two to learn the language at hand. In the case of Ruby, this time line could potentially be shorter. The syntax is dead simple and the API is rather intuitive.
- oscardelben 17y ago
  The fact that the syntax is simple doesn't mean it's easy. I could learn lisp syntax in two days but that doesn't make me ready to work in a lisp shop.
deleted 17y ago
[deleted]
blasdel 17y ago
Variable typing is one of those topics that everyone sort of understands it, but is hard to put it into words. I’ve iterated and improved the next series of questions to really test a senior level candidate’s knowledge of static and dynamic typing. This is my best attempt so far. And a naive, inapt, incorrect, nomenclature-misusing attempt it is! Please read and re-read the nearly perfect "What To Know Before Debating Type Systems" before broaching this topic in any forum: http://www.pphsg.org/cdsmith/types.html http://www.pphsg.org/cdsmith/types.html
shin_lao 17y ago
I don't see a strong correlation between these questions and being a great programmer. Being a great programmer doesn't mean knowing the nomenclature. It is - in part - knowing which structure and algorithm is appropriate to solve a problem, and how to implement it efficiently with the given language.

9 points by matt1 17y ago

onewland 17y ago

That gotapi.com link is sweet. Is it commonly known?

carbon8 17y ago
I think so. I've been using it in a fluid app for a long time now. http://railsapi.com/ http://railsapi.com/ is good for Ruby, too, especially since it's customizable.

coffeemug 17y ago

I think a good question to think about is why someone would want to design an interview to specifically hire Ruby on Rails programmers. Other than a few very rare situations when you want an expert fast, what would a rails programmer offer that a C++ and Lisp programmer with a solid grasp of data structures and algorithms wouldn't? Even in the few cases when specialization is important, I still wouldn't design an interview entirely around Ruby on Rails. Every framework has some gotchas that you only learn with experience, but beyond that there is a ton of other stuff a good programmer should know that's outside the realm of any given framework, or even any given language. 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.

lonestar 17y ago
These interview questions were about Ruby, not Rails. 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.
- coffeemug 17y ago
  I don't completely disagree with you, but a part in me wonders. Ruby isn't a conceptually challenging language - it doesn't introduce any new ideas that you wouldn't have known by coding a combination, of say, Lisp, Perl, and Python. So if you have an all-around strong candidate on your hands that didn't write a line of Ruby in his life, would you pass? I generally prefer candidates that can reason about language design issues - if you can hold your own in a discussion about whether objects or closures are more primitive, can code well in one or two unrelated languages, and can reason about algorithms in the abstract, it's extremely likely you'll have no trouble picking up Ruby within a very short period of time. 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.
- tptacek 17y ago
  Coffeemug beat me to my comment about this post. We're an all Ruby shop, and I don't think we've ever hired someone who (a) knew Ruby well coming in and (b) wasn't up to speed in under a week. If you're strong with Python, Perl, or Lisp, you will do fine in Ruby. 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.
  - oscardelben 17y ago
    Yes but if you are looking to hire people who already know Ruby, they should know at least those basic questions.
    - xtho 17y ago
      The precise semantics of ||= were subject to a longer discussion on ruby-talk. I don't think it's really that important whether it expands to 1.) a || a = b or 2.) a = a || b, is it? So all you would know about a person giving answer 1) is that he/she was subscribed to ruby-talk at that time. 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.

ghotli 17y ago

I wouldn't design an interview just for a specific programming language. If they can prove to me that they understand OOP and functional programming concepts up to my standards, then they should be able to write useful code given a week or two to learn the language at hand. In the case of Ruby, this time line could potentially be shorter. The syntax is dead simple and the API is rather intuitive.

oscardelben 17y ago
The fact that the syntax is simple doesn't mean it's easy. I could learn lisp syntax in two days but that doesn't make me ready to work in a lisp shop.

deleted 17y ago

[deleted]

blasdel 17y ago

Variable typing is one of those topics that everyone sort of understands it, but is hard to put it into words. I’ve iterated and improved the next series of questions to really test a senior level candidate’s knowledge of static and dynamic typing. This is my best attempt so far. And a naive, inapt, incorrect, nomenclature-misusing attempt it is! Please read and re-read the nearly perfect "What To Know Before Debating Type Systems" before broaching this topic in any forum: http://www.pphsg.org/cdsmith/types.html http://www.pphsg.org/cdsmith/types.html

shin_lao 17y ago

I don't see a strong correlation between these questions and being a great programmer. Being a great programmer doesn't mean knowing the nomenclature. It is - in part - knowing which structure and algorithm is appropriate to solve a problem, and how to implement it efficiently with the given language.