The Software Engineering Interview — “The Process”
Hi I’m Brian
Before we get into it, a bit about me. I am an engineering manager who’s worked all over the stack across a few industries. I’ve been on either side of the table for countless interviews. I’ve held interviews for engineers across the full spectrum of experience, from staff+ to recent bootcamp/college grads. As a result, my opinion of the current state of the software engineering interview process is… well honestly not great, but I think we can make it better!
I am writing these articles to share my experience as an interviewee, but more importantly as an interviewer. I’m hoping that breaking down each phase of the interview, outlining what a hiring manager is looking for, will make the process less overwhelming for candidates. I’m also hoping that hiring managers reading this find ways to improve their hiring processes to be more candidate-friendly and yield more accurate results.
Interview Types
To talk about the overall interview process, we should run through a quick summary of common interview types. We‘ll dive much deeper into these in later articles.
- Technical Phone Screen: A quick talk with a hiring manager to evaluate the candidate’s technical background.
- Technical Interview: A more intensive evaluation of the candidate’s technical skills. Commonly these will involve solving an algorithmic problem or modifying existing code to add a new feature.
- System Design Interview: An assessment of the candidate’s high-level design skills. The interviewer will give requirements that a system needs to fulfill and the interviewee explains how they would solve the problem end-to-end.
- Behavioral Interview: An interview covering the candidate’s past interactions with their team, managers, and others. Typically these interviews are not very technical as they’re more about assessing interpersonal skills.
Companies often will have at least one round outside of the “core interviews” listed above. Here are some examples:
- Take Home Exercise: An assignment to solve an algorithmic problem or to build an application. These are often through a platform like HackerRank or Codility.
- Team Fit / Matching Call: A usually less formal chat between the candidate and their potential future peers. In these calls, the team usually outlines what they’re working on and tries to sell their team to the candidate.
- Product Fit / Business Case / UX Sense: An interview, usually with a more business-facing peer, to cover the candidate’s understanding of the business. These are fairly uncommon below senior/management levels.
Now that we’ve gone over these, onto “The Process.”
The Process
“The Process” needs to be able to evaluate any candidate’s fit for any role in any industry, which is probably impossible. So then what is “The Process” for figuring out if an engineer should be hired? If the end goal of “The Process” is to make sure that a candidate is a good fit for a position, then every company must have a process for every role, right?
Ideally, yes — every role will have a bespoke interview process with specifically targeted questions and criteria. Realistically, this isn’t going to scale well past a few roles. Creating a process to evaluate a candidate’s skill is hard and expensive. As a result, many companies wind up following a template like the this.
So… what?
So “The Process” exists — kind of. While there’s no great one-size-fits-all process to evaluate a software engineering candidate, there is a sort-of standard template that companies apply. There’s pros and cons to this for both the candidate and the company.
On the upside, since candidates are generally aware of “The Process,” they can prepare for many parallel interviews. Also, companies don’t need to reinvent the wheel when putting together their hiring pipeline.
On the downside, applying a generic pipeline for specific roles can lead to awkward edge cases that make things hard on the candidate and the interviewer. For example, when evaluating an entry-level, fresh out of school candidate, a system design interview might turn into an awkward hour where the interviewer needs to explain what a microservice is. The end result is that the interviewer understands that the candidate with less than a year of experience won’t be able to architect a new product end-to-end and the candidate probably walks away thinking they did awful. Was that hour really worth it for anyone?
Standardization makes sense, especially as companies grow, but it comes at a cost. In following a standard template, companies’ interview experience and fidelity of assessment is going to suffer. For the Googles of the world, maybe this is fine. For a budding startup, it could be fatal.
Can we make it better?
Probably! For most roles, there’s likely a middle ground that takes “The Process” and tweaks it to be more relevant.
Take the example above about the system design interview for an entry-level candidate. Looking purely at the process and not talking about specific interview content (we’ll get to that later), it probably makes sense to just omit the system design round and save everyone some time and the candidate some stress.
Another way to specify away from the standard might be to add a domain-specific round for a web engineer instead of asking them to design a full-stack Twitter-like application.
That’s all for now! Next we’ll start taking a look at each individual round, seeing how they work and how we can make them better.
