This blog post goes into detail about how our company, Scholarly, hires software engineers. I’m writing this down for a few reasons:

  • We don’t have a company blog yet.
  • Our hiring process is relatively short (3.5 total hour total time committment)
  • Our hiring process is serial
  • We get a lot of positive feedback on the technical interview portion

For some context:

  • We’re a young company. We’ve been in business since June 2023 and we are now a team of 8.
  • We are a B2B SaaS company. You can read more about how we work and develop the product in the previous blog post, How We’re Working, 2024.
  • We have a tiny engineering team. We are 4 if you include me, the CTO.
  • We trying to centralize our engineering team in Seattle, or at least the Pacific Northwest.

What our hiring process is optimizing for:

  • Culture fit
  • Technical excellence in our tech stack (Rails)
  • Comfort with ambiguity
  • Not advancing folks further in the process than necessary.

We are comfortable with the following tradeoffs:

  • There is only one technical test, which likely results in false negatives. This means that folks might have an off day or otherwise be a great employee, but we just won’t get the chance to work together.
  • Our interview process can be a bit more elongated than a single-day, 8-hour gauntlet. It might take 1-2 weeks to go through the full loop, from first touch point to offer.
  • We have created a bit of an uneven playing field, that biases toward great or recent Rails engineers.
  • This process is very time intensive for myself, which we’re okay with. One of the lessons learned from Gusto’s leadership was to take hiring very seriously. It’s one of the most important things a young, growing company does.

The Process

Our interview loop consists of 4 sections, each section designed with a specific purpose in mind.

The 4 steps are:

  • The Screening Call (30 minutes)
  • The Technical Interview (2 hours)
  • A Chat with our CEO (30 minutes)
  • A “lunch” with our engineering team (30 minutes)

This process is serial, meaning if a candidate does not perform in one step they do not advance to the next one. We schedule using a series of Calendly links.

The organization here is to protect the time of those further on the chain. We view Maker Time as nigh sacred among ICs, and advancing only the most serious candidates is one way we protect that time.

The Screening Call (30 minutes)

The screening call is a chance for the candidate to get to know the company and vice versa. At the moment, I’m running all of the screening calls which can be a bit time consuming.

Here, we’re mostly going through a mechnical set of steps. Do you have the set of qualifications we’ve deemed important for this role? Are you in Seattle or willing to relocate? What’s your timeline? Any other curve balls? There will usually be a few questions about background to gauge a candidate’s mindset. Are they proud of their work and gracious in their failures? Do they frame success in terms of the team/company rather than themselves?

This session is meant to set up the process and to also act as a hedge against scam candidates. The hiring market is distorted at the moment due to a large volume of what can best be described as organized crime rings landing a job just long enough to dupe a company into paying a few paychecks before catching on. It’s wild out there, and it hurts otherwise honest candidates.1

The Technical Interview (2 hours)

This is the meat of our interview process. It’s where the rubber meets the road in terms of demonstrating technical aptitude. It’s got 3 sections:

  • The beginning. 5-10 minutes where the candidate gets a prompt via a gist and can ask questions. They
  • The middle. ~90 minutes of time to work solo, in the tools of their choice.
  • The end. ~20 minutes where I hop back on the call, the candidate screen shares, and walks me through their progress. Technical discussion ensues.

We want to most accurately create a day-in-the-life situation without artificial contraints like an in-browser code editor or deprivation of common tools. We encourage and expect candidates to use StackOverflow, ChatGPT, any othere things like that. You’ll likely be using those on the job.

The middle section is really testing how well and quickly you can write some basic Rails code, and how you translate ideas into code. We value speed of execution and are looking for a Walking Skeleton/Tracer Bullet/Steel Thread/Vertical Slice of the solution. Slow is smooth, and smooth is fast.

After I hop back on the call for the end, the candidate is measured on their ability to speak to their work. We don’t expect candidates to write tests, but we expect to have a good conversation around “If you were to test this, what types of tests would you write and why?” We’ll also ask questions like “If you were to spend another day on this problem, where would you invest and why?” ChatGPT and LLMs can do pretty well on many aspects of the authoring of code, but they cannot (yet) help with this section.

To pass, someone must be able to author working, idiomatic Rails code in the time provided and explain their work.

For many candidates, this format is particularly refreshing. They get to use their own tools, work in their own style, and then explain their work and then discuss their work with a peer.

A Chat with our CEO (30 minutes)

For candidates that pass the technical interview, they are advanced to a chat with our CEO, Rusty. Trust in the founders is a requirement for joining a company so young like ours, so we want to start that process during the hiring loop.

Rusty can dive deeper into the aspects of the business, our vision, things like sales and marketing, and so forth. Rusty also probes candidates on their motivations for joining Scholarly, some of their past learnings, and

Hopefully, both the candidate and Rusty come away from the conversation excited.

An Engineering “Lunch” (30 minutes)

  1. To give some flavor, a recent LinkedIn job posting of ours was turned off after getting 50 applicants in the first hour. 95% of them were either unqualified (no Rails experience in this particular case, a hard requirement) or showed signs of being a scam candidate (resume not matching their LinkedIn profile, etc.). ↩