How to Conduct Tech Interviews Like a Pro: 5 Helpful Tips

Other articles by this author: 

• Zooming in Pajamas: What Will Happen to Remote Work?

Introduction

I have been conducting technical interviews for almost 20 years, in person and remotely, in different technologies, and for different roles and levels of experience. Through that experience, I have learned that a successful interview depends much more on the interviewer than the candidate.

If you search the internet for guides or advice on how to achieve a successful technical interview, you will see that the articles are always oriented towards candidates. There are no (or at least none that I have found) adequate guides about how to conduct a good technical interview as an interviewer.

In this article, I share some of my experience, hoping that it can be useful for those who conduct interviews. I provide examples concerning Java, but the article applies equally to any technology.

What is a successful technical interview?

First, let me share my definition of a “successful technical interview”.

A successful interview is not the one in which the candidate passes the interview. There are situations in which a candidate can pass the interview with honors, and the interview can still be a failed case.

A successful interview is one in which:

1. A candidate who did not meet the required profile was rejected, or

2. A candidate who met the required profile was accepted.

Similarly, a failed interview can be defined as:

3. An interview in which a candidate who did not meet the required profile was accepted, or

4. An interview in which a candidate who met the required profile was rejected.

It’s impossible to completely avoid cases of failed interviews. The advice given below, however, can help you minimize the risk of failed interviews.

Tip 1: Describe the interview agenda to the candidate (and adhere to it)

Without prejudice to any profession, there are jobs in which the scope of interview is usually limited. If you know how to drive a car or a motorcycle and use a map (or a GPS), for example, you are qualified to be a delivery or taxi driver. Some knowledge, such as memorizing restaurant opening hours or the best routes to and from the restaurant location, can be learned by a future delivery driver in a matter of days or even hours.

In the tech world, however, the universe of possible questions and scenarios is immense. Often, even if it is limited by a specific technology for a specific role and a specific level of experience, the universe of questions can seem inexhaustible.

Think, for example, of Java. Focusing on just the differences between major versions 5, 8, 11, etc. still leaves a very large universe:

• What classes are now deprecated?

• What new reserved words were included in each version?

• What is the underlying reason for those new reserved words or strategies?

• Are there differences in memory management? Etc.

I only listed the changes in the syntax and mechanisms of the language above. Now imagine the Java API, which is impossible for a single person to know 100%. And we have not yet reached Java's own frameworks (Spring, Hibernate, Struts, Junit, etc.). In addition, candidates will surely be asked questions about tech-agnostic concepts, like design patterns, communication protocols, architecture, unit testing, etc.

No matter how intelligent, educated, or experienced a person is, it is impossible for anyone to adequately answer 100% of the possible questions.

That's why outlining the interview agenda to the candidate in advance can remove some stress and uncertainty for the candidate. It also gives the candidate the opportunity to take the initiative and say whether the agenda seems appropriate for them. For example, we can start with a basic description:

“The interview will consist of questions about the Java language, its syntax, and properties. I will also ask you some questions about databases (both relational and non-relational), microservices architecture, design patterns, and the Spring framework. In addition, we will dedicate 30 minutes to a programming exercise."

The candidate can then take the initiative by saying something like:

• “My database experience is limited to relational databases, I have no practical experience with NoSQL, I have only read the theory”; or

• “In the last few months I have been working only with Java 8, I have not yet had time to familiarize myself with later versions.”

These types of early responses from the candidate give the interviewer the opportunity to readjust their interview and spend more time on the areas in which the candidate will be able to perform better, and to avoid asking the candidate questions they know in advance that the candidate may not be prepared to answer correctly.

It is also appropriate to clarify how the interviewer and the candidate should or will behave in the interview. When the interviewer takes notes, for example, either on paper or on the keyboard, it may seem to the candidate that the interviewer is distracted with other tasks. A simple statement like “If you see me writing or typing it is because I am taking notes about the interview, my attention is 100% on you and this interview” can help the candidate better understand the interviewer's work environment.

A clarifying statement that I have found extremely useful is:

“If I ask you something that you don't know or have no experience with, it is perfectly acceptable for you to tell me ’I don't know.’ Then, we can focus more on your areas of knowledge rather than on your areas of opportunity.”

This simple statement generates in the candidate a feeling of immediate confidence. They now understand that the interviewer is someone who is aware of human limitations and that being an expert does not mean having to know everything.

