How a Java Guy Became a Ruby Developer

Once upon a time — OK, in 2012 — there was a startup and an engineer. They were both in the market, seeking their match. The startup needed a solid engineer for its Ruby on Rails application, and the engineer was a Java guy looking for his next great platform to build. Clear-headed observers would never have guessed that this mismatched pair would find themselves together, but they defied the odds and everyone’s better for it.

This is their tale.

Fork in the RoadHiring Troubles

The startup — which we’ll call WidgetCo — is a fun little company. Its website lets consumers compare investment offerings and decide where to put their money. It’s an impartial source of information for consumers and financial planners. The founder was an ex-financial planner himself who figured that if he had the need, others probably did, too. They had a prototype that a contractor had built, and with it got enough money and traction to start hiring a team.

At first, things went swimmingly. WidgetCo joined TechStars, and through its mentoring program found a great team leader with both startup and with Ruby on Rails experience. Within a few months, they’d found a good designer and a junior Ruby engineer.

The third engineer would be an important hire. This would be the engineer to tackle a lot of the front-end work, building connectors and interfaces with different applications. The more investors and customers WidgetCo talked to, the more interfaces they wanted to build. The challenge was that no one on the team could build them effectively. So, where to find that third engineer?

The hiring pipeline was dry. WidgetCo’s team had talked to everyone they knew and posted the opportunity on every job board they could think of. They’d gone to networking events and technical events. But no matter what they did, they simply couldn’t find another Ruby on Rails engineer who met their criteria. Those were:

  1. Be able to build interfaces.
  2. Know Ruby on Rails.
  3. Work for market rates.
  4. Be available.

WidgetCo’s style was not to wait and hope. They couldn’t afford it, for one thing. For another, there weren’t any signs that the situation would change any time soon. So what to do?

Rethinking the Hire

WidgetCo had three choices: Give up on the third engineer, go to a contract firm or somehow change its hiring criteria.

The hiring team quickly dismissed the idea of giving up. Mark and Jeff, the two engineers already in place, were great and working hard, but just weren’t making progress quickly enough. In addition, WidgetCo’s sales guy had a hot lead for a massive enterprise account, but getting the deal meant they’d have to quickly build about four interfaces, and neither Mark nor Jeff had experience with these particular kinds of system interfaces. To find someone who could do that work, and do it in front of a major client without embarrassing himself or WidgetCo, was a necessity.

So WidgetCo looked at local Ruby on Rails contract firms. Most didn’t have any availability. The ones that did charged pretty high rates: $7,000 per developer per week, a bit beyond WidgetCo’s budget. Still, if they got the big deal they might have to find a way to pay for contractors. In the meantime, they could keep looking for a full-time engineer.

That left the third option: changing their hiring criteria. This seemed to have the most possibilities. They’d been writing their job-board ads the way most companies do, tossing in everything they wanted in the hopes of finding the perfect engineer. Maybe some flexibility was in order.

Here’s the relevant part of the job description:

Required Skills:

  • Ruby on Rails experience, including Ruby 1.9 and Rails 3.2
  • expertise in building complex bi-directional data interfaces
  • proven success on applications with data volumes greater than 10,000 transactions per hour
  • data architecture design and development
  • experience with Redis, Cassandra, MongoDB, Hadoop, Elastic Map Reduce
  • mid-level developer skills in Sass and JQuery
  • understanding of object-oriented design

Preferred Skills:

  • effective working with our technology stack: Git, Pivotal Tracker, Rspec, Cucumber
  • background in security audits and data integrity analysis
  • cloud deployment familiarity (we use Amazon AWS extensively) using Puppet or Chef
  • Test-Driven Development (TDD) skills
  • complex SQL optimization skills

As job descriptions go, it was fairly short. However, it was quite heavy on certain technologies and skill sets. This isn’t your average Web engineer. It’s also not your average data engineer. While people with these skills exist, WidgetCo hadn’t found them. So it was time to examine what they truly wanted and why they wanted it.

Breaking Down the Requirements

WidgetCo went back and examined each requirement to understand the “requirement behind the requirement.” Why did they want each particular skill?

