Now that Ruby’s begun its march towards global domination, it’s appearing on increasing numbers of resumes. That puts most tech companies (including yours, I’d venture to guess) in a weird position, because they don’t know how to evaluate Ruby programmers. Not yet, anyway.

We’ve been here before, haven’t we? Remember back when CGI appeared on the scene, followed almost instantly by CGI.pm, and suddenly every company wanted people who knew Perl? Same thing with C++, Java, C#… a good litmus test for programming-language popularity is whether people bother putting it on their resumes. And for a while after a new one shows up, nobody can tell the wizards from the poseurs.

This is a key juncture for Ruby. If companies start hiring people with “Ruby” smeared all over their resumes, and those people go on to produce brilliant software and generally kick ass, then Ruby gets modded way up. If said Rubyists turn out to be (on average) a bunch of do-nothing kneebiters, Ruby loses big. Rubyists are out there right now, getting set up on blind dates with tech companies, and these first impressions don’t just matter for them; they matter for all of us.

What’s the worst-case scenario? Well, I used to have this friend who worked at a tech company we’ll call “FooCorp”. This is a true story: at FooCorp, the HR department decided to hire a lone cowboy programmer to write a new performance-evaluation tool for the company. The programmer they hired — who had no interaction with the rest of engineering — went ahead and decided to write it in Ruby. With much ado and fanfare, they rolled it out, and with even more ado, a thousand people spent hours entering in their performance reviews. And then, with a truly enormous amount of ado — I mean enough ado to fill several football stadiums — the shiny new Ruby-based perf tool went on a rampage and ate up everyone’s performance reviews. Forever.

Was that Ruby’s fault? Of course not. In fact I, er, that is, my friend met with the cowboy afterwards to figure out whether the disaster could be undone, and the cowboy announced: “WELL, YOU KNOW, WHEN THE SYSTEM GETS ENUFF CHAOS GOIN’ IN THERE, PRETTY MUCH ANYTHING COULD GO WRONG.” And I can’t say he was wrong, either.

Needless to say, Ruby got a bad rap at FooCorp for a little while.

I’d like the Ruby community to start thinking proactively about this problem. I don’t think I’ll come even close to solving it in this blog. Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I’ll just say it: it’s easier to learn than Python. And that’s quite a feat. It means Ruby’s inevitably going to become a magnet for people who can’t program any other way. Tech companies need our help here. Let’s figure out some ways to differentiate the good eggs from the bad ones.

I’ll offer a few of my own ideas here, but obviously I can only barely scratch the surface in a single blog. I’ll start with some approaches that should work regardless of the language you’re testing for, and then talk about some Ruby-specific tests.

The Statistical Approach

Your first shot at evaluating a Rubyist comes at resume-screening time. Come to think of it, that’s true of any candidate. You can eliminate a large class of probably-weak programmers by looking for patterns and antipatterns in their resumes.

Let’s say you’re trying to hire a Java programmer. Well, you’ve already made your first mistake! Why? Because setting out to hire an “X programmer” for any value of X is probably going to land you a dud. I will assert: all the best programmers are proficient with at least three to five programming languages, and the Really Best ones pretty much hate all languages, but they hate some less than others. Anyone who proudly proclaims they’re a “Java Programmer” is pretty much a puppy. They may be smart, but you’ll have a lot of paper-training ahead of you.

So there’s your first Warning Sign: if the resume says “I AM A RUBY PROGRAMMER”, toss that sucker right in the Round File. Unless their name happens to be “Yukihiro”, “Dave”, or “Why”, in which case you might want to take another peek at it, just to be safe.

OK, while I maintain that you don’t want to hire people who know only one language, we can still use the Java example. Let’s say you need to hire someone who will likely be contributing to an existing Java code base, and you’re looking at the resume of a candidate who claims to know Java. How can you tell how good they are at Java, just based on the resume?

Don’t forget Dave Barry’s advice: “A resume is more than just a piece of paper. It’s a piece of paper with lies written all over it. A good resume can mean the difference between not getting the job and not even coming close.” You need to read between the lines when you’re looking at someone’s resume.

As we all know, this is how to correctly interpret occurrences of the word “Java” (and related terms) on a resume:

Resume Pattern Interpretation
“Java” appears exactly once on the resume, towards the end of the “languages I know” section. Doesn’t know Java.
Java 5, Eclipse/IntelliJ, Ant, log4j, JavaCC, ANTLR Probably knows Java pretty well.
Implemented a JVM, a Java compiler, a world-famous Java app or class library, or a new JVM language. Almost certainly an exceptional Java programmer.
Has used Java for everything they’ve ever done, starting in Grade School. Probably doesn’t know Java very well.
“J2EE” or “EJB” appears more than once in the resume. Doesn’t know Java.
Utilized my strong communication skills enabling me to be a key team player on a major project involving Java. Round File.

