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!