In my career as a consultant, I constantly need to conduct tech hires for tech companies. As a result, I have explored a wide variety of technical interview methods.
I will share the methods I know below, together with their pros and cons, the conditions under which they may be useful, and provide some tips for using each method.
First there are a few reasons why you want to explore different technical interview methods:
Tech companies often conduct hires globally.
Those who cannot afford to fly every candidate in for interviews, will have to employ remote interview methods, so that they can do the preliminary screening online, to filter out unwanted candidates and shortlist those who show potential.
To save time
Using a different interview method could also help to save time.
Engineers are often involved in a technical interview, due to its technical nature. Companies want to save engineers’ time, because to a tech company, engineers’ time is best spent on product development.
They can’t be spending all day attending interviews. So they often think of a more efficient way to conduct technical interviews.
White-boarding, a very popular technical interview method, does not resemble how a software engineer does coding in real life.
Consequently, some companies look for an alternative, which may be more suitable for screening a particular role.
Usually it is because the style of the method matches with how the role supposedly works in the company. It structures the interview in a more realistic fashion.
On seeing how the candidate performs in the interview, the interviewer can make a better assessment on whether the candidate can perform equally well if he/she works for the company.
1. Panel interview
A panel interview is the most common form of tech interview, where a group of interviewers interview a candidate to find out if he/she has what it takes to fill the job opening. The interview also gives the candidate a chance to find out more about the organization and the opening, as the conversation goes two-way.
Skillful interviewers can make this form of interview comfortable to the candidate, by making it as conversational as possible, so as to get the candidate to open up and talk candidly about his experience. For this reason, behavioral interview is often conducted in a panel interview format.
The drawback of panel interview is that the technical assessment might not be in-depth due to the conversational setting.
Tips: Let one of the interviewers serves as an observer, who observes the body language of the candidate, to catch any subtle hints on whether he/she is passionate about the role.
2. Tech Q&A
In a tech Q&A interview, only the interviewers get to ask technical questions and the candidate answers them, in a rapid-fire format.
If you find that your panel interviews tend to go chatty (talkative candidates or interviewers) or awry (you took up too long time discussing about a particular skill or experience), you might want to explore the option of having a tech Q&A session inside an interview.
By splitting a technical interview into an introductory first half and a tech Q&A second half, you can make your interview more efficient. In the first half, you give the candidate the background information, arrange a round of self-introductions and ask the candidate general questions. In the second half, you evaluate the candidate’s knowledge in-depth.
Tips: Let the candidate knows the format of the interview beforehand. It helps him to prepare for what is coming.
3. Phone screening
Phone screening is a short tech Q&A session over the phone. It is typically used in tech companies with very lengthy hiring process, as the first filter.
Companies do phone screening because they have got too many applications in the pipeline and there is simply no time for the hiring team to meet all applicants.
Another reason for doing phone screening is that it can be done remotely. Companies typically do a phone screening before inviting the candidate over to the nearest office for interview.
The problem with phone screening is that it is often carried out by a non-tech interviewer (to save engineers’ time).
I have been screened on the phone once by a tech recruiter from a Fortune 100 company. The recruiter was not a technical person and I could tell that she was reading the questions from a script and checking my answers against the model answers to see if they are correct.
There were a few places where I could give a better answer, but opted to just reply with a common one, for fear that she might not understand what I said. The whole screening took almost an hour and a half, which was quite unpleasant.
Another potential problem with phone screening is that, there is a small chance that the candidate might cheat, by having an assistant beside him quietly googling for answers with a tablet PC.
That is why sometimes interviewers do not tell the applicant that a phone screening is coming and it all happens in a surprise “follow-up” call. That adds some discomfort to the candidate’s experience.
Also phone screening is terrible for behavioral questions, because the interviewer does not get the chance to observe the candidate’s body language, which sometimes tells more than his/her answer.
4. White-board coding test
In a white-board coding test, the candidate solves a coding problem on a white-board without using a laptop or internet connection.
It is a very common form of technical interview. Its advocates reason that by taking away the laptop from the candidate, he/she can no longer rely on the internet to search for an answer, and so he/she can only solve the problem relying on his/her skill alone.
The unfamiliar setting creates a stress on the candidate’s mind that any weakness in the candidate’s thought process will be exposed quickly. And so the white-board coding test can tell good engineers apart from bad ones effectively.
There an element of truth in that saying, otherwise this method would not be so widely adopted in the tech circle. White-board coding test does provide a window for the interviewers to peek into the candidate’s mind, to observe his/her problem-solving approach, as shown in the video below. In the video, two Google software engineers simulated the white-board coding test.
The important thing about white-board coding test is that it must be carried out by experienced interviewers who understood it. The best example is shown in the video. It may look easy to execute, but it is actually quite technical. Inexperienced interviewers often made the following mistakes:
- Not giving the candidate sufficient time. In the video, the two Google engineers took about 20 minutes to solve a very simple algorithm problem. Many companies have actually allocated the same time for much harder problems. They filtered away good candidates who just need a little bit more of time to think.
- Lack of interaction with the candidate. In a white-board coding session, the interviewers are supposed to interact with the candidate, to guide him/her to think out loud, to offer him/her some hints if he/she got stuck. This mimics the teamwork in the company. (Which company has engineers develop product features by working alone in front of a white-board?) The primary objective of the test is to see the candidate’s problem-solving process. Checking if he/she knows something is secondary (there are better methods discussed in this article for that purpose).
Tips: a very experienced interviewer will be able to conduct a white-board coding test as “just another learning session” for the candidate instead of a “student vs examiners test”. When the candidate does not feel he is being tested, he performs naturally in the interview.
No doubt, filtering by white-board coding has an unavoidable selection bias: it is stressful, so you have false-negatives due to stress—excellent engineers who normally perform well might get stuck in front of the white-board due to a temporary stage fright, not due to a lack of technical skills. Therefore some companies have opted for alternative methods.
5. Paper coding test
A paper coding test is a time-limited coding test to be undertaken on a paper or laptop, on-site without supervision. It can be administered with or without internet connection. There may be a discussion session following the test in which the candidate is given a chance to explain his/her answer.
This form of coding test is less commonly used, due to its resemblance to examinations in schools. The questions are mostly simple programming problems. If internet connection is provided, the difficulty of the questions can be raised higher.
Typical questions of a paper coding test are about basic data structures and algorithms, database queries, programming concepts and techniques. Questions involving system design are not suitable for this type of test, because an in-depth discussion is probably needed. A paper coding test is more useful for screening entry-level to mid-level software developers.
Compared to a white-board coding test, a paper coding test is time-saving as it requires no supervision. So you can give the candidates more questions in the same time-frame.
6. Take-home coding exercise
A take-home coding exercise is a coding assignment to be attempted by the candidate at home. There is usually a deadline for the submission of the solution, and a follow-up interview to discuss the solution (to rule out cheating).
The coding assignment is usually a mini-project related to the job scope of the opening. By allowing the candidate to use whatever resources available to attempt the assignment, the interviewer removed any bias factors in the evaluation of the candidate’s skills.
For the same reason, the assignment has to be of considerable level of difficulty, in order for the test to be effective.
The interviewer evaluates the submission from several angles: understanding of the business requirements, code quality, knowledge of software engineering practices, performance and robustness of the solution, etc.
One can tell a lot about the candidate’s skills and experience just by looking at the candidate’s solution. A good coding exercise also gives the candidate an idea of what his future job entails.
The downside of this approach is that, it requires the candidate to commit a lot of time into working on the assignment. There is a possibility that the candidate will pass on the opportunity, finding it troublesome to pursue or viewing the company as trying to extract some kind of free labor from him/her.
Also it takes a lot of thinking to design a good take-home coding exercise that is unique and cannot be found anywhere on the internet.
7. Online coding test
An online coding test is no different from a white-board coding test except that it is conducted online with the help of some special software applications.
By using a real-time coding tool such as CoderPad, Codility, HackerRank and Codeground (I will do a review article for these tools one day) or the old-fashioned Skype or GoToMeeting, an interviewer can now conduct a white-board coding test remotely, observe the coding activity in real-time.
It preserves all its original qualities, except that perhaps the candidate feels more comfortable attempting the coding test from home.
Because an online coding test is simpler to facilitate, many companies use it as a first line of filter before other steps.
8. Pair programming exercise
A pair programming exercise is a unique form of technical interview, in which the candidate forms a pair with a software engineer from the company to solve a small coding challenge or a problem concerning actual development code.
The proponents of pair programming exercise argued that, in order to see if the candidate can fit into the team and write good code, the best way is to have him/her works together with some team members in a coding session. In that way, the candidate can decide if the team and the code are what he/she likes to work with. The team can decide if he/she can help them out with their project.
I think it is a novel idea. I have used this form of interview in the hiring process for some roles with good results. These are roles whose work depends on close collaboration with a lot of people, such as site reliability engineer, DevOps role and UI developer. The video below demonstrates what pair programming looks like in practice.
However, interview by pair programming exercise has a drawback. You have got to ask one or two engineers to do this for all shortlisted candidates. If you have many candidates, performing this exercise again and again is very distractive to their work.
Notable mention: Code walkthrough
This form of technical interview is rarer, so I decided not to list it as a 9th, until it gets more popularity.
In a code walkthrough, the candidate gives a presentation about a piece of code, usually a work sample of his, or the completed take-home exercise, or even a code fragment from a well-known open-source project.
The interviewer will be able to see if the candidate is able to explain why he/she structured the code that way or chose to use a certain data structure or application design. It is a good way to check if the candidate understands good software engineering principles, can read code quickly and spot potential issues.
Code walkthrough on its own however tells nothing about on how well the candidate writes code.
Now that you have seen 8 different ways to conduct a technical interview, which one should you use?
You are advised to choose the methods that fit your company’s culture, workflow and hiring needs to get the best results. I will share more details in my email course on how to pick the right methods, personalize them to form an effective technical interview process.