How We Hire Software Engineers

Interviewing software engineers is a notoriously difficult task. In fact, there are a ton of posts about how companies get it wrong. Some coding bootcamps even practice mock interviews with the goal of making the candidate cry, to simulate more intense interviews.

At Side, we’ve worked hard to come up with a system that is fair, leaves candidates feeling respected (pass or fail), and most importantly: actually evaluates how the candidate will do on the job. Using this process, we have had great success in finding candidates that are a good fit for our company. We wanted to share our process, so that other startups can improve their outcomes and the experience for everyone involved.

Problems With Other Approaches

Whiteboard coding can easily be administered incorrectly. If a candidate feels unsupported, the interview becomes more about “how well can this person manage the stress of being under a microscope”, and less about “how good is this person at solving problems.” This is particularly rough on people with high emotional intelligence (EQ) and good communication skills, since they are likely solving the whiteboard problem and attempting to manage the interpersonal dynamic with the interviewer.

Puzzle questions evaluate the wrong thing. Happening to see the correct solution one time to a tricky problem is not evidence that someone can write good code, break down problems, estimate effectively, etc.

Our Approach

There are four hurdles a candidate must go through before they can be hired:

1. Application evaluation
2. A ~30 minute phone screen
3. A take home assignment
4. An on-site interview that lasts almost the whole day

Application Evaluation

Applicants are most likely to be filtered out at this stage. Candidates typically arrive in two varieties: recent bootcamp grads, or not. Bootcamp grads are the overwhelming majority of people who apply.

When evaluating bootcamp grads, I typically look for a Science, Technology, Engineering, or Mathematics (STEM) background and passion. Not having a STEM background isn’t a total deal breaker, but, they really need to stand out to make up for it. When I look over their Github, do I see any signs that this person has done a project for fun? Does it look like this person was a leader in their bootcamp projects? Do they have a history of coding before bootcamp, or, have they been coding post-graduation?

For non-bootcamp-grads and bootcamp grads alike, I evaluate: do they know our technology specifically? Will they be able to write good React code when they show up? Have they ever used Firebase? What about things on the periphery of building features, like: CI, agile, build systems, etc.

I attempt to evaluate what sort of personal velocity someone has: how driven are they? What size projects do they take on? What have they accomplished so far, and does it seem like a lot, given their circumstances? This is often hard to get a read on.

Phone Screen

Phone screens aim to evaluate:

1. Can this person communicate well?
2. Are they telling the truth on the application?
3. Are there any personality red flags?

Phone screens almost always start off by following a mold (though the occasional candidate will drive things in a unique way):

Me: Hey, Candidate, is now still a good time to talk?

Candidate: Yep!

Me: Great. I figured we could structure the call by: first, I’ll give some background on myself and Side. Then, we can discuss your background more thoroughly, and at the end if you have any questions you can ask them then. Sound good?

Candidate: Yep!

Me: Excellent. So, for some context: Side is a modern real estate brokerage that…

It’s important to structure the call to reduce stress for the candidate. Giving context to the candidate is important because it shows respect: we’re both evaluating each other here. This segment lasts about 5 minutes, and is short because I’ve got it down pat.

When it’s time for the candidate to discuss their background, I usually hope for broad strokes that cover their history. However, along the way I will pick some project that I expect them to talk in-depth about. This is part of the “verify they are telling the truth” portion of the interview. I’m looking for very specific details, and “I” statements about achievements, not “we” statements — or anything else that would indicate specific individual contribution. I generally like to ask why a candidate is interested in Side: interest and passion go a long way to making a great employee. This segment lasts about 20 minutes.

At the end of the call, I let the candidate ask me questions. I love when the candidate has good questions. Thoughtful questions can do a lot for an interview. Generally, these are things deeper than “What’s a typical day like?” and “What’s your favorite part of working there?” Good questions demonstrate that the candidate has put thought into the company, or what working here would be like.

If everything goes well, the candidate is moved on to the take home assignment stage. I try to tell the candidate immediately if they’ll be progressing, but, I generally need time to think through the call.

Take Home Assignment