Tip 2: Let the candidate lead the interview

During the interview, the interviewer's contribution to the interaction should be 10-20%, and the candidate's should be 80-90%. That means the interviewer must listen far more than they speak. Achieving this goal is quite difficult, maybe even impossible, if the interviewer focuses on questions that are too specific or that require too much detail.

For example, such questions as “Describe the JSR 335 standard,” “What is JEP 444 about?” and “Describe the differences between MVC, HMVC, MVA, MVP and MVVM” are clearly stressful (and I would say useless) and will lead to the failure of 99% of the candidates. Ironically, these questions involve concepts that most candidates with experience in Java master in an acceptable way, but they are simply poorly posed.

The sample questions above may seem extreme to the reader but believe me when I tell you that I have encountered real cases in which interviewers asked these types of questions, and even some that were worse.

An alternative to the previous questions would be inquiries that are more open-ended, such as: “What is functional programming?” “Describe the threading mechanism in Java” and “Name and describe 3 design patterns that you know and the cases in which they are applied.” These requests are more general and open to interpretation. They give the candidate an opportunity to project their level of knowledge in the subject: I know the concepts / I have practical knowledge / perhaps I know tricks and workarounds of which the interviewer isn't even aware.

Such questions offer the candidate the opportunity to talk about their knowledge; information that we can later use to restate or ask new questions. This allows the candidate to lead the interview by default, since their answers will guide us to the areas in which they have more experience.

Always remember: an interview should be a conversation between colleagues, not an interrogation.

Tip 3: Make corrections and observations only when they are short and clarifying or complementary

Let's be honest: we all like to show off our knowledge to a greater or lesser extent and, as interviewers, we find ourselves in a so-called "position of power." This can cause us — especially less experienced interviewers — to fall into the “ego trap,” let me explain.

Sometimes, we encounter candidates who, due to nervousness or lack of confidence, remain silent for prolonged periods of time searching their minds for an answer that is not there. Or worse, they begin to “guess” the answers, producing long monologues that are mostly full of incorrect information.

When this happens, the interviewer may be tempted to heavily correct the candidate's answer, turning the interview into a basic course on X or Y technology. This does not add value for you, the candidate, or the interview. It can also place the candidate in a defensive position toward us, something that should be avoided at all costs.

Of course, it is prudent to make corrections and convey clarifications to the candidate about their answers. This should, however, be done only when most of the candidate's answers are correct, and the interviewer's comment is merely clarifying or complementary.

A partially correct answer from a candidate might be something like: “Interfaces in Java only allow abstract methods to be defined, not implemented.” This answer may be accompanied by an interviewer comment such as: “From version 8 onwards, implementations can also be defined in the interfaces.”

In that example, the answer given by the candidate is mostly correct, we only added some limited information that the candidate forgot to mention. The candidate can take the initiative and say something like “Oh, right!” giving us the opportunity to ask deeper questions that may confirm that they just forgot the detail, but really know the topic. Alternatively, we may receive a response like “Really?" that confirms a small gap in the candidate’s knowledge which can be filled in less than 10 minutes.

In scenarios in which the candidate really ignores a critical topic, we should not try to teach the candidate. It is instead preferrable to guide them with short comments such as “I recommend that you review X or Y topic,” and move on.

Tip 4: Don't hire people who know, hire people who have the ability to learn

This is probably the most important point to consider. To understand why, let's play a small game of probabilities:

Suppose there are 4 skills that our desired candidate must have:

This is possibly the simplest case of a profile requirement that I can imagine.

Each requirement has two options: the candidate either has the skill or not, which means that each skill has a 50% probability of being present in the candidate. We also want all 4 of the skills to be present, which gives us a probability of 0.5^4, or 0.0625. This means that, on average, we must conduct 16 interviews to achieve a desired case — if we are lucky.

In this example, the profile is oversimplified (as is the math). I assume that if a candidate knows Spring and Hibernate, they must also know the basics of Java language without considering Java specializations such as Threading, JDBC, JSP, design patterns, etc.

If, for this simple case, we will need 16 interviews (if the candidates know what they say they know), imagine if we build a more realistic profile, one that includes cloud technologies, microservices, Web Services, and tools like Kafka or Kubernetes, etc. The number of interviews needed increases with each new skill requirement, and the pool of desired candidates decreases.

