A Slicker Engineering Recruitment Process

One of the things I love most about working at Glean is my colleagues. They are some of the kindest, smartest people I’ve worked with and this is partly down to our interview process. We unashamedly maintain a high bar for technical ability when hiring, but this does mean that to fill a role we do end up processing a lot of applications.

We give people a technical challenge (about one to two hours whenever suits the candidate) as a simple filter to help us decide whether to invite a candidate to interview. We used to send out a PDF and ask them to submit their solution in whatever format they felt was appropriate. It was manual and clunky, not ideal, but it did the job.

Last year we decided to hire an additional squad, a significant ramp-up in recruitment which exacerbated this pain point - our process didn’t scale well. So along with some general sprucing up (reducing live coding, replacing toy puzzles with a single more domain-relevant problem, shortening the technical interview) I had a go at making things slicker on our side too, and hopefully making a better first impression.

I tried to imagine what experience I’d want as a candidate. I thought instead of an email with the task attached, perhaps we could invite the candidate to a GitHub repository. Then we could ask them to submit a solution by creating a new branch and opening a Pull Request.

But if we had a single dedicated repository for this, as contributors they’d be able to see other people’s PRs. I thought perhaps we could script something using the GitHub CLI to create a new repo for each client, but after a bit of digging it turned out GitHub had beaten us to it with Template Repositories. These make it easy to create a totally independent copy of a repository, consisting of a single initial commit (the ultimate squash!).

To keep some healthy separation between candidates and our company code, I created a separate GitHub organisation, dedicated to recruitment. It worked pretty well - we could easily invite someone as a collaborator, and they could open a PR and let us know that they were done.

Once we had proven the candidate side could work, I wondered if I could make it any more convenient for us. GitHub Actions are relatively young, but have matured in leaps and bounds over the last couple of years. They live within a repo and you can set up access to credentials if required. They even come with access to a GitHub token out of the box (default permissions here). We would need a more powerful token than the default to create repos though.

I set up a new repo for our GitHub Actions, and created an Action that creates a new repository. We give it a name, role and GitHub username (the repo name combines the name and role). It takes care of creating the repository and inviting the candidate as a collaborator. Neat!

Actions are not perfect and human error happens. Sometimes we get a GitHub username wrong, and sometimes inviting the candidate as a collaborator fails for other mysterious reasons. I set up a Slack Webhook to notify us of the success/failure when we run the Action, so we didn’t need to sit there waiting to be sure of success. The Slack Webhook gave us a direct link to the repo as well, so it was easy for others to review the submission.

We started eyeballing the repositories list for PRs (it’s pretty convenient, all on one page), but eventually even that was too much like hard work. The ever-excellent Charlie whipped something up on Zapier to spot new PRs and post that to a separate slack channel, dedicated to reviewing candidate solutions.

So what’s our next pain point? Well, we need to manually go to the GitHub actions page and copy over the user’s GitHub account and name. Wouldn’t it be great to trigger the GitHub Action that creates the candidate repo from our recruitment platform, Greenhouse? I haven’t looked into it yet, but it would take another little bit of time and effort out of the process.

It’s also a manual job to clear up old repositories at the moment - ideally we’d delete them automatically after a candidate leaves our recruitment pipeline, so maybe that could be triggered from within Greenhouse as well? We’ll see!

Conclusion

Our basic, ramshackle process worked fine for a few years, but it didn’t scale too well as we have grown. We’ve worked on improving this process incrementally, focusing on our pain points.

This is how we usually aim to treat our processes in general at Glean: reflect and iterate, making small improvements to get rid of the key pain points. Our retrospectives every eight to ten weeks give each squad space to identify their pain points and come up with experiments, and our weekly Entmoot is an opportunity to raise more pressing issues or make suggestions for changes we’d like to try out (or process we’d like to get rid of!).

Overall it helps us to stay process-light and minimise interruptions, keeping us engaged, motivated and productive.