The take home assignment aims to evaluate a candidate’s ability to write features. We offer 3 different options and tell the candidate to choose whichever one they’d like. This, hopefully, allows the candidate to choose a problem they’re interested in and will excel at. Assignments differ in their frontend vs backend focus, differ in their amount of definition, and differ in their domain. In all assignments, we tell them we are interested in their ability to build features and they can skip things like automated tests, build systems, etc.

Timelines for submission are lax, and I give the candidate at least a weekend before submitting. We also state that we expect them to take a few hours to complete the project.

It’s possible that this stage can be skipped if the candidate has sufficient evidence that feature writing won’t be an issue (work experience/seniority, open source contributions, etc). Skipping the take home assignment is more likely for more senior engineers.

Upon receiving the assignment, I immediately see if I can run it without errors. In the past, config files have been left out of readmes, and necessary dependencies have been left out of package.json.

I then check to see the interaction and UI the candidate made. Our specs have wireframes and descriptions only, so, it’s often exciting to see what a candidate put together. Once I make sure things look like they’re working in the browser, then I dive into the code and understand how it’s working.

I typically shield my team from the time expense of reviewing a take home assignment until I’ve had time to vet it first. After things look good, I ask the team for comments. We make a joint decision if the candidate should be brought on for an onsite. If a candidate has reached the take home assignment stage, they are almost certainly going to pass it — we don’t like wasting people’s time. Either way, the candidate is notified right away and (in the case where the interview doesn’t proceed), asked questions or given feedback on what went wrong.

On-Site Interview

The on-site interviews take up almost the entire day. Candidates get an hour with direct team mates and 45 minutes with folks outside the team. Often, there will be multiple interviewers per one interview time slot. Non-engineering interviewers are checking to see if they can interface well with the candidate.

Engineering interviews are coordinated in such a way that there are two threads:

One thread focuses on a new problem and the different things an engineer might need to do to solve that problem: break it down into smaller problems, wireframe a solution, name React components you’d create, discuss pitfalls that the engineer would keep in mind when coding it, discuss data architecture to achieve that solution. These things are split up across interviews, so one interviewer may focus on data architecture and then next will focus on React components… but it’s all based on the same conceptual problem, so the candidate has some continuity.

The second thread focuses on the take home assignment. I generally ask the candidate to walk me through their take home assignment and show me the pieces they think are important. We talk about what got left out, what there wasn’t time for. If anything in particular stuck out to me during the review, I’ll ask them about it. I try to get a sense for their process, and what it would be like to work with them. I want to feel confident they coded the assignment without significant aid, and that they can produce features at a rapid pace. There are plenty of opportunities to see them get excited, or solve problems during this time. Additional interviews in this thread follow this same pattern.

After interviewers are done, they enter their opinions on a private scorecard and are instructed to not bias anyone who has yet to interview. However, they may prep future interviewers, eg “I didn’t get to ask anything about CSS, you should check in on that.” Interviewers are instructed to decide: if this was your company/team, would you hire this person?

Generally, results are unanimous. If there are differing opinions, I try to find out why. By the time candidates come on-site, we’re pretty confident we’d like to hire them (no sense in wasting everyone’s time). If there is more than one “no” response, it means we probably missed something in the screening ahead of time.

Wrapping Up The Process

If the candidate passes the on-site interview, they are set to receive an offer. There are a lot of intricacies that go in to determining what goes into an offer, which I won’t include in this post. It’s time to start ordering hardware, updating on boarding documentation, and setting aside Jira tickets suited for the new person.

Future Thoughts

Side has only been around for about a year and a half, so our process is still evolving. In the future, I’d like to add more options for the candidate to choose from for the take home assignment. It’s difficult to come up with good problems that don’t take up too much time — and we put a lot of effort into this.

Our process is intentionally low-stress, however, the consequence is that it can be time consuming. In the future, I’d like to put thought into how to accommodate candidates who have less time (eg, maybe a ‘lets code in person to save time’ track).

We’ve structured our process to be as respectful to the candidate as possible, while also ensuring we get a quality candidate. I’m hopeful that this post will inspire other companies’ interview processes.

While we’re on the subject… did you know Side is hiring? :)

Thanks to Ryan Jadhav, Adam Guthrie, Matt Hadley, James Byrum, Jonathan Rippy, Charles Osborne, Lizzie Paris, Jeff Judkins, Prescott Prue, and Stephen Saunders for help reviewing this post.