Even for this simple case we can facilitate our work by not only exploring a candidate's knowledge, but also their ability to acquire the required knowledge.

1. The candidate may not have good English skills, but is it really necessary for the candidate to interact with English speaking people? Is it possible to use another team member as a translator when this happens?

2. The candidate does not speak English well, but can they understand written instructions? Is this necessary when online translators exist?

3. The candidate does not know Oracle, but perhaps has extensive experience with another RDBMS such as MySQL. How long would it take to train the candidate in the particularities of Oracle?

4. The candidate does not know Hibernate, but has experience with other ORMs. How difficult is it to bring them to the desired level of Hibernate knowledge?

5. The candidate has no experience with Spring, but has experience with Google Guice. How difficult would it be to train them in Spring?

Looking back on my personal history of interviews and projects, I’m sure that in most cases it takes less time to train a candidate after you hire them than it does to find an ideal candidate. This, of course, only works when the candidate has at least the minimum necessary proficiency to learn what is required for the role.

Over the last few years, I have noticed a widespread problem in the tech industry: companies always hope to find the perfect candidate instead of investing in training. Companies should invest more in generating value and less in finding it. As an interviewer, you can help your company by making the right observations.

I started in this industry knowing just a little bit of C and Visual Basic, my first company trained me and helped me become who I am today. Sadly, this practice has been lost.

Tip 5: Break the ice

There are different theories about how long it took humans to create the first spoken language. The most conservative estimates suggest that it took our species a few thousand years to create the first spoken language.

Before speaking, we developed mechanisms that allowed us to understand the intentions of others through facial expressions; this biological development continues to this day. We can detect anger, frustration, sadness, joy, and other emotions in other humans that we do not know and with whom we have never spoken. That is why it can be difficult to pretend to experience an emotion other than the one we are really feeling. What is very easy, however, is to misinterpret emotions.

Suppose you walk into your interview after a failed production release. Or suppose your release was successful, but you didn’t sleep the night before, maybe you had problems with the internet and had to unexpectedly travel to a friend's house to conduct that interview.

All of these situations cause negative emotions in us as interviewers that, if not communicated properly, can create a negative (wrong) perception by our candidate. The candidate may notice your displeasure or frustration, for example, and misinterpret it as you not wanting to be in that interview, or that you simply disliked them from the first moment.

Also, consider that as an interviewer, you represent your company. If the candidate notices your stress, they might think that the company is disorganized, or that the project demands too much of the employees. You could discredit your company even without saying anything.

Remember that your main objective is to create an environment of trust with the candidate. When the candidate enters the interview room or connects to the virtual office, they may be nervous and stressed because they don’t really know what to expect. Part of your job is to eliminate that stress, not to add more. You have two options:

1. If you can hide your emotions well, you will be able to create a positive atmosphere despite your emotional state.

2. If you are someone whose emotions are easily apparent to others, it is better to speak the truth in advance.

If you are a little stressed about work, you can say something like: “Sorry I'm a little late, I was just solving a minor problem on the project.” Such a comment, although it may seem out of place, achieves several positive things:

1. It lets the candidate know that you and your team are an efficient group that solves problems.

2. It clarifies that any stress or discomfort you show during the interaction is associated with the project issue, not with the candidate or the interview.

3. It humanizes you in the candidate's eyes, helping to relieve some of their stress and making them more empathetic toward you.

4. Finally, you have spoken the truth, but you have not revealed specific details of your project and you have not placed your company in a negative or prejudicial light.

Once you clarify the true causes of your possible stress, both of you will feel more comfortable with each other. You will notice that, by honestly conveying your emotions, both you and the candidate will have more confidence in an almost organic way and the conversation will become more relaxed in a matter of minutes.

If, on the other hand, the cause of your stress has nothing to do with work (if your internet is failing, for example) it is valid to mention what is happening and even make jokes about it. Be cautious about the type of information that you share with your candidate, though. Don't share family or overly personal problems to try to break the ice.

Look for reasons to smile during the interview and do so, that way your smile will be authentic.

If the candidate doesn't answer the questions the way you want, do your best not to show your frustration. A great technique is to “let the candidate lead the interview.” If you explore a topic that the candidate does not perform well on, try to identify a topic on which the candidate could perform better, this will occupy your mind and wipe the frustration off your face.

Is a coding exercise really necessary?

