Best Practices for the Technical Interview Process—From Start to Finish
If you haven’t conducted technical interview before—or if you have, and ended up with candidates that were less than ideal—then you may find yourself wondering how to optimize your process. Companies like Apple, Google, and Tesla have their technical interview process down to a science. These organizations are literally built on the backs of the most talented developers in the industry. Many of those individuals found themselves at the top echelons of talent without the benefit of traditional educational or job experiences.
As a hiring manager for software developers, what this means is that a coder who went to community college might be as a good as a coder who went to MIT. Your job is therefore to apply a different kind of hiring filter to your candidates, one that can prioritizes an applicant’s coding talent as opposed to their educational background.
The Technical Interview Process Begins with Reading Resumes—or Does it?
Before you begin conducting technical interviews, you need to start by collecting resumes. This may seem counterintuitive given that our introduction talked about hiring by talent instead of by background—but there are still good reasons why the resume review remains an important keystone of the technical interview process.
For one thing, there are more ways to collect resumes than you might think. Many traditional recruiters stick to either soliciting resumes from people they’d like to recruit or placing requests for job applicants on venues such as LinkedIn—but there’s a third way.
For example, you can post what’s known as “take home problems” on your website. These are software engineer interview questions that are based on problems that you solve every day at your company. Good coders find it difficult to resist a difficult question, so you should get plenty of responses. Anyone who’s able to successfully answer your questions should be invited to submit a resume and an application, which means that you now have a ready-made supply of candidates who are interested in your company and who have demonstrated that they can do the work.
Once you have all the resumes you want, your next step is to read them—and there is much to be gleaned from a resume. For example, let’s say that one of your applicants went to MIT, but that they’re fresh out of college. Why would you hire them? A good candidate will be able to:
- Articulate the projects that they were part of
- Show how their contributions led to quantitative improvements
- Link to a portfolio that demonstrates their work
A great candidate will be able to point to all of these things—even without having had a lot of experience in the field. What’s more, you as the interviewer should be able to pick through a candidate’s accomplishments, understand which of them has the most relevance to your open position, and then drill down on these experiences during the interview itself.
Assemble a Hiring Team to Create Technical Recruiter Interview Questions
Making a list of technical recruiter interview questions is the next part of the technical interview process, but it shouldn’t be done alone. If you create interview questions in a vacuum, you risk alienating process stakeholders who will resent their lack of input. Worse, you could end up with a candidate who doesn’t reflect the preferences of their future business leaders.
First, you need to understand who the stakeholders are—who needs to be at the table when designing technical recruiter interview questions?
First, you need to start from the top and work your way down. Someone like a CTO or a CIO doesn’t necessarily need to be across the table from a job applicant asking questions (unless it’s a very small company) but they should be able to sign off on the list of interviewers and the questions you’ll be asking. Having their blessing will allow you and your hiring team to make better and more confident decisions as you move forwards.
Second, you need engineers on your side. Having the CTO’s blessing comes in handy here. A lot of engineers don’t necessarily like giving interviews or helping with the hiring process, but having the CTOs authority means that you’ll be able to compel a lot more enthusiasm.
Having engineers conduct or sit in on interviews results in better questions—and can help validate a candidate’s responses as well. It’s best to choose interviews who are experienced in hiring if possible, especially if they’ll be working above or alongside the candidate you’re hiring. If you can’t find an experienced interviewer among your engineers, try to train them using mock interviews, and make sure that they’re familiar with the tools you’ll be using to screen applicants.
Conduct Screening Interviews Before Asking Programming Technical Interview Questions
Many recruiters might be tempted to jump right into their programming technical interview questions without conducting a basic screener, but we recommend against this. A basic screening interview can weed out applicants for many reasons. As one example, let’s say that your workforce is planning on returning to the office once the pandemic ebbs—but that your applicant is planning to work remotely indefinitely. This kind of information might not come up in a technical interview, but it would certainly result in a hiring mismatch.
In general, recruiters should use their time to set expectations for the job. Candidates should understand what the workload looks like, what their ideal candidate looks like, and what the average workload looks like. Meanwhile, the recruiter should understand the reverse—what the candidate is looking for and whether their background matches expectations.
In most cases, you’re not going to learn more about the candidate than what you know already. These are candidates who already look good on paper, and this call serves mostly to verify that your applicants are interested in the job and are able to theoretically do it. About one in five candidates will drop out during this process, but don’t be discouraged. If there’s a mismatch between what you expect from your hires and what your candidates want, it’s better to get that out of the way early.
Beginning the Technical Interview Process
Now, finally it is time for technical interviews to begin. Although it took a long time to get to this stage, the wait was worth it. You’ve assembled a list of promising candidates and created a team of well-trained and motivated interviewers. Now all that’s left is for your candidates to test their mettle. Where do we begin?
Before you even start asking software engineer interview questions, the first step is to level-set about the ways that your interviews will be designed. The most important thing is that each candidate should have the same experience—they should be asked the same questions (with some exceptions), and they should be given the same tools. Interviewers should also agree on what a good answer looks like.
Once you’ve established this rubric, technical interviews can now commence.
Technical Screening Interview
During this first round of interviews, it is most important to make sure that each candidate is asked the same software engineer interview questions. This should be used as a venue for a collaborative exercise. The interviewer can work together with the candidate to solve problems that are closely related to the work that they’d be doing if they were accepted. Try to time the screening interview so that it lasts about an hour.
From this, the interviewer will learn a few important things:
- First, they’ll learn if their candidate is a good match for the specific problems presented by your company’s day-to-day operations. Most candidates with the programming skills they claim to possess should be able to fulfil this criterion. The next parts of the rubric are more important.
- Second, they’ll learn how well the candidate is able to collaborate with others. Teamwork is hugely important to the development process. If an applicant can’t sit through a paired programming exercise, then they probably aren’t a good fit for your position.
- Lastly, the interviewer will learn about the candidate’s distinct coding style in a low-pressure environment. Any style is acceptable at this stage—as long as the candidate can complete the exercise in the allotted time, but this will give you material to develop more personalized questions in later rounds of testing.
If you’ve set up your pipeline correctly, this technical screen should be able to narrow down a substantial minority of your candidates while letting the top tier of applicants through to the next round. With that said, there are ways to optimize the interview experience to make sure that you can evaluate every candidate fairly and make sure that your most talented applicants don’t drop out of the process.
Interviewers need to make sure that the testing tools they’re using closely approximate the tools that developers use from day to day. Many interviewers don’t do this, instead simply screensharing a text editor and asking candidates to answer questions using tools that they aren’t sued to working with. Using a text editor doesn’t make sense, however, because it cuts out one of the most important parts of a software developer’s workflow—the ability to run code, check for errors, and run it again.
Giving candidates tools they’re familiar with—such as those which approximate a full-featured IDE—means that they’ll be more comfortable throughout the technical interview. It also allows you greater insight into their thought process. Taking these tools away adds stress to the interview process without adding any valuable information. What’s more, a stressful interview process will make candidates less likely to accept any job offers that come down the line.
Whiteboard Coding Interview—What Not to Do
Whiteboard interviews occupy a somewhat uneasy place within the technical interview process, and we’re going to tell you why. Short answer? Many interviewers rely on the whiteboard at the expense of other interviewing tools, which is a detriment to the entire process. Most programmers don’t use whiteboards that often, which means that when you confront them with a coding interview that focuses entirely on whiteboards, even promising candidates might freeze up. Because of this, we recommend using an IDE optimized for remote interviews instead of whiteboards when possible.
That being said, there are some programming technical interview questions that will require the use of a whiteboard, and some candidates might like to be given the option of a whiteboard in order to augment their thought process. In these scenarios, CoderPad includes a Drawing Mode that lets candidates draw or diagram to explain a system—and also allows interviewers to sketch out a concept for a candidate. In this context, Drawing Mode acts as a supplement to the interview without taking it over completely.
Capping Off the Interview with a Technical Project
The final programming technical interview question will be designed to test the limit of a candidate’s abilities. Rather than answering questions about their background or working with the interviewer, the candidate will be expected to create a capstone project. During this part of the application process, the candidate is given a long period of time—up to five hours—and will be instructed to face a more challenging problem. This might include:
- Creating an entire application from scratch
- Writing an algorithm designed to run on a system with strict memory limits
- Design a continuous integration system
Because this part of the interview is so long—and because any applicant who gets this far has a good chance of being hired—it’s good practice to have multiple stakeholders sit in on these interviews in order to offer a wide range of opinions on the candidates being evaluated. At the end of these process, you’ll be able to narrow down the applicant pool to just three or four candidates.
Hiring Remotely (for the Foreseeable Future)
Now that you’ve narrowed down the candidate pool, what happens next? Bear in mind that you probably won’t be able to meet your new employee for quite some time. As such, best practice for remote technical hiring is to do a final round of due diligence before you make your decision.
Meeting with a team member
Depending on the importance of the role you’re hiring for, now is the time for your candidate to meet with one of your business leaders, such as the project manager. This allows the candidate to learn about the goals of the wider company, not just the department they’re working for. In addition, this lets the product manager gain an understanding of the hiring process and learn more about the people who might be working under them. Earlier, we spoke about making sure that your hiring process has buy-in from multiple stakeholders. This is part of that. By ensuring that the business leader knows you’re bringing up quality candidates, you’ll have more support when the time comes to make additional hires.
Final Review and Extending the Offer
At last! We’re finally into the onboarding process. Having narrowed it down to a very small handful of candidates, your job here is to compare notes and pick whoever’s best. Continuing with the “buy-in” theme, this is where you should have your VP of Engineering or a C-Level step in to help you make your decision—reviewing your collective wisdom and helping you make a “sanity check.”
Last but not least, your top-tier candidates may be considering other offers right now—so you need to make an effort to sell them on your position. After sitting through three rounds of interviews, you might assume that your candidate is an automatic “yes,” but it would be embarrassing if they didn’t. Make sure that you make more than a token effort to impress the people you’re trying to hire at the end-stage of the process, and you’ll be guaranteed to onboard enthusiastic employee who hit the ground running.
We’re not going to lie—technical hiring is a difficult and time-intensive process, but the results are what matter. Adhering to best practices and making the right decisions means hiring motivated employees who can drive your company further into the future. With CoderPad, you’ll be able to streamline the interview process in a way that benefits both recruiters and applicants. Interview more talent, and learn more about your candidates’ skill and knowledge when you get started with CoderPad today.