I’m in the current position of hiring Senior Rails developers at my company, PrimeRevenue. Finding developers that fit the mold of “I’ve worked with Rails in the trenches”  is a lot different than someone who has deployed a blog on Rails. There is absolutely nothing wrong with the latter, but when trying to parse resume submissions it can be very difficult to find folks who are seasoned senior developers. I’m largely a self-taught Developer, imposter syndrome level 20. So I’m largely not concerned with your degree, education or pedigree. I’m concerned on your abilities, tenacity and focus on self-learning.

The above recalls an interview I heard with the Sandi Metz refer to experience of developers, which turns out to be attributed to: corgibytes.com.

“When I hear someone say they have 20 years of experience, I wonder if that’s really true or if they merely had 1 year of experience 20 times”.

I interpret the former as someone with a good breadth of knowledge who has licked their wounds and learned from it — all the while improving their knowledge and growing.

I’ve always hated interviews, especially contrived technical ones.

As a hiring manager, I find what matters to me is rolling up your sleeves and solving a somewhat real-world feeling problem in a relaxed environment (as possible). So that is what I’ve finally landed on. And it seems to be working well. My goal is to let you feel at ease and just work on some code. No tricks, no brain teasers. To get to this I have to filter candidates before they come in for the real fun.

The Derailed Interview Process

1. Screen resume online

I look for markers to decline the candidate, examples include:

  • A limited amount of demonstrable working time in Ruby.
  • Alphabet soup resumes where it is apparent they are trying to cast a wide net with Ruby/Rails as being a part of unrelated technologies.
  •  Only experience that is from a boot camp or school project.

I don’t immediately exclude candidates because of lack of personal online presence. If they have one, I will grade them on that, but lacking one doesn’t necessarily disqualify someone. We all have busy lives and sometimes you can’t devote 10 hours a week to being a consistent open-source contributor. This leads to an obvious question:

“What if I don’t have a lot of working Rails or Ruby experience? How can I ever get experience?”

This is the catch 22 of course. You don’t have much or any experience but need experience to get the job that needs experience. The simple and hard answer is, you have to do some moonlighting and work on some side-projects. Get some real experience on your own.

Create a website with some e-commerce for your kids’ school, make a blog engine for your church or contribute to a Gem or project online — anything that solves a real problem and allows for review online. If a picture is worth a 1000 words, your code is worth more.


Don’t know where to get started?

An example is https://www.codetriage.com/. You can pick an open source project and give a couple hours a week. Then reference this in your resume.


2. Technical Phone Screen

This is pretty straight-forward. At the risk of showing my hand to recruiters out there, it’s not a trade secret that much. This screen is focused on using something like http://collabedit.com/ where the interviewee and I look at some Rails code that has problems that need fixing or addressing. The problems are not too obtuse and a Senior dev with some years experience will catch them in a few minutes. I ask the interviewee to refactor and walk me through the code as they address issues.

Their level of expertise should reflect their answers and how quickly they are able to tackle the online code review. If they can’t address the code issues, even verbally, within about 30 minutes, I don’t view them as Senior.

If they pass the hands-on challenge, I then pivot into more open-ended questions focused on certain facets of Rails development. These facets were a result of some work with my coworkers and seem to work well.

  • Backend
  • Ruby/Rails
  • JavaScript
  • CSS
  • Debugging
  • Development Processes
  • Source Control
  • Databases

Going through this list only takes about 15-20 minutes and can give a good overview of where the candidate sits. Using similar questions for every interview ensures the process is more objective.

Candidates are graded on scale of 1-4, this scale was created by my old friend and work colleague Zack Adams.

  1. Noob
  2. Intermediate
  3. Advanced
  4. Expert

I won’t go into the exact ranking, but for each facet the candidate is ranked using the above.

If the candidate passes the hands-on code challenge and the facets questions fairly well, they move on.

3. Technical in-person coding exercise

This is where “Derailed” comes into play. “Derailed” is a public Rails 4 minimal app that is ready to go for hands-on interviews. It’s available here: Derailed

Derailed provides a quickstart method of candidates setting up their preferred development environment on a laptop ahead of time.  It’s a barebones working Rails application with all the basics:

  • one database model
  • a single JSON API endpoint
  • a dashboard page
  • a single passing request Rspec test
  • seeded database
  • and more.

The focus is hitting the ground running when the candidate comes in to interview. No setup, no friction. 

3.1 Next step, backend & frontend challenges.

After the candidate is connected to WiFi and has their computer up on the shared monitor we ask them to implement a straightforward backend feature. While it might be a little contrived, the feature feels real-world. I won’t share all the “challenges”, but here’s an example: “Implement feature in API to fetch random audio (using keyword in record).”

In a short amount of time, I/we are able to ascertain the interviewees’ capability. We add more complexity as the time passes and about at 1/2 point in scheduled time we’ll pivot from a backend feature to presentation. Using the above example, “Using random audio attribute, add button to play audio for each record”.

After about 1-2 hours, I feel we can safely gauge the interviewees’ skill in actually working with Rails and Ruby on a daily basis.

Conclusion

By focusing on semi-real-world problems both in phone screen and in-person with a quickstart application, we hit the ground running. Skip all the fluff and make the best use of everyone’s time. It’s important to cut the interview if there’s not a fit. There’s no sense in prolonging the inevitable.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s