During the first 15 years of my work experience, I conducted many interviews. During that time, I never asked any candidate to perform any coding exercises. The vast majority of candidates who were hired after my interview performed very well.

From this experience, I conclude that a coding exercise does not guarantee the success of the interview, and the lack of one is not a factor in its failure. Why, then, are coding exercises a requirement in the tech industry now?

The answer is simple: the FAANG (Facebook, Amazon, Apple, Netflix, and Google) companies. They have had an incredible marketing projection over the last 20+ years. Almost everyone in the world recognizes these brands and knows what each one does. This has caused these companies to receive many more job applications that they can handle. The practice of requiring coding exercises emerged to reduce the number of potential candidates. This practice spread rapidly in the tech industry. At the same time, multiple platforms like leetcode.com and geeksforgeeks.org emerged to meet the demand of programmers who wanted to improve their programming skills.

For the above reasons, coding exercises are now standard practice in tech interviews.

Unless you are interviewing candidates for one of those FAANG companies, a coding exercise can sometimes be more harmful than helpful, particularly if done incorrectly. Typically, the interview coding exercises conducted by FAANG companies are quite complex, since their primary goal is to narrow the candidate pool, not just evaluate a candidate's logical abilities.

I have learned that these coding exercises can be useful when the level of complexity is reduced. They have helped me identify candidates with significant deficiencies in programming, and candidates with great logical skills. The trick to using them effectively is simple: the complexity of the coding exercise for an average tech company should be much less than the complexity of an exercise applied in FAANG.

If you are preparing for an interview with one of the FAANG companies, I suggest searching the internet for the term “Blind 75.” The resulting list of questions covers the skills to develop to increase your chances of success in a coding exercise required by these companies.

If you are NOT interviewing for a FAANG company, however, I recommend (still) applying a coding exercise, but the complexity of the exercise should be less. Asking the candidate to solve a simple number ordering algorithm (using a classical algorithm or a predefined method in the language API) or create a local cache will be more than enough to know if the candidate really has programming skills or not.

Always remember: if you are not interviewing for a FAANG company, your goal is to find reasons to hire the candidate, not to reject them.

FAANG companies have a huge list of candidates. The remaining 99% of tech companies, however, experience the opposite situation: difficulty and high cost associated with finding the desired candidates and convincing them to work for these companies. Don't make your HR colleagues' jobs harder by applying an unnecessary level of difficulty.

One additional point if you are interviewing for a FAANG company: I have found that any moderately capable programmer can successfully pass the FAANG exercises if they spend enough time practicing their coding. Let's be honest: complex coding exercises will hardly be used in daily work since there will always be a method in the API of any language that solves the problem. In fact, writing an algorithm to solve a problem that can be solved by a standard API method would be bad practice.

That is why, although any programmer can solve the problem optimally given enough time, the candidate will need to have had enough time to practice coding shortly before the interview to be able to solve the problem in the short window of time that an interview offers.

The interviewer must understand, then, that a candidate who is currently unemployed or a recent graduate looking for their first job will be much more likely to successfully pass a difficult coding exercise since they had more free time to practice the exercises. For a candidate who is currently working on a project, it will be much more difficult to find the time to carry out this preparation when their entire workday is occupied with tasks related to their current job. A candidate who is currently working will, on average, perform worse than one who is not if the coding exercise is too complex. This does not mean that the candidate is not suitable for the job. If a candidate passes the coding exercise with flying colors, it may indicate one of two different possibilities:

1. The candidate is quite good; or

2. The candidate had more time to practice (and sometimes even memorize) the exercises.

Consider this when making your final recommendation and preparing for your interview.

Conclusion

To summarize, the most important points in brief are:

1. The interview should be a conversation, not an interrogation.
2. Since you conduct an interview from a position of power, use that power in a measured way.
3. Look for good reasons to hire the candidate, rather than finding dumb reasons to reject them.
4. No matter who you are interviewing, you can make any candidate fail. The universe of things we don't know is much bigger than the universe of things we do know. Don't be more strict than necessary.
5. Always allow the candidate to lead the interview, use the candidate's own answers to delve deeper into the topics.
6. Don't look for people who know, look for people with the ability to learn. In the long run this is the most efficient strategy — in terms of both time and money — for your company.

I hope that these tips will help you to be a more efficient interviewer and will reduce the number of failed interviews and increase the number of successful ones.