Question submitted by Steven
We do all of our hiring at Automattic via Slack. Interviews happen there (text), discussion around the process, etc – all on Slack. That’s where we’ll be spending a lot of time communicating, so it’s important to figure out how well someone is going to handle that.
Beyond that, we also do a (paid) trial project with most roles, which is a time to get deep on assessing their skills, but also a chance for them to demonstrate that they can work in a relatively unstructured environment, continue to communicate effectively, ask appropriate questions, etc. During this time some people pull out when they don’t realize that working remotely is not for them, or we end their trial because it’s clear they’re not able to operate effectively in that environment. It’s time consuming, but critical to our hiring process.
At a previous company I worked at we did some paid trial projects, but it tended to exclude some people who didn’t have the availability or willingness to take time off from their job to do that project. It works best for younger people or consultants who work on their own. Have you had any issues with that?
We do ours part time, so people can work on them after hours, on weekend, etc. That definitely is still hard for some folks because of other responsibilities, but we haven’t found a way around it yet.
I’ve found that temporary work assignments and contract-to-hire are certainly better than asking for free work, but you have to be very careful to avoid certain pitfalls. The biggest I’ve found, especially if the trial is individually project-oriented, is that the success criteria for the project many not align with behaviors to be a successful employee. Projects tend to stimulate performance linked behaviors over social behaviors. They’ll often be evaluated on speed of delivery, functional fulfillment, and hopefully quality over collaboration, sustainability of pace, and iteration on outcomes. These are addressable to some extent with highly intentional design of the engagement parameters, although some things like outcome iteration are limited by the time bounds.
The other, largely unavoidable consequence of these kinds of arrangements is that they bias towards risk takers and those with economic security, which reinforces many of the inequities already in the system. There’s a significant cost of delay for the candidate from spinning a job search down and back up that the project compensation doesn’t cover. This could be partially mitigated with a funded severance if the trial doesn’t work out, but I’ve never seen that done.
Overall, I would say remote hiring requires better communication of expectations and the process and more preparation of the people, process, and tooling to do well.
Remote hiring tends to break the interviews into smaller chunks, which spreads them out, extends timelines, and increases scheduling overhead. It also allows for either side to pull the cord earlier without awkwardness, but that also raises the performance demands, as each session has an opportunity for recency bias and impulsive reaction. The extended interview timeline can also be out of phase with in-person interview that may be happening as part of the same job search as well as with other extended remote interviewing schedules.
The tooling, especially for collaborative interviewing approaches, is not nearly on par with in-person capabilities yet. Additionally, the infrastructure and tooling requirements, especially if they extend into expectations of what the employee funds themselves upon hiring, can reinforce industry hiring inequities.
Many of the challenges can be substantially mitigated with intentionality and preparation. The first step toward that is awareness.
For my current position I was given a complete at home assignment during the interview process which delved deep into C# class reflection. According to them, I was the only one who completed it successfully. I would note however that 7 months later, I’ve not once used reflection in my job, and the vast majority of my time involves building a React.js library.