Doing Interviews

The Other Side of the Table

Let’s talk about the interview process. Tech company interviews have become the stuff of legend. Tales of impossible questions, nerve-wracking whiteboard coding, bizarre brain teasers, you name it: the Internet is full of examples of strange and wonderful experiences during interviews at leading technology companies.

In this article, we’ll explore some important aspects of interviewing candidates. Some of these aspects have no definitive answer or best practice, but I’ll offer my own opinions on what works and what doesn’t. A lot has been written on the process of technical interviews from the side of the candidate. It’s time to talk about what it’s like to be on the interviewer’s side of the table, so you can define and run this process yourself.

Let’s start with the obvious stuff: why do we do interviews? Well, we’re looking to make a decision as to whether we would want to work with a particular person. Can they help our company succeed by bringing themselves and their skills into the organization? As a technology company, we look for three major facets:

• Technical skill
• Team fit
• Suitability for the role

How can we perform interviews to identify these characteristics quickly, whilst leaving the candidate as happy as possible with the experience — regardless of the outcome?

How Many Interviews?

I’ve read horror stories of candidates wading through ten interviews or more before being offered a job. Larger companies with full candidate pipelines may be able to afford such luxuries. In my own experience of hiring candidates into smaller organizations, especially at the start-up or small business phase, is much different. Candidates are often interviewing at numerous companies — a number of which that could be more widely known than yours — so having a fast and efficient interviewing process is beneficial to both the interviewee and the interviewers.

💡 An expeditious interview demonstrates that you’re efficient and, most importantly, that the candidate is wanted.

When interviewing for niche or very senior roles, you may not want to follow a particular template. However, for engineers at most levels of experience, you’ll find an interview process consisting of two to three stages works well: two actual interviews and one optional take-home test.

You don’t need to give a take-home test to all candidates — use it when there is limited evidence of their coding ability (graduates; those who are unable to put lots of their work on Github; or those changing their primary programming language) or if you are on the fence about their ability.

Some companies do more or fewer interviews. I can’t vouch for the success of approaches that are wildly different from what I outline in this article. For example, Google and Facebook have been known to do intensive day-long sessions of about six interviews, but I do not have any data on whether this reduces the false-positive rate for quality compared to the process that I am used to following. I do know they make candidates quite intimidated…

The structure that I use:

• First interview. Both parties are getting to know each other, and we are assessing team fit. The hiring manager is present and possibly another person — typically a member of staff on their team or someone with a similar skillset from elsewhere in the organization.
• Optional take-home test. A fairly open-ended coding challenge that allows the candidate a number of different avenues to showcase their ability in a self-directed way.
• Second interview. A technical deep dive with people who would be peers of the new hire. For example, if the hiring manager is the team lead, the second interview would be with two of their engineers.

Let’s have a look at each of these interview stages in turn.

Interview 1: Getting to Know You and Team Fit

The first interview is where the candidate (usually) is the most nervous. One important thing to remember is that no matter the outcome of the interview process, even if the candidate is nowhere near experienced enough for the role, they should come away thinking that your company is a great place to work and that they would reapply again in the future. I cannot stress this point enough.

Be nice. Interviews are not a place for you to show how clever you are. It should be the opposite.

In this interview, it’s good to stay broad and let the candidate do the talking. Use a similar technique as in this article about 1 to 1s: listen, nudge, and absorb. Some good questions include:

• Tell me about your current role and what you’re currently working on.
• How did you get into technology/computer science?
• What’s the most interesting piece of technology at your current company?
• What’s the project that you’ve been most proud of? What made it great?
• What’s the worst project you’ve worked on? Why was it the worst?
• What’s the most interesting open-source project out there at the moment?

These questions are just a sample, but the idea remains the same: you want to allow the interviewee the space to talk and tell their story, allowing them the chance to put aside their nerves and let their true everyday selves show. Along the way, you’ll begin to get an idea of what motivates them: is it technology, people, business, or all three? Do they enjoy being hands-on or do they tend to delegate tasks to others? Are they well-read on the state of the art, or are they working at a company that has limited their technical choices? Are they aware of current technology alternatives at all?

It also helps to assess their analytical brain. For example, if they mention working on a file transfer application, probe deeper: what protocols were they adhering to? Did it support multiple concurrent connections? Did it have to deal with the out-of-order delivery of packets? How was the consistency of the transferred files checked? Excellent candidates would have these thoughts whizzing through their brains while they were doing the project, even if they didn’t need to implement all of it.

At the end of the first interview, assess the candidate around three areas:

• Technical knowledge. Does this candidate impress with their technical prowess when their years of experience are factored in? Remember that seniority is not just years under the belt.
• Team fit. Would I be happy sitting next to this candidate and working with them every day? Do they bring a different perspective and skill set that would improve the team?
• Suitability for the role. Do I feel that the current role is right for the candidate? Are they too junior and therefore need more mentoring than we can offer right now? Are they too senior, which means a risk they’ll get bored?

If those three areas are satisfied, try this one final check: if the hiring committee was on the fence and you had to argue the case for this candidate to the CTO, which way would the CTO swing on the hiring decision? I find my gut feel is usually correct.

Imagine yourself presenting this candidate to your own manager or even your CEO: would you argue their case if your own reputation depended on it?

Optional: Take-Home Test

Depending on the candidate, a take-home programming test can be useful. Treat this as optional, as the need for it varies from candidate to candidate. If recruiting a very senior member of staff who is prolific on Github, then it’s unnecessary. The evidence is clear. However, lacking evidence of their coding ability (especially true of graduates or very junior candidates), then it can be helpful to see how they tackle the test.

