Discover more from Hartley's Handbook
My Optimal Software Engineering Interview Process Template
No two interviewing pipelines are the same, but with this straightforward template, you can at least have a jumping-off point.
Keep in mind, the questions within each of these chunks will be the key factor to making your interviewing process successful. This is merely a starting point and I’ll dive into each further along the way.
A major thing to remember within any interview process is that each portion of the pipeline should support the next steps. If the initial screen shows they may be weak in Ruby on Rails, the Technical Screen should either validate or disprove that they are weak within that area. If the Technical Assessment gives some mini flags of ego or cockiness, the Values Fit should work on validating or disproving that, and so on.
The simple template looks like this:
Initial Screen (45 minutes max)
Technical Skills Assessment (1–2 hours)
Values Fit (1 hour max)
Final Check (30 minutes)
The total time from the above is roughly 3-4.5 hours. Might feel short, but I’ve found great success in this amount of time.
I prefer to break this into 2 days:
By Day 5
Offer or Rejection
Be respectful of a candidate’s time and remember that they will likely need to take PTO in order to accommodate the second day of the process. Don’t get all high and mighty and say “Well, if they don’t want to spend time with us, they must not want the job!” Have some empathy and work with them to make it work.
Before we dive into each section, I want to outline the variables associated with shortening or lengthening an interview process. A while back I was asked to pour jet fuel on a process, which was an incredibly fun task to think through. In doing so the following variables came to mind as factors that determine how fast a company can really go.
Hiring Accuracy - What percentage of individuals must be retained (voluntarily or involuntarily) after X period of time
Speed to Fire - Does our management group have enough discipline and time for proper performance management, and are we okay cutting ties quickly
Speed to Productivity - How quickly do we need these individuals to be productive on their team or teams
Available Support - Are our mentor-capable engineers available to support their new team members or do we have other structures in place to support them
Level flexibility - Asking for ten junior engineers is much easier than five staff engineers. Are there gains if you bring in juniors quickly vs staff slowly?
Location flexibility - If the company is fully remote, it’s much easier to attract talent at different skill levels because the pool is much broader. Needing folks to relocate or convincing them to commute will likely drag your process out.
Core metrics you should always track for hiring:
Cost to hire: From resourcing to the moment they start, what is the total investment you have put into that individual? It’s not only the cost of one individual’s path, but the path of all others that didn’t make it that far. The total cost of recruiting, interviewing, etc, divided by the number of hires = cost to hire.
Speed to hire: There are two flavors of speed. The first is time to close the open role, or how long it takes from when you make a role public to that person’s first day. The second is time from first contact (cold email, LinkedIn Recruiter message, etc) to the time they start. Note, for each of these it goes until the person starts, not when the offer is signed. You can go with the signed offer as the end date, but I’ve seen too much weirdness happen post-signing to pat myself on the back at that point.
Now that we’ve covered the hiring considerations, let’s dive into the parts that make up our hiring process.
1. Initial Screen (45 minutes max)
Key Goal: Early assessment as to whether they seem to be a good technical and value fit for the company and team.
Who conducts: Hiring manager, or Technical Recruiter
Quick technical check
Additional Company Questions
The initial screen is equal parts of you selling the company to the individual and the individual pitching themselves to you.
Candidate Background/Overview: Start off by asking them to give a bit of their background, summarizing portions of their career that make them a good fit for your company. By this point you should have their resume, so don’t ask them to give you a chronological breakdown of every position they’ve held. Highlighting the roles that transfer best into the new role should give you a good sense of if they’re a one-skill master, or if they’re well-rounded and capable of picking up new skills.
Company/Role Background/Overview: Once they’ve gone through their background, ask if they have any initial questions about the role or the company. If they’ve done their homework, they may have several right away. If not, no worries, dive into your overview and pitch. At this point you have likely given this pitch many times, so be sure to ask if they have any additional questions or clarifications once you’re finished.
Check all the basic boxes. Do they have experience with the technology or subject matter you and your team work with day-to-day? If not, are they willing to learn and do you believe they can learn? Are their skills and prior work transferrable?
Give them a chance to ask any additional questions on their end. I like to close with, “Anything additional you would like us to know about you?”
Finally, if you feel the candidate fits 70%+ of the criteria for the role, discuss the next steps and check on their availability for the next portion. If you feel they do not, you can do one of two things.
Option 1 - Let them know you will review with the team and get back to them in a few days on next steps. Don’t let this drag out and absolutely do not ghost them. If they’ve spent any time with you, you owe it to them to give them some resolution.
Option 2 - Tell them on the call that based on what you’ve heard you don’t feel they are the right fit and you’ll be ending the process there. This is more of a gut punch, but it’s also clear and direct. I’ve done this a few times, but also added what they should look into for additional training (especially with less experienced engineers), and offered myself up as a resource if they had additional questions. It hurts, but I’ve established some good relationships this way and even hired a few later on in their careers.
2. Technical Skills (1–2 hours)
Key goal: Assess problem-solving and technical skills, as well as ability to work with others on the team.
Who conducts: Engineers, preferably from the team that is hiring, varying levels. Don’t make the mistake of only seniors interviewing for senior+ roles. Varying levels will work with the individual, so their opinions will likely differ.
The technical skill assessment gives you a snapshot of how an individual might work in your environment and with your engineers. There are a few different types of technical assessments that can be considered. Decisions here will depend on the six hiring considerations above and the speed at which you would like to move. Below are my three optimal options.
Home-rolled code day:
My preferred method of technical assessment if possible, the home-rolled code day allows you to create a custom 2-hour interview where you can make any code specific to the job they will do if hired. This method has the benefit of giving you an idea of their technical chops in your stack, but also gives them an idea of what the codebase or work will look like day-to-day.
The biggest challenge with this method is finding a problem that can be solved in a short amount of time, is specific to your company’s work (without needing to be production ready), while also giving the interviewee enough of a chance to understand the technical stack they might work in. Consider putting the files up on GitHub, that way the individual can pull the codebase down and test their environment ahead of time. Environment problems are not a reason to fail a candidate.
This method has the largest up-front cost and will require some engineering time to build initially, but the payout is huge for your process. It looks like this: one-hour technical challenge that represents real work, one-hour debugging or architectural discussion that represents real work, depending on company need. Each session should also be viewed as pairing with the individuals interviewing the candidate.
Homework, pre-work, and live review:
When we were testing for Front End engineers at a previous company, we would send homework to candidates to weed out candidates at the beginning of our process. If you go this route, the exercise should be no more than an hour, and you should know what red flags you are looking out for. Dogfood your process to make sure it is no longer than an hour, instead of stating it. While I generally don’t like homework for interviewing, there are a few roles where it is beneficial.
After the homework portion, we would bring individuals in for a few hours to sit in the office and work through another UI problem (with a simple API and some UI to sit on top of it). This represented real work they would do day-to-day, but gave them focus time to get it done. We were also non-remote at the time, so it gave them a chance to work in our environment. It is easy to give this time in a remote environment as well. Be available for questions during this time and note check-in points where you will see if they have any questions for you. This portion of the process can be telling about whether they will reach out if they get stuck (there weren’t any “gotchas”). While most individuals were able to get the work done, or ask questions along the way, there were definitely anomaly candidates that this process sifted out.
The last piece of the interview was a code review with the individual along with a few prompts about how they would extend the code further if needed. Completion was not the only way to pass, but was a good sign of speed or expertise with the toolset. Discussion, ability to take feedback, and ability to think through future states told us more about a candidate.
There are several companies that specialize in outsourced technical code tests. Companies that come to mind are Woven, Byteboard, and Karat, each giving you the ability to outsource and standardize testing immediately. If speed is your top priority, outsourcing the assessment is your best bet.
Each of the companies mentioned gives different levels of interviews in different languages. Each also has consistent interviews with set scoring to help eliminate bias in the process. It also removes any internal concerns of sandbagging or sabotage.
It might feel more impersonal, but if it saves you and the candidates time (they can take the test whenever is best for them), is it really a negative?
There are plenty of other ways to assess technical skill, but the above methods are what I have found best when trying to stick to a 2-hour timeframe. What are some other methods you think work well?
Note: The technical assessment should not be a fishbowl process. Especially if you work in an engineering culture that promotes collaboration, the interview should also be collaborative. The interviewee is not there to put on a show, they are there to get a sense of if they would be comfortable working in an environment with your engineering team. I’ve seen too many technical interviews where a good engineer panics because they are getting nothing from the interviewers.
3. Values Fit (1 hour max)
Key goal: Does the individual align to the company and team values or are there red flags that prove otherwise.
Who conducts: Cross-functional partners, stakeholders, other engineers
The Values Fit portion of the interview is debatable for me. If you’ve included questions about your values as an organization and as an engineering team up until this point, you may be able to skip over this portion.
Where I see the biggest benefit of this particular interview is the cross-functional partners. Product Managers, Designers, or engineers from other teams can give a different perspective of the candidate. Where the values interview becomes difficult is training. The more individuals you add to a process, the higher the risk of unconscious or even conscious bias leaking into the process. More training is needed as is a review of scores from interviewers to ensure they are assessing on the right areas.
Keep in mind that it should be made very clear how this interview differs from the others. Candidates are already in a fog during interview day, so clarifying that they will be asked more about how they work with others, past experiences, and optimal work environment can relieve some stress of context-switching.
Another way to think about this interview is the “soft skills” or “human skills” section, where the technical was the “hard skills.” This portion of the interview is where many companies dive into the “Tell Me About A Time…” questions. While these questions are helpful, I have a few that tend to tell me more about an individual. I go into detail here, but the four questions are:
Themes that should be answered by the end of this interview are:
What are they like to work with?
Would I be able to collaborate with this individual?
Do they fit the style of work we are trying to do? If not, what concerns do I have about that?
Where there are concerns, did the interviewers give a chance for the interviewee to clarify or follow up? Feedback in this section holds less weight in the broader interview process, but can be beneficial for any red flags or patterns that emerge in other portions.
An example where this was helpful. A candidate nailed the first technical portion of the interview but in the second part of the technical assessment and the values fit interview, they were condescending toward all female interviewers. One instance of this is generally enough to fail a candidate, but when it is across multiple interviewers it is even more clear.
4. Final Check (30 minutes)
Key goal: Answer any remaining questions on either side.
Who conducts: Hiring manager
At the end of Day 2, the hiring manager should spend time with the candidate to see how things have gone. By this point, the Hiring Manager will likely see some of the feedback coming in and can also ask the interviewers to see if there are additional areas to dig in.
I generally take this time to see how the process has been for the candidate so far and if they have any questions about the company, the role, or the teams. This is also a good time to validate that the job still looks like something they’re interested in. In some cases it’s not and you can have an open conversation about their concerns.
Questions during this portion should be about what makes them nervous about the potential new role, areas where they think they would need support, or how their previous experiences would help them transition into the position. I also like to ask about how they like to be managed, how their best/worst managers managed them, and what they would be looking for from me if they took the role.
This is a final check because both candidate and interviewer should feel like they know where things stand at the end of the day. If things have not gone well or you are confident it will be a rejection, it’s okay to have that conversation.
Before closing, explain the next steps:
“Thanks for your time today. I’ll be getting with the team to review all feedback and you should hear something from myself or RECRUITER in the next three days. During that time, let us know if you have any questions or concerns.”
Be quick with the review and follow-up to ensure you are doing right by the candidate and keeping your process moving. Personally, I like to finish all of it in the following 48 hours if at all possible. Dragging it out past 48 hours is tough both internally and for the candidate.
5. Offer or Rejection (30 minutes)
Key goal: Present the result of the interview process.
Who conducts: Hiring manager and/or Technical recruiter
Unlike L’Orchestra Cinematique’s song in the trailer for Edge Of Tomorrow, this is the end…of the process. At this point you reviewed all feedback, had follow-up conversations where needed and determined whether you would like for the candidate to work with you and your team.
If you are extending an offer, you met with your internal team and know what will go into the offer from a salary and benefits perspective. My quick take is if the individual has stated a desired comp already, either hit it or go above what they asked for. I generally expect folks will come back with a counter (it’s a good practice as a candidate), but never lowball their initial ask unless they oversold their skills or you don’t mind them rejecting the offer. Keep in mind if you do undercut their initial stated comp request, your probability of losing the candidate skyrockets. Common sense, but lowballing is a bad way to start a relationship.
If you are rejecting the candidate, be clear about why and make clear whether there is an opportunity for them to take a position in the future. If they are a good team fit, but their skills do not match, let them know how the may enhance those skills for the future. They may tell you to shove it, but rejections with no reasoning are harder to swallow. If the candidate is being rejected because they are a total jerk, it may be more difficult to find the right words, but whatever you choose they will always see you as wrong, terrible, and incompetent.
At this point, the hope is you have closed the deal or cut the candidate loose and can move forward accordingly. Regardless of the outcome, take a moment to look back at the process for that candidate and see if there are any adjustments you should make.
No reference checks
Simply put, reference checks are a waste of time if you’re trying to determine whether the individual will be successful or not. I’ve never learned anything in a reference check that I didn’t already know or was revelatory. The key thing to remember, no one will give you reference information if they’re not prepared to say something complimentary about the individual.
Remember, you are not some incredible detective that will shine a bright light on something bad the person did by interrogating a source provided by the individual.
I’m sure there are certain scenarios where this can be impactful, but I’ve yet to find them.
No Brain Trust Reviews
I’ve worked in several places where all individuals involved in the interview process for a candidate get into a room and discuss whether the person should be hired or not. I’ve also eliminated that process at all of those companies because it is a waste of time and unproductive. Here’s why:
The loudest voice wins
The quieter voices don’t have a seat
There is rarely anything new to learn
Group-think is all too common in these scenarios and whoever casts the first stone ends up leading the decision in the room for the other individuals. Descenting opinions are typically difficult to express, and any positives or negatives for a candidate tend to get buried if one interviewer is loud about their stance.
It is more beneficial to spend time with individuals to clarify their feedback or ask additional questions. Do not ask leading questions when following up, but see if they can expand on why something seemed like a positive or a negative. We all see things differently, so where I may view something as a positive, you may view it as a negative or vice versa. Chatting through the difference in opinion is better served in a one-on-one setting than in a group conversation.
Whew, there you have it. A small template with a lot crammed into it. The key thing in any interview process is that it is not a crockpot. You cannot set it and forget it. The process is a living thing that should evolve and improve over time, shifting based on hiring considerations and what roles are needed and when.
Keep poking at it and review metrics frequently. What else do you think about for your software interviewing process? What did I miss? Let me know below!