RailsGigs! Canada! 🇨🇦

Howdy, Friends. A quick announcement that RailsGigs has expanded its Ruby on Rails jobs listings to Canada! RailsGigs now lists Remote, US-based, and Canada-based Ruby on Rails jobs.

We’ve slowly rolled this out over the past several weeks, and have now added a top-level page for Rails jobs in Canada as of today. You’ll also find a page that lists all Canadian localities that have open Ruby on Rails jobs as well as a bunch of city-specific pages.

The True North takes its place on our homepage with quick links to the most active metros!

If you’re a Canadian Rails shop and you’re not yet listed, reach out at posting@railsgigs.com, and we’ll happily set you up with a free job posting! Or just drop us a line with if you’ve got some feedback.

More international coverage is coming soon!

Live or Take-home Coding Assessments?

Last week in the RailsLink community‘s #work-offers Slack channel, a member ran a poll with this question:

“Do you prefer a live code assessment or a take-home assessment when interviewing for a developer position?”

I answered that I’m pretty firmly in the take-home camp. Here’s why.

Just to clarify, “take-home” is something the candidate completes alone, probably where they live. “Live” is done physically or virtually in an office, and here’s the important bit, with an interviewer watching the candidate.

I think take-home tests are at least an order of magnitude less stressful than a live coding exercise. And there’s recent research, “Does Stress Impact Technical Interview Performance?“, that supports this notion. (If you click through, you’ll see the paper thinks “live” tests are perfectly constructed to stress people out.)

A brief aside, to talk about my hiring process philosophy in general. I feel strongly about setting candidates up to succeed. That is, an interview process should be less about weeding out the people you don’t want to hire and more about surfacing the people you do want to hire.

You want to help people succeed for both practical (engineers are scarce) and noble (being a decent human) purposes.

Interviews are stressful! And coding interviews? Yikes! It’s one of the most stressful things I can remember ever doing. Asking people to perform well under these conditions sure feels like “weeding out.”

Generally, being a software engineer doesn’t require that one operate well under extreme stress. So unnecessary stress’s presence in the process is unwelcome! I don’t need to know if folks can code under duress–I just want to see if they can code!

So, I believe that folks answering a reasonable, relevant, and practical coding exercise at home is a lot less stressful. At home, you’ve got your own computer and dev environment. You’re probably in a workspace you enjoy and set up to your preference. You get to Google guilt-free. You can grab a snack or hit the bathroom if the need arises.

The more I’ve interviewed people (and been interviewed), the more I want to let candidates take the interview on their terms in the time and place of their choosing, if possible. (And with an open book, because all software developers work with an open book.)

Am I asserting that a take-home assessment is stress-free? Oh, Dear Reader, absolutely not! Still pretty stressful, I’d say!

Does this mean that there will be no further technical assessment in the course of a face-to-face or onsite interview? No. But it probably means there’s nothing that involves writing curly braces on a whiteboard.

We have all blanked at coding questions in interviews because it’s kind of intense. As a hiring manager, the idea that someone didn’t make it all the way through an interview process because it was too stressful just drives me crazy because finding good people is often my biggest challenge!

And, as a human, I feel bad that it makes people feel bad.

So, if you’re a hiring manager, minimize or drop your live coding tasks. Figure out how to turn them into take home tests.

If you’re a candidate, ask if you can do parts of the interview at home.

We’re at the end of this post, but I’m sure you’ve got a lot of questions. What is a fair assessment? How do you create one? Where in the process should it occur? Should you even have a coding assessment? All great questions that I look forward to addressing in the future!

Thanks for reading! You can find me on Twitter (@mjbellantoni) and LinkedIn. I’d love to hear your thoughts!

React is now effectively part of the Rails stack

In the most recent Stack Overflow Annual Developer Survey, (see my writeup here) React.js is the top-ranked web framework, with over 41% of respondents saying they use it. This fact got me thinking about how often I see React mentioned in Ruby on Rails job postings on RailsGigs–because I can tell you it’s a lot!

So I decided to take a look at the data. Let’s go!

In the past five or so months, RailsGigs has published 1,662 job posts. Of those, 841 of them mention “react.” That’s 50.6% of all job postings! I knew it was a lot, but I was pretty shocked that it was just more than half.

(If we only consider the job postings that are currently live, 50.0% of them mention React.)

Here’s some pie for you:

More than half of all job posting descriptions on RailsGigs mention React

I audited 25 of these job postings to understand the context in which the term “react” is used. 60% of the postings state straight up that the employer using React as part of their Rails stack. 52% of them ask for “experience,” while another 12% use it in the context of a “nice to have.” One posting even uses it in the context of “aptitude.”

So, while employers sometimes mention React in the context of “you should know some Javascript like React or Vue or something,” the anecdotal evidence is that React is actually in use at a whole lot of Ruby on Rails shops.

60% of employers state that React is part of their stack. Over 50% ask for some amount of experience while just over 10% list it as a “nice to have.”

To give you a sense of how often “react” is appearing alongside other Javascript or frontend-related words, here’s the frequency of some others:

What took me back in this data is that React appears more often than Javascript!

The other big surprise is that Ember has such a strong showing. In some sense, not a surprise as, at one point, Ember was kind of going to be “the Javascript Rails.” (And maybe it is?) I didn’t dig into the data to see if it was a requirement in job postings or not. That’s a project for another day.

Hotwire and Stimulus have a pretty weak showing. Is that a surprise or not? I do know that I’m expecting those numbers to grow steadily in the next 12 months.

When one looks at the data, it’s pretty dang hard to argue that React isn’t a de facto part of the “Rails” stack. It feels like this is a new topic for, uh, “healthy conversation” right alongside “Minitest vs. RSpec,” “fixtures vs. factories,” and so on. 

I would not be surprised to find that React adoption has peaked. And like I said: I would further predict that Stimulus and Hotwire gain a lot more adoption in the coming year. I look forward to a future or more HTML and CSS with more judicious use of Javascript, generally.

If you think this is interesting or have a question you think this data can answer, hit me up in the comments or reach out at @mjbellantoni. And if you’d like to post your job on RailsGigs, lemme know!

Stack Overflow’s Developer Survey and Ruby

Stack Overflow has just released its annual Developer Survey for 2021. Since it contains some numbers relating to Ruby, and graphing software and blogging software exist, I figured I’d graph those numbers and blog about them.

I was able to find the data back to 2013 quickly. Where available, I took the numbers reported for professional developers and not the entire population of respondents since that’s of most interest to me.

I think we need to approach this data as pretty coarse-grained. That is, the number of survey respondents varies pretty significantly from year to year. So, we can rely upon it for only the broadest of trends.

So, without much further ado, here are the charts. First, here’s the trend in percentage of survey respondents who are using Ruby.

Graph showing the Percentage of Stack Overflow Developer Survey Respondents Using Ruby
Percentage of Stack Overflow Developer Survey Respondents Using Ruby

First of all, I’m sure this number is lower than it was at Rails’ peak popularity, probably around 2010. (Google Trends says 2007.) While Ruby’s popularity may be trending down, I could also argue that it might be cyclical at this point? Anyway, as a lover of Ruby and Rails, I’d love to see this number rocketing up. But this feels kind of stable to me, and I’ll take it.

And here is Ruby’s ordinal rank among all of the “Programming, Scripting, and Markup Languages.”

a graph showing the Ordinal Rank of Ruby's Popularity in Stack Overflow's Developer Survey
Ordinal Rank of Ruby’s Popularity in Stack Overflow’s Developer Survey

This one is up and to the right, baby! Woo hoo! Oh, wait.

So, Ruby is decidedly out of the top ten and possibly destined to sink further? I do wonder if this is a product of Ruby’s declining popularity, or instead due to the appearance of many new languages on the scene in the past decade or so. It looks like it’s Go and Kotlin that have pulled ahead.

In conclusion, I’m a partisan here, and I’d love to see these numbers unequivocally more vital. But my roses interpretation is that these are the numbers of a healthy technology and community.

But I still feel pretty great about being in the Ruby world! Anecdotally, it feels like Ruby and Rails are on fire these days. There are several new Ruby implementations underway. Folks are doing some exciting work on other web frameworks. Shopify, GitHub, and Basecamp are all making significant contributions to Rails, making it ever more feature-rich.

On the employment side, Rails developers seem to be in demand as ever. When I curate job descriptions at RailsGigs, a bunch of them are looking for Rails and some other technology (e.g., Elixir.). Along with comments like this, it makes me wonder if folks who decamped from Ruby as their backend web development language are making their way back? Anyway, that’s something I’m hoping to unpack later and in more detail.

I’d love to hear your thoughts! You can find me on Twitter and LinkedIn. Thanks for reading!