Our Take-Home Test

I won’t reveal exactly the coding challenges we use, but we don’t set ridiculous brain teasers that require intricate knowledge of bit-shifting. That’s not an accurate reflection of day-to-day work as an engineer at a SaaS company like ours.

Instead, we have a toy system that performs basic functionality, and we tell candidates there are a variety of ways the system could be improved. For example:

• New and improved functionality
• Tests that could be improved
• Refactoring
• Documentation that could be written

Candidates can take any of these areas to any level of depth that they like. We’ve had some very novel submissions this way, and it doesn’t pigeonhole our successful candidates to be the ones best at solving advanced exercises in Knuth’s The Art Of Computer Programming. Our toy system performs some functionality that our real system does, which makes it much more interesting to the candidate as well.

Once they submit the coding challenge, we forward it to an internal mailing list that our engineers monitor. We encourage engineers to volunteer to review the test and give positive and negative feedback and a recommendation about proceeding (or not) in the interview process.

Candidates who do not proceed still get the feedback so they can understand why we decided not to continue with their application.

Remember, candidates who fail at this stage should still feel that the company is fair and supportive, and they should feel that they could improve and reapply in the future.

Interview 2: Let’s Get Technical

At the second interview stage, invite two people who would be peers of the candidate in the organization. They can spend this interview getting deep technically and working out whether they would like to have the candidate working on their team. To add some continuity to the interview stages, if they have succeeded at a take-home test, then beginning the interview by talking through it is a great way of making them feel comfortable (after all, they’ve already succeeded!) But, inevitably, you’ll need to do some technical exercises together.

At this point, the candidate has already had an opportunity to show you the kind of code that they write, either by completing the take-home exercise or by sharing their Github with you. The success of the technical interview isn’t hinging on them working out the correct answer for all of the problems that you set (although that’s also nice). Instead, you’re looking to see how the candidate works on problems in person and how they communicate with others while doing so.

You can use a whiteboard or an IDE of their choice on a computer. However, these two workspaces are used for different types of interview questions.

Firstly, whiteboards. There are many horror stories online. The nervousness of standing up in front of interviewers; accidentally leaning on the board and getting covered in ink; sweating so much that the pen rubs off; you name it, it’s happened. The truth is that whiteboards aren’t for everybody. They also suit a particular style of problem. Whiteboards are suited for questions that involve drawing an architectural diagram of a system, describing the steps of an algorithm, or writing in a loose pseudo-code style. Expecting whiteboard code to be transcribed and then compiled successfully is missing the big picture of the exercise: understanding the candidate’s thinking process. I’d encourage you to stand at the whiteboard with the candidate and work with them by asking probing questions, rather than sitting in silence making notes while they have their back to you.

Good whiteboard questions could be:

• Imagine you’re building a chat application from scratch. What would the architecture of the system look like and how would you build it?
• Imagine that you’re writing a Java method that is being given tweet objects in real-time. How could you keep track of the user who has tweeted the most?

Whiteboards are not where your engineers are going to be writing most of their code in their day job. If you want to do an in-depth coding exercise in person, then a good technique to use is pair programming on a computer, just like they would if they were working with you. Ask the candidate ahead of time what their OS and IDE preferences are and get the computer set up ahead of time. You can then spend some time coding together. Even better, try to fix a real bug in your system. This exercise will give a good insight into how the candidate thinks, works, uses git (or similar), and organizes themselves. Try to have some fun while doing the exercise too.

Deciding To Make an Offer (or Not)

Once both interviews have been done, you should have feedback from all of your interviewers.

We have most recently been asking for a candidate score of 1 to 4 along with written notes.

Write all notes in such a way that, if revealed to the candidate, they would learn how to improve rather than be offended.

Keep in mind that in the UK, candidates can request feedback via the Data Protection Act. Following is a description of the rating scale:

• 1. Definite no hire. The candidate was definitely not right for the role or didn’t demonstrate the experience required.
• 2. Marginal no hire. The candidate may have been a consideration, but there were red flags during the interview that would result in arguing against their application.
• 3. Marginal hire. The candidate performed suitably but didn’t impress enough to warrant an instant job offer; however, we would argue their case.
• 4. Definite hire. The candidate was excellent — it would be silly not to hire them right now.

As an interviewer, there is an internal emotional conflict between being nice and doing what is right for the organization. When faced with this situation, you have to leave as much emotion at the door as possible. If you want to give a candidate an opportunity because their poor performance could have been due to nerves, but you know, truly, that they don’t meet your standards, suppress that emotion and reject them. It is much easier to break bonds with a person at the interview stage than it is after you’ve hired them and they are struggling on critical projects.

If the consensus averages on a high 3 or a 4, then go ahead and make that offer. If the average is a low 3, then get together in a room and debate. Any lower than that and it’s a no. Other factors such as the market conditions and the number of candidates in the pipeline (both actual and predicted) may influence your decision.

It’s never easy: a candidate for whom you have a few reservations may actually be the best you’ll see all year for that role. But how do you know? Well, you don’t. You can only make your best judgment at any particular moment in time. Good luck.

Join the Conversation

Do you have interview tips from either side of the table? Join the conversation by leaving a comment.

If you enjoyed this article, be sure to pick up James Stanier’s book from The Pragmatic Bookshelf:

Through the end of October 2021, you can save 35% on the ebook version using promo code jsengman_medium_35. Note that promo codes are not valid for prior purchases.

Further Reading

Also by James Stanier:

Become An Effective Software Engineering Manager on Medium: