• I'm an experienced developer and technical architect (C#, Delphi, Java, Clojure, Assembler, Perl, various esoteric functional programming languages)
  • We need to hire some Ruby developers for a growing Ruby on Rails project
  • I don't personally know much Ruby at all, but need to evaluate some candidates

What's the best way to fairly evaluate a developer who is hopefully skilled in a language you don't personally know well?

  • 2
    @Jeff O: That questions is about attracting interviewees when you are not getting many. That is very different from asking how to conduct an interview. Jul 28, 2011 at 12:12
  • 1
    @ChrisF - didn't think this was a duplicate because this is about lacking knowledge in the particular language/toolset that you are hiring for, not about overall developer experience (I'm probably going to be more experienced overall than any candidates, just not in Ruby)
    – mikera
    Jul 28, 2011 at 12:30
  • 1
    @Mikera - I would to break down what the project into main subject areas. I would then look up any Ruby on Rail terms for those subject areas. A developer who had knowlege of ROR would be able to answer those questions giving additional insight. A developer like yourself who did not have a great deal of knowlege with ROR would not be able on the spot at least to go into detail on those subject areas. You first need to know what does this person need to know, and how do you ask the right questions, to determine how much they know. You don't need to know ROR to do this.
    – Ramhound
    Jul 28, 2011 at 13:36

6 Answers 6


Ask questions that do not depend on a language. There are many core concepts to programing that carry over to whatever language you are using. Think of questions that are more theory than they are practical. Let one (or more) of your current Ruby programers be the interviewer that validates the interviewee's actual Ruby skills.

In addition, there are a number of good interview questions that you should be asking no matter what the position is. You need to decide if the person would be a good fit for the team. So you ask questions that get a feel for the person's personality and their work methodology. Having someone that meshes well with you team can be more important than having someone who is smart and knowledgeable about a language. It's much easier to teach technologies than it is work habits.


As long as you have one Ruby person in the team who can skill-check the candidate in that particular area, you're fine. You can always ask more general, high level questions about the candidate's past projects.

Even if the projects the person has done in the past were in a vertical you know nothing about with technologies you know nothing about, you can still ask about pain points, lessons learned, overcoming obstacles, dealing with the pre-release crunch, etc. etc. that will quickly uncover whether the candidate was a contributing member of the team or just someone along for the ride.

But you might want to spend half a day on Google to learn the basics of Ruby, especially if your RoR team is growing. Do it on a weekend if you're swamped during the day. YOU are the ultimate beneficiary of this extra effort.

  • +1. I was going to suggest the same thing, the poster has to learn some Ruby at some point. If having the wool pulled over your eyes at the interview stage is an issue then it will be at a later stage (during a code review or when a weird bug comes up and everyone is on holiday or ill) Jul 31, 2011 at 21:24

There are very few, if not zero, developers with Ruby as their only language. Almost everyone is at least conversational, if not fluent, in a C#/C++/Java type language, especially if they have a college degree.

Therefore, I would choose a language you have in common, state the idiomatic way to solve a common task in that language (like performing a simple database query and displaying the results), tell them you know very little about Ruby on Rails, and ask them to briefly teach you the idiomatic way to accomplish that task in Ruby.

If you both are experienced as you each claim, the candidate will be able to explain the differences in a way you can understand. After all, a significant part of his job description will likely be explaining issues to people who don't know the language, so it's a test of that communication ability as well.


I just had to do this the other day, interviewing for a .NET position where the candidate was familiar with Java. I focused on general object oriented programming principles, design patterns, and software development concepts, versus language-specific questions. I know enough Java to get me in trouble, so I did ask a few light Java questions to at least make sure he knew more than I did about it.

I was a bit worried going into the interview that we wouldn't be able to talk about anything, but it actually went quite smoothly. There is a lot of underpinnings to the software development craft that don't have anything to do with language syntax or platforms.


In order of descending priority, this is what I'd ask:

  1. Non-trivial commits to a popular project. You're in. Fill in your salary at the dotted line and sign here.
  2. Commits to lots of different projects. Sweet. What do they do?
  3. At least one private project. Alright, cool. What does it do? How many users/forks are we talking?
  4. Good references from a relevant job. So you got along with your boss. Can you show us some code? No? Are you aware that 50% of developers are below average, and that their (non-programmer) boss doesn't know the meaning of "technical debt?"
  5. Good Q&A profile. So you know how to write "DRY" on command. Where's the code?
  6. Good credentials*. What, you haven't used [language] yet? Alright, convince us you're a fast learner, and can take criticism. Do you have something cool in another language?

* Disclaimer: I do have a degree, but it took some time to figure out just how clueless I was. Did I say "was"?

  • 2
    Technically 50% of developers are below the median. Jul 28, 2011 at 14:35
  • Only if it's a countable scale. That is, if two developers can be at the exact same level. I don't know about you...
    – l0b0
    Jul 28, 2011 at 21:42

My opinion is good code is somewhat universal. Have him show you some things he's programmed, see how well they run, and then look at his code. Even if you're unfamiliar with the language, you can usually get an idea of what type of programmer he is by looking at his code.

More importantly though, actually have him write code in the interview. It can be something rather simple that only takes 20-30 minutes. If you're hiring someone for a job for years to come, he should be able to at least give you 30 minutes to assess if he can do the job. I'm amazed at how many people hire programmers without even testing if they can really program.

If they've got some impressive looking past projects with nice looking code, and if they can whip out a nice, simple little test program with well organized code, than you can get a pretty good feeling about their ability.

Not the answer you're looking for? Browse other questions tagged or ask your own question.