What lessons can we generalize from this Highly Accurate Summary? Well:

  • Knowing Java well involves knowing a lot more than just Java.
  • Working on Java teaches you more about Java than working in it.
  • Huge “enterprise” frameworks cause brain rot.

As you might expect, this generalizes to other languages, including Ruby.

Today we’re at the stage where most resumes may only mention Ruby once, or maybe twice if you count Ruby on Rails. But we’ve already reached the point where if that’s all you see, you can probably discount Ruby from the resume entirely. If you’re looking for someone who’s actually good at Ruby (and even better, programming in general), their resume should talk about what they did with Ruby.

What are today’s Ruby buzzwords? What are the equivalents for Spring and Hibernate and Jaxen and those hundreds of other Java-related Buzznologies? I’m not sure, actually. Ruby seems far less framework-prone (which you should read roughly the way you’d read “accident-prone”) than Java. The best packages (e.g. REXML) eventually seem to get absorbed into the main Ruby (or Rails) distribution. For some domains, e.g. parser generators or IDEs, nothing has yet emerged as the dominant player. So there aren’t that many reliable buzzwords for Ruby, not yet.

I suppose for purposes of resume screening, you just need to look at what they’ve built with Ruby. If looks like an impressive achievement in any language, then it probably is.

Using Rails to build a web application is not an impressive feat, because Rails makes traditional web development essentially trivial. [Hint: that’s why it’s so cool.] So you can safely ignore “I used Rails to build a website” on resumes. On the other hand, if the person is the maintainer for a Rails extension that’s being used by dozens of site owners, and is currently being considered for inclusion in the core Rails distribution, that’s an entirely different matter.

Even though we’re still fairly early in Ruby’s rise to fame and fortune, you can already start to use pseudo-statistical approaches (i.e., buzzword counting and clustering) to weed out the lame Ruby programmers during resume screening.

And don’t forget that other, non-Ruby indicators still matter just as much as they ever did. A good education, good work experience, and a healthy amount of extracurricular programming work are all positive signs on resumes.

Phone Screen Questions

Once the candidate has passed your B.S. test, and has made it to the phone screen, what’s the best way to reduce them to tears over the phone?

Ha, ha! Just kidding. You don’t really want your candidates to cry. If the candidate leaves the interview hating your tech company because you were mean, you’ll have made an enemy for life. Just ask Microsoft. It wasn’t until the mid-1990s that they figured this out and started trying to be nice to people during the interviews. Everyone who interviewed there and didn’t get an offer has pretty much dedicated their life (and through peer pressure, their friends’ lives) to fighting Bill. I’m sure that’s at least partly how the open-source movement got so big.

Anyway, the phone screen is a great opportunity to test someone’s Ruby skills. It helps to know some Ruby yourself, though. If you don’t, there’s a pretty good chance they’ll be able to bluff you.

Here’s a sample of some of the questions you might consider asking a professed Rubyist over the phone:

Compare and contrast Ruby with your second-favorite language.

[Note: Ruby must be their favorite language, or they obviously don’t know it very well. But just in case, a few acceptable runner-up favorites are Scheme, Lisp, Haskell, OCaml, Python, Io, and Lua.]

Good candidates should be able to drone on endlessly about this comparison, and you should have to try several times before you can get them to shut up about it.

Describe any two features you’d remove from Ruby to improve it, and explain what changes would be required in the lexical analyzer, bison parser, and interpreter in order to effect these changes.

There are all sorts of good answers to this question. “Ruby is perfect, and any change would necessarily diminish it!” gets points for loyalty, but is unfortunately an incorrect answer. And don’t let them get away with asking if they can remove the absence of a feature, such as tail-call optimization.

Describe in detail the name-resolution chain for constants (i.e., if you reference a Constant in your function, where does the interpreter look for the definition of that constant?)

Major bonus points if they can tell you how it’s changed in Ruby 1.9, and why.

If you were to write a Ruby Style Guide for your company, what are some of the things you’d put in it? Would you include a maximum line length? If so, how long would it be?

Good candidates will have lots of thoughtful insights about this, and will hopefully arrive at the conclusion that they’d look at existing style guidelines and source code before committing to anything permanent.

Can you think of any possible justification for the Ruby on Rails core source code using a line-wrap width of 500 characters, or whatever the hell it is?

Good candidates will be really peeved about this. (What’s up with that, DHH? Do you have a 150-inch monitor or something? Jeez.)

Pick any five C++ or Java “design patterns” and explain how to accomplish the same effect in a tiny amount of Ruby code.

(Can you tell I’m a harsh phone-screener?)

Bottom line: Ruby is an incredibly thoughtful language, and great Ruby programmers can’t help but think deeply about it. The phone screen is a great time to probe candidates on how much they’ve thought about Ruby’s internal mechanics, and how its semantics and implementation differ from those of other languages.

General Interview Questions

OK, your Rubyist Candidate has made it past the resume screen and one or two phone screens. It’s time to put them to the Big Test. Are they up to the challenge?

More importantly, are YOU up to the challenge? How the heck do you tell a good Rubyist from a bad one? There you are, right there in the interview, and it seems like they’re solving everything you ask them with a single line of Ruby code.

Well, I’ll be honest with you. If you don’t know Ruby very well, this is NOT the time to have them write Ruby code. If you don’t have any programming languages in common (which should worry you), ask them to write in pseudocode.

It’s still quite possible to evaluate them if you don’t know Ruby. If you’re a tech company trying to hire someone, and that someone really loves Ruby and has it plastered all over their resume, you can still do a great job of evaluating them by asking them more or less standard interview questions.

In case you didn’t know this, about 1/3 of all technical interview questions worldwide are variants of “How do you fit 10 pounds of crap in a five-pound bag?” Examples: how do you reverse a string in place, how do you sort a billion numbers, how do you write a decent compiler backend for an architecture with only four frigging registers, how do you handle fair scheduling when someone just forked off 1000 copies of some Towers of Hanoi simulation, etc. Another 1/3 are variations on “How do you find a needle in a haystack the size of Mount Everest?” Examples: how do you search a chess game tree for a good move in less than the lifetime of the universe, how do you find which IMDB picture you most resemble, what are the odds you’ll have a heart attack if it turns out to be Marty Feldman, etc.

It’s not too hard to think of interview questions that probe a person’s problem-solving and algorithm-design abilities without relying too heavily on the specific language(s) they’re most familiar with. So don’t sweat it if you can’t test them directly on Ruby. (And don’t ask any of the example questions I just mentioned. They’re all terrible, terrible questions.)

Incidentally, many of the remaining technical interview questions appear to be random trivia questions about language syntax for some mind-numbingly complicated language like C++ or Perl. The worse a language’s syntax is, the more likely it is that practitioners of the language will interview for its syntax. Please, please don’t let your company sink to that level. Language syntax trivia doth NOT a goode programmer maketh. And if you ask that kind of thing already, please, please don’t start with Ruby, too. Hiring based on syntax trivia is the last, desperate resort of a weak interviewer. Just say No.

Ruby Interview Questions

What if you DO know Ruby, and you want to test the candidate on whether they know it, too?

Well, now we have a minor problem, because this is a Ruby blog, and any actual questions I mention here are likely to be studied meticulously by job-hunting Rubyists. I actually had an interview candidate 2 weeks ago tell me they’d read my blog, after I asked a question from one of my old blog entries. Word gets around!

You can always fortune-cookie it. You know how Fortune Cookies always sound better if you add “in bed” to the end of the fortune? Well, you can always impress a candidate by adding “in Ruby” to the end of your question. For instance:

  • Reverse a string in place, in Ruby. [str.reverse! — see? told you it was a bad question.]
  • Write a function that appends (if not present) the words “in Ruby” to any English sentence, in Ruby.
  • Write a function to print out Pascal’s Triangle to a depth of N, in Ruby.
  • Write a Python quine, in Ruby.

OK, well, maybe not every question works better with “in Ruby” appended.

Seriously, though, here are some of the things I’d look for, if I were really trying to evaluate someone’s Ruby knowledge.

First, I’d make sure to cover metaprogramming, because it’s pretty damned important. One of the things I love about Ruby is that it embraces metaprogramming; in contrast, many other languages with metaprogramming support whine a lot about it being “potentially confusing”, and even go so far as to disallow it in company style guides. Hire only the best and brightest, then make them write strictly in for-loops: standard policy for 90% of the tech companies I’ve dealt with.

So I’d cover metaprogramming, probably before anything else, to ensure we talk about it before running out of time. I might ask the candidate how to build a compatibility bridge between an old legacy interface and a new one. Or how to create a class with methods for handling every {HTML|CSS|Starbucks|whatever} keyword in some lexicon without having to write identical-looking methods for every keyword. Any question whose answer involves writing code that writes code.

I’d also ask about the metaclass model, and mixins, and superclasses, and how method lookups traverse that potentially complicated tree. And I’d want to know a little about the flavors of eval in Ruby, and why you’d need them. And how you’d fake any one of them, given only the others. These are examples Ruby-specific problem domains that will set experienced Rubyists apart from the masses of unwashed Rails converts.

In practice, while I’m rather strict about concepts, I tend to be pretty forgiving on details, at least relative to other interviewers I’ve compared notes with. For instance, I’d expect someone to know the capabilities of Ruby’s regular expressions, and when you’d want to use them, but I wouldn’t ask them anything beyond the basic set of posix-ish regexp metacharacters (if that). And I’d expect a candidate to know about method_missing, but I’d probably let them slide on the exact signature or arity. (That one’s not too hard, but you get my point, I hope.)

