These days, everybody is looking for candidates with Ruby programming experience.  But if you are a Recruiter or Sourcer who doesn't understand what Ruby is and the many different places it can be used, you might end up selling the wrong job to the wrong person.  You also may ask the wrong questions about the things that the candidate will be working on in their job.  As a recruiter, nothing is worse that not understanding the job you are recruiting for.  The days of "I am a great recruiter and I can recruit for anything even if I don't understand it" are long over.

Technology

Ruby is based off of Perl, Eiffel, and Lisp.  The Ruby programming language is a very versatile object oriented language that can be used for:

• Stand alone applications like those written in C, Java, C++, etc.
• Test automation frameworks like Perl Frameworks, Junit Frameworks, Python Frameworks, etc.
• Web application frameworks similar to PHP, ASP.NET, Java Server Pages, Python pages, Perl pages, Cold Fusion, etc.
• Shell commands similar to bash, korn shell, bourne, etc.

There are other uses besides these, but these are the most common ones that we see companies implementing.  Now inevitably when you talk about one technology topic, you end up talking about others.  So here is a more in-depth explanation of the list of things that Ruby can be used in:

• Stand alone applications are applications that get written, compiled, and executed by the user.  Easy-to-understand examples are ones like Microsoft Excel (written, packaged, and released to the end user), or Adobe Photoshop (written, packaged, and released to the end user), or the custom search engine application that Google uses for their site (written, packaged, and deployed on thousands and thousands of servers).
• Test automation frameworks are pieces of customized software that are used for QA/SW testing.  Just like a library, you can enter in your unit tests and then they can be called upon whenever those conditions are encountered in the software during testing.
• Web applications are the most common implementation of client-server interaction we have.  The application is processing information server-side and the results are integrated with a nice-and-neat webpage.  Think about any e-commerce, email, trading, cloud storage applications on the web.  The information changes based on the user and the user interaction.  The information is stored on a database and processed by a server-side application.  These web applications transfer their information to the user inside web page templates.  These templates can be written in PHP, ASP.NET, JSP, or Ruby.  They are integrated with HTML, CSS, and Javascript.
• Command languages or Shell scripts are usually languages used to command an operating system or environment.  In the case of IRB (Interactive Ruby Shell), the commands are an easy to use text interface to the ruby programming language.  The IRB commands allow you to run simple ruby programs and get results immediately.

Recruiting

So what do you do?  Well, you have to ask the right questions.

When qualifying your job that you recruit for, make sure that you know exactly what type of software this engineer is working on.  You will also qualify the candidates with a lot of the same questions.  The goal is to start broad and then keep refining until you are completely sure that you have the right person:

• What was the main goal or purpose of the software project that you worked on? (Trying to get an idea of the software project)
• What were the primary functions of the software?  What did this software do?
• Was this a stand-alone piece of software or was this a web-based application? (Even though this is probably stated in the engineer's profile, it's good to hear them talk about this and verify)
• Why did you (or the software architect) decide to go with Ruby as opposed to Java? (This will tell you about either the architectural mind of the engineer you are speaking to and/or the direction of the software architect or manager)
• What were the noticeable performance benefits you observed once this software was deployed? (You want to hear about the success and benefits of this software)
• How much of the coding was attributed to you?  Who else had partial responsibility for the creation of the software? (Very important because sometimes people "fluff up" their experience when they didn't do the actual work)
• How much of your time at the company was spent writing Ruby code?  How much of your time was spent on software configuration, packaging, deployment, or writing in other languages? (This is important because most hard-core Ruby developers are pretty passionate about spending most of their time coding in Ruby)

Remember that these questions (and similar ones you will create) are used to identify what the candidate has done, match to the main focus of the job description, and make sure that the candidate is not telling you what you want to hear.  As always, make sure the questions you ask elicit deeper responses and not yes/no answers.

- Mark Tortorici