Hiring at Loophole
We've worked really, really hard over the past few months to design a hiring process that we're proud of! Of course, we expect the process to evolve over time, but for now, we want to share some thoughts about the way we've set things up, why we've done it this way, and also I'll probably rant about the broken state of the tech industry interviews. Let's goooooo!
Note: Our process is designed specifically for interviewing software engineering candidates since that's all we're hiring for at the moment. We're hoping to reuse most of what we've built when we come to hiring others, but we absolutely expect to revamp huge chunks of it to better assess candidates with different skillsets.
Our Design Principles
To build a great hiring process, we believe it's necessary to know what matters most. For us, we discovered that our most core value is that we care a lot_ about making the process as frictionless as possible for candidates. While iterating on our process, we developed the following principles which have helped guide us towards the process we have today.
Principle 1 - Transparency Is an Absolute Requirement
We've tried to make our interview process as transparent as possible. For example, some companies provide vague timelines around when you'll hear from them, but most leave candidates in limbo, wondering if they should send a follow-up email. We find that to be completely unacceptable, so we have strict SLAs on responses and we communicate those timelines to candidates. Here are a few other examples:
We publish salary ranges (including equity) in every job description. We don't want anybody to waste their time applying if we can't meet their financial needs.
Candidates receive an agenda beforehand with every question we'll ask during the interview. It's an opportunity for us (meaning both the company and the candidate) to decide if we want to work together. It's not a pop quiz.
We will always let candidates know whether or not we're moving forward as soon as we can. A candidate should never have to wonder whether we're taking our time to decide or if we've already moved on.
Principle 2 - The Candidate's Time Is Valuable
Our time as interviewers is also valuable, obviously, but the candidates aren't being paid for the time they spend on our process. We recognize this, so we try to ensure that we're as efficient as we can be with their time, while also requiring very little extraneous work from the candidate. To this end we have...
...eliminated cover letters. We don't want 'em. Send us a resume (or LinkedIn, or Github, or website... we're not picky), and let's get that screening call scheduled.
...set temporal boundaries on our interviews. Each section of the interview is designed to fit within a specific amount of time. We're flexible — some sections take more or less time depending on the candidate — but we have an absolute time limit on the interview process. If we haven't asked all of our questions before we get to the time limit, no worries. We prioritize our questions to get to the most important ones first, and we will never hold a candidate longer than the scheduled time limit (currently 1.5 hours).
...automated scheduling (mostly). We use automation tools that allow candidates to schedule their interviews without requiring a bunch of back–and–forth over email. As long as there's time on the appropriate calendars, scheduling should be as quick as the candidate can make it.
One more thing that we do: schedule our post-interview meetings as soon as we can. Often we'll have them immediately after an interview. Our guarantee is that no candidate will have to wait more than 5 business days for a response, and sometimes we can make same-day offers!
Principle 3 - Assume Competency
Tech interviews are all over the board, but there's one portion that's basically standard across the industry: programming challenges. They come in many forms:
Take-home projects
Shoulder surfing disguised as pair programming
Whiteboarding questions
Additionally, the adjudication of these challenges is inconsistent. Very few companies have a legitimate, non-biased scoring system for their challenges. Most have no heuristics at all, instead relying on subjective opinions from the interview team. These challenges almost always fail to represent a candidate's capability. They're not representative of what candidates do on a day-to-day basis, and they introduce a significant amount of stress and anxiety for most candidates.
Instead of leveraging this terrible, archaic, flawed methodology, we decided to take a different approach. Rather than requiring candidates to perform a circus act for us we just... assume they know what they're talking about. 😱
I know, I know... It's a wild concept, right? The idea that people applying to engineering roles actually understand engineering? We subscribe to the idea that we should trust the people applying to have the expertise they claim to have.
On a more serious note, the benefits of this have been substantial. We do still ask candidates to submit an open-source project that they've worked on (there's an alternative option, too), but the goal isn't for us to adjudicate their technical chops. I'll discuss that more in a bit.
The Actual Process
I'd be lying if I said it hasn't been hard to escape from the trappings of the "standard" interview process. With these principles in place, however, we've been able to design a process that we think allows us to make smart hires without forcing the candidate to make sacrifices.
Screening
We have a standardized screening process that candidates undergo. It's a brief call with some basic questions. A lot of it is just getting the basics out of the way:
Preferred name
Pronouns
Best contact method
What should we use for work history review (resume, LinkedIn)
An open-source project that the candidate is excited to talk about[1]
Once we have that taken care of, we'll ask some questions to get to know the candidate better. This is a candidate's opportunity to get an advocate in the room. The interviewer doing the screening call is looking for information about the candidate's background, knowledge, and expertise. The interviewer will then carry this info over to the next step of the process so they can advocate for the candidate prior to the interview.
If the screening confirms that the candidate covers the basic needs of the role they're applying for, we'll send candidates an invitation to schedule an interview. On the other hand, we'll let candidates know if we decide not to move forward at this point. The last thing we want to do is leave somebody hanging.
Pre-Interview Sync
We schedule this internal meeting at least 2 days before the interview. We'll use the time to assess what knowledge gaps we have around the candidate. The screening interviewer will take the info they learned during the screening call and use it to fill in some of these gaps. We'll try to fill other gaps by reviewing the candidate's work history, website, open-source work, etc.
The goal here is to generate a set of questions that are specific to the candidate. Some of our standard interview questions will even be skipped if we feel we have enough positive signals to answer them ahead of the interview!
Once the meeting is over, we compile our questions into an agenda, export it to a PDF, and send it to the candidate at least 24 hours before their interview. We expose every question that we intend to ask beforehand because it gives the candidate time to think about the questions. It makes it easy for candidates to bring their full selves to the interview, knowing exactly what we're going to be discussing. It also eliminates a level of stress and anxiety for most candidates because they don't have to guess what they'll be asked during an interview; it's all right there on the agenda. ❤️
Interview
The actual interview is broken into 4 sections: Overview, Technical Discussion, Team Q&A, and CEO Q&A.
Overview
Expected time limit: 15 minutes
This first part of the interview is super basic. Both the candidate and the interviewers will introduce themselves, then we'll recap the role the candidate is interviewing for. We'll also do a brief recap of the sections of the interview before we dive in.
Discussion
Expected time limit: 30 minutes
We'll ask questions about the submitted OSS project after the screening call. Rather than digging into technical acuity (which can be trained), we're trying to better understand the candidate's ability to communicate about technical topics. Some example questions:
Why build 𝑥 instead of using library 𝑦?
What was the biggest technical hurdle?
How was the breakdown and prioritization of work managed?
The goal is to make sure that the candidate can break technical topics down in such a way that they can communicate them to us, and we can actually understand what they're conveying.
Team Q&A
Expected time limit: 15 minutes
During this time, the CEO will leave the call so the candidate feels free to ask questions of the rest of the team. Candidates are encouraged to ask difficult questions, such as, "What's it like to work for the CEO," or, "How do you feel about the stability of the org?" Lending back to Principle 2, transparency is key. We want people to work for us, but we don't want them to show up and find that we can't meet their needs as a workplace.
CEO Q&A
Expected time limit: 15 minutes
The final leg of the interview has the CEO return to the call while the rest of the team heads off. Candidates can certainly ask the same questions of the CEO that they asked of the team, but they're encouraged to dive further into things like...
What specific projects would I be working on in this role?
How solid is the company's funding?
What's the company's growth plan over the next year?
On the flip side, our CEO will also take this opportunity to better understand candidates' goals and needs, and assess whether or not our company can fulfill them. Again, we want to be able to set clear expectations, and we don't want somebody to accept an offer only to feel like the rug was pulled from under them when things aren't exactly what they expected.
Post-Interview Sync
We try to get this internal meeting on the calendar right after the interview. While a lot of companies handle post-interviews with solo interviewer surveys or arbitrary discussions, we have a single document that guides us through the process of filling in the gaps that we found during the pre-interview sync. Once we're done, we'll make a hiring decision. This decision comes down to 2 questions:
Do we believe the candidate can accomplish the goals we have for this role?
Do we believe we can collaborate effectively with this candidate?
If the answer to both of these questions is "yes," we're ready to send an offer! Otherwise, we'll respond and let the candidate know we're not moving forward, and we try to do that as soon as possible.
Offer Negotiation
The heading here is a bit of a misnomer; there's actually no negotiation in our offers. That said, it's not a take–it–or–leave–it or a one–size–fits–all offer, either. What we present is a salary range alongside an equity range (both listed in the job descriptions). The candidate can then choose where they want to land in both ranges, where the equity amount is inversely proportional to the base salary that the candidate chooses.
Let's simplify this by looking at a hypothetical example. We'll assume we have a job description with a salary range of USD$100,000 to USD$150,000 and an equity range from 0.5% to 1%. If a candidate chooses the low end of the salary range (USD$100,000), they'd get the top end of the equity range. If they were to decide they want to be in the middle, they could take USD$125,000 with 0.75% equity. Again, _these numbers are purely hypothetical_. Please see our actual job descriptions for real numbers, and don't hesitate to reach out to us if you're considering applying but you're having trouble understanding the way this scales!
Final Thoughts
We've built this process based on our own terrible experiences interviewing in the tech industry, and as a result, we've come up with something we're really proud of. Of course, we're not infallible and we recognize that there are likely issues we're missing, or biases that we haven't yet addressed. We're always looking for places to improve, so if you have suggestions please don't hesitate to let us know! The best way to do so would be to join our Discord server.
If you like how everything sounds and you're looking for your next role, make sure to check out our current openings! We're looking forward to hearing from you. 🥰
Credit Where Credit's Due
Our process was heavily influenced by Jonathan and myself (Trezy). Jonathan is no longer at Loophole, but we wanted to acknowledge his significant contributions during the process of designing our interview pipeline. ❤️
[1]: If the candidate doesn't have any open source work to show off, they can instead select something from one of the many Loophole Labs OSS projects. We prefer candidates send us one of their own projects because it requires less work from them, but this alternative is perfectly acceptable.