Ruby’s Limitations

The very best Ruby programmers, as with any language, are the ones who can think outside Ruby; i.e., they know its limitations as well as its strengths. It’s extremely uncommon for average programmers or language novices to be able to speak intelligently about their favorite language’s weaknesses, because the language books and tutorials rarely focus on the weaknesses. Bad for marketing, and all that.

You can usually only find out about a language’s weaknesses by seeing those things handled better in another language. So if I’m interviewing a Java programmer, I might ask how to return multiple values from a function efficiently. There aren’t any terribly good ways to do that in Java. If I’m interviewing a C++ programmer, I’ll ask about situations that call for runtime reflection, e.g. loading a class by (string) name on the fly, or getting a list of the methods on a class.

Better yet, I might simply ask them to come up with a list of deficiencies in the language, without any hints, and see what they come up with.

I think Ruby’s rich enough that you’ll be able to tell a LOT about a given candidate from their answer to this question. Will they bemoan the lack of tail-call optimization, citing its ill effect on patterns using recursion or call/cc? (Hired!) Will they complain that it doesn’t have static types like Java or C++? (Red flag!) Will they whine about its performance? (Probably not hired!) Will they go on about how they really miss IntelliJ, and hate having to use Emacs for all their Ruby coding? (Definitely not hired!) (Note, added 13 hours later: I’m just kidding! You’re all frigging hired! Stop mailing me about this! Jeez!)

The thing is, every language has its share of design problems. The “tell me the language’s weaknesses” question is an opportunity for a candidate to show you how well they understand the art of language design, which in turn is an exceptional indicator of how they think about software design in general.

But hey, interviewing is a weird process. Everyone does it differently; everyone has their own style, and I’ve found that reasonably experienced interviewers generally think they’ve got it down to a science, and are unwilling to change their style very much. And frankly, I don’t think it matters, because the traditional 1-hour interviews conducted throughout our industry are a pretty random way to figure out how well someone is going to work out in the months and years ahead. I don’t think anyone’s style is good enough to avoid all false positives and false negatives.

So take all my interviewing suggestions here with ten pounds of salt. Preferably in a five-pound bag.

Calling All Jobless Rubyists

Ruby’s at a tipping point. You can see it in the resumes. Go to Monster.com, or your favorite source of online resumes, and you’ll see a LOT more mentions of Ruby today than there were a year ago.

I’d love to say: “If you’re dumb, please don’t mention Ruby on your resume.” But of course I’d never say anything as mean as that. I might think it, but it’d never make it into my blog.

Instead, I’ll offer this small bit of advice to job-seeking Ruby fans: don’t push it too hard. Ruby’s a wonderful tool, and it makes you feel very powerful. But most tech companies these days are still just getting their feet wet with Ruby. They’re trying to figure out whether it should be allowed, and if so, how it should be used, and how much it can be trusted. Companies are generally slow-moving entities, even when they’re composed entirely of fast-moving, smart people. It’s just how things work. And it’s never more true than when they’re considering whether to introduce a new language.

If you know Ruby, then be sure to mention it on your resume. But your motto should be to under-promise and over-deliver: don’t overstate how good you are with it on the resume, or it will backfire in one of two ways. Either companies will conclude that you’re too dependent on it (and not interview you at all), or they’ll interview with overly high expectations, and you could come up short.

Calling All Companies

If you’re a company (admit it! you are!), then you know by now that Ruby’s rudely shouldering its way into the public consciousness. Very soon now, whether you like it or not, you’re going to have to “deal” with the issue. At some point, Ruby’s going to be mentioned on 50% or more of the tech resumes out there, and Ruby has this odd way of inspiring drooling fanaticism in people who use it. That’s because it’s actually a pretty darn good language, which translates to “getting your projects done faster, with fewer people, and lower maintenance burdens”. All in all, a good thing.

So at some point, very soon, if it hasn’t been happening in secret already, Ruby’s going to rudely try to shoulder its way into your code base. Your best bet is to start thinking about it now, so you’ll be prepared. If nothing else, you’ll at least want to have a plan for sorting out the good Ruby programmers from the bad ones at interview time. Maybe it’s time to walk around the hallways and ask who’s up for doing Ruby interviews, and see what Ruby talent you’ve already got in-house. I think you might be surprised.

And if you’re a programmer, and you’ve made it all the way to the end of this blog, and you don’t know Ruby yet — what the heck are you waiting for! Go spend half a day and learn it! Off with you! Shoo!

5:00am. Time for sleep. If you hated this blog entry, please make sure to mention it in the comments section, and hope you don’t get me for your next phone screen. Ciao.