Required Skills:

  • Ruby on Rails experience, including Ruby 1.9 and Rails 3.2. Why? This is what our software is currently written in, and we don’t want to have someone come in and not be able to work on it.
  • expertise in building complex bi-directional data interfaces. Why? This is the skills gap on our current team, the “special sauce” that this person needs to bring. We know we have complex interfaces coming, and we know our current team doesn’t know how to build them correctly.
  • proven success on applications with data volumes greater than 10,000 transactions per hour. Why? We’re expecting our interfaces to be high volume, and we want someone who builds for that.
  • data architecture design and development. Why? Someone who is good at interfaces is logically going to be good at this, and it’s a good skill to have on the team.
  • experience with Redis, Cassandra, MongoDB, Hadoop, Elastic Map Reduce. Why? These are technologies that are used in large-data analysis, and we will be doing a lot of data analysis.
  • mid-level developer skills in Sass and JQuery. Why? We use these on the front end, and we want this person to be able to help out.
  • understanding of object-oriented design. Why? Functional programmers don’t belong here.

Preferred Skills:

  • effective working with our technology stack: Git, Pivotal Tracker, Rspec, Cucumber. Why? We use these.
  • background in security audits and data integrity analysis. Why? With the kind of customers we have, we’ll be getting some junk data and getting audited for security. This person shouldn’t panic in the face of that.
  • cloud deployment familiarity (we use Amazon AWS extensively) using Puppet or Chef. Why? We use these, and it’s good to have someone else on the team who does.
  • Test Driven Development (TDD) skills. Why? We think this is a good idea.
  • complex SQL optimization skills. Why? This goes along with the complex-data idea. To avoid performance issues, we’re going to need some fun queries.

It was an illuminating process for WidgetCo. They noticed that their requirements fit into three basic themes: Needed skills that no one on the team had, technology they used, and good practices. These suggest a very different breakdown between “required” and “optional.”

Required vs. Desired

The skills in bucket one — skills that no one on the team had and that were important to the business — were clearly required. The other two buckets were maybe a little less required. Skills that the company could teach, or that seemed like good ideas but didn’t directly apply to WidgetCo’s situation, fell into the “preferred” category.

However, that didn’t mean the company should look only for people who met the “required” list. After all, they didn’t want to hire someone who would flail around and screw up its product along the way. So it was looking for someone who met its revised requirements and also had some of its preferences.

Let’s look at the rewritten job description:

Required Skills:

  • expertise in building complex bi-directional data interfaces
  • proven success on applications with data volumes greater than 10,000 transactions per hour
  • data integrity analysis experience

Preferred Skills:

  • experience with our technology development stack: Ruby on Rails, Rspec, Cucumber, Sass, JQuery
  • experience with our development tools: Git, Pivotal Tracker, Puppet
  • experience with our deployment model: Amazon Web Services including EC2, Elastic Map Reduce, and RDS
  • experience with Big Data manipulation and storage technologies such as Redis, Cassandra, Hadoop, MongoDB
  • experience with Agile development practices, including TDD, feature branches, and pull requests.

Additional Comments:
We’re all in this together. We help each other with everything from system design to code reviews. We put the “us” in “team” and we’ll succeed together!

Well, that’s interesting. All of a sudden the technologies have lost prominence and the skills have gained prominence. Now WidgetCo was looking for a skilled engineer who could be trained in the specific technologies.

Did these changes work? Well, yes, but identifying the right candidate wasn’t easy. In my next post, we’ll look at how WidgetCo identified the finalist.


  1. BY RobS says:

    Wonderful change of direction. I think that most companies who “can’t find anyone” are making the same mistake. You simply don’t ask for someone who can drive a “horse-and-buggy” or “a souped up BMW” when what you need is a driver. Sure, you have those “tools”, but if skills transfer well from other tools, then you’ve boxed out those people with related skills.

    I look forward to the next post.
    I hope you’ll add a link to a post here so I don’t miss it.

  2. BY Daniel Walton says:

    I think you hit the nail on the head Catherine.

    Developers who are worth hiring can usually pick up new technologies pretty quickly.

    Hiring is much better off focusing on hiring talented engineers over engineers with specific experience.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>