Interviewing developers: what I learnt

Hiring is about finding a common agreement between two parties: one provides work and salary and the other provides knowledge and time

Introduction

Hiring candidates is an integral part of the life and growth of any company and whether it’s a start-up or a well-established company the way employees are hired doesn’t fundamentally change: they get assessed through interviews. Different companies of course follow different interview processes, with some being satisfied with just one interview while others require multiple stages.

In many cases, new hires are intended to replace leavers but in some cases, companies go through periods of expansion that require more commitment to finding the best talent for all levels of experience.

Having been involved in one such expansion-focused hiring initiative on behalf of Version 1, I ended up interviewing a lot of candidates for software development roles and learnt (at least to some extent) how to interview people and I’ve come to a point where I believe there’s a lot of value in sharing this experience so that others can benefit from the lessons I learned.

Do you want to grow your new hire or do you need a full-grown one? This is the very first question you will need to ask yourself.

Before the interview: Keep in mind the seniority you want to cover

Interviewing a junior staffer is completely different from interviewing a senior staffer. While your expectations for a junior are that they will be able to handle basic tasks with a varying degree of supervision, your expectations for a senior are much higher. In the case of a software developer, for example, you will want them to be able to make architectural choices as well as plan work and teach best practices to other personnel.

The difference in skills breadth between the two figures means that when interviewing a senior, you want your questions to quickly tell you whether they have the technical knowledge you need so that you will have enough time to ask questions related to the “soft skills” (leadership, management, negotiation) that you need them to be able to cover at least partially. When interviewing a junior, on the other hand, you will want to make sure that they have problem-solving skills and some technical knowledge, as they will be crucial in the field.

Senior questions focus:

• Leadership, estimation, and negotiation questions
• Best development practices to teach others
• Ensure they have broad experience (architecture, problematic situations, types of requirements)

Junior questions focus:

• Basic questions on the technical skills you need for the project
• Make sure to verify they have an understanding of specific skills (for example: compute the output of a simple SQL query with “join” and “order by” clauses)
• Make sure to test problem-solving in general (for example: explain the logic you would apply to a function that determines if a number is prime)

Knowing what you need from the candidate is critical, much like knowing what tools to use for woodworking.

Before the interview: Determine what aspects of the person you are trying to assess

The first things we think about when trying to prepare our questions for a software developer are usually the language or technology we expect the candidate to use. While this can be important it’s neither the only metric nor necessarily the most critical aspect to assess.

In reality, among other things, you will need your new hire to:

• Fit into an existing team
• Be able to communicate effectively with others
• Provide you with their views and insights on various issues
• Maintain a productive behaviour
• Be capable to solve problems
• Be able to see beyond the small task at hand (you want them to see the “big picture”)
• Be able to negotiate with, manage and possibly lead other people

This means that when interviewing you also need to ask questions meant to understand their personality and dispositions.

For example, one could assume that a person capable of answering every single minute technical question is bound to be a great asset to the team and therefore fit a high seniority position but if that same person is not adept at training less experienced developers, talking and negotiating with different stakeholders or set sensible priorities you may end up introducing an element of instability in a key position of your team.

Before getting into an interview try to determine what aspects of the candidate you want to assess and prepare related questions as well as expectations for good and (especially) bad answers.

Behaviour question example:

Q: Did you ever have to deal with an unreasonable co-worker or client? How did you handle the situation?

Possible good answer: I tried to ask their point of view and find a compromise, I tried to involve another colleague to get an impartial point of view, and eventually I had to go to our manager/lead to settle the matter.

Possible bad answer: I went to their manager and complained.

To interview one person you need one set of questions, to interview many you should still need only one.

Before the interview: prepare a baseline of questions you will ask everyone

When you are interviewing a small number of candidates (say: to fill one specific role) you can afford to tailor the interview around the role and individual candidate completely. When you are involved in a larger hiring campaign, on the other hand, you need to consider your other responsibilities and time constraints.

What the above means, in essence, is that you will need to find a way to exercise some “economy of scale” that allows you to minimize the time spent preparing for the many interviews you’ll be involved with. A very good way is to prepare a baseline of questions that both you and your colleagues will be able to ask.

Having such a baseline of questions not only will save you time but interview after interview, it will allow you to learn how to recognise an excellent answer from an average one, which will both help you select the best talent and learn from those you interview (yes, you will on occasion learn from their answers!). Furthermore, a carefully selected baseline of questions will allow you to expand further on related concepts and matters, thus laying the foundations for an interview that feels like a conversation rather than an interrogation.

Baseline questions example:

• What is a singleton? (can lead to spring-boot, web applications, threading model)
• What is an abstract class and how is it different from an interface? (can lead to language-specific questions, inheritance/composition, SOLID)
• Did you ever hear of the concept of “truthiness” in JavaScript? (can lead to TypeScript, general web development)
• How would you estimate a complex task? (can lead to analysis questions, NFRs, testing, individual experience)
• How do you avoid becoming a bottleneck when managing your team? (this can lead to a discussion on leadership styles)

Interviews can be stressful for candidates, but stress tolerance may also need to be assessed.

During the interview: put the candidate at ease… maybe

Interviews are intended to understand whether someone is “fit” for a certain role. This implies that the interviewer has a lot of control over the process whereas the candidate is at an implied disadvantage.

This implied disadvantage puts a lot of pressure on the candidate and depending on experience, covered roles and personality we tend to respond differently to stressful situations. Some people will manage stress very well whereas others will see their minds go completely blank even though they would normally be perfectly capable of answering your questions in a satisfactory way.

Pressure and panic can be a big problem during interviews as they effectively prevent assessing the viability of candidates from a technical standpoint… but will also tell you whether they can handle stressful roles.

This means that depending on the role you’re interviewing for, you may either want to put the candidate at ease by asking questions they will naturally be able to answer by virtue of who they are and what they do on a daily basis (asking a description of their current project and role, for example, should be an easy question) or keep the pace regardless of stress levels to see how they react. The caveat is that you need to know what the role is going to require of them, as otherwise, you’ll just risk losing talent needlessly.

Example criteria:

Junior and mid-level candidates: try to ease the tension whenever possible

Senior candidates: try to ease the tension but see if they can snap out of panic on their own

Team Leadership candidates: they shouldn’t be tense at all; they should be confident and assertive, to begin with

Although hiring is not a scientific process, objectivity is still critical and emotions should be kept in check.

During the interview: keep yourself in check and be objective

Most of the interviews you will hold will go perfectly fine. Most candidates will be at least viable, some won’t. If you hold a lot of interviews, however, sooner or later you will find people who either cheat or have a bad attitude.

In one instance I had a candidate trying to look up his answers on Wikipedia and subsequently trying to put together some semblance of answers. Once I figured that out, I essentially had two options: expose him or continue the interview. In another instance, I had a candidate answer “I’ll have to refer you to the documentation for that” (a particularly poor choice of words if the intent is to say “I don’t know”) twice for basic knowledge questions that the vast majority of candidates answer without trouble regardless of their experience.

For the cheating candidate the way I handled it was to dig deeper into their hesitantly delivered answers and collect the appropriate notes on their real understanding of the matter. For the “bad attitude” candidate I continued with my other questions — none of which need to go through any documentation — once again collecting notes based on their answers, including notes on their behaviours during all stages of the interview.

The bottom line is that no matter what happens the best course of action is to continue with your questions and conduct the interview till the end, using the notes you collect to drive your decision, which needs to be as objective as possible.

Best practice:

• Collect notes objectively based on the questions you planned to ask
• Postpone any subjective response till after the interview: it might just be a poor choice of words after all

The economics of hiring should not factor into your decision as a technical interviewer.

After the interview: economics is not your problem

The decision to hire a person is the result of a number of separate assessments including technical, personal and economic. The amount of money people ask is of course critical to the final decision but you need to understand that it may not be relevant to you.

In a technical interview, your role is to decide whether candidates fit from a technical standpoint, what degree of confidence you have in your assessment and whether they are ahead or behind other candidates. Once you know “how good” a candidate is, you can recommend whether they’re hired or not but you won’t be the person making the final call.

Using knowledge of their financial demands to make a judgment call on whether a technical interview was successfully passed or not is a bad idea as it skews your technical assessment. For example, you may be inclined to say “no” to an excellent candidate that seems good but in your view asks too much money but what if that amount is negotiable? As a technical interviewer, you won’t be involved in that negotiation part: the recruiter will rely on your yes/no assessment assuming its basis is purely technical and will deny the job to the candidate regardless of their willingness to negotiate. Furthermore, depending on company policy, your “no” in the present may automatically translate to a “no” in the future, so by making an economic assessment during a technical interview you risk losing talent needlessly and persistently. The opposite is also true: you may say “yes” to a mediocre candidate that reports asking for a very low salary to you but negotiates a much higher salary with the recruiter in a subsequent step and that’s even worse as you may have to reject the candidate during his probation period — with all the indirect costs — or let him slip through the cracks and keep an unproductive employee.

The main point here is that separate, independent assessments should be made on the critical indicators that will determine whether a candidate should be hired or not. Your role as a technical interviewer is to assess a candidate from a technical standpoint, not an economic one.

Best practice:

• Assess candidates solely on technical aspects

Taking structured notes is critical to ensure consistent results and objective interviews.

After the interview: capture the outcomes in as much detail as possible

Interviewing takes time. Once it’s finished it will be very tempting to simply say “yes” or “no”… but reality comes in many shades of grey and you need to remember that. Furthermore, decisions may get delayed and you may be asked after some time to decide between two candidates so you will need to recall the two interviews or you may end up being assigned the new hire and you will want to remember their strengths and weaknesses during the interview.

As a result of the above, you want to have a methodical way to collect feedback on all the questions you ask and you may also want to collect notes on anything they said that captured your attention, whether it’s in a good way or a bad one, as it will help you remember the candidate later on.

Best practice:

• Give each answer a score (example: excellent/good/average/bad/awful)
• Write down the bottom line of each answer the candidates gave to act as an explanation of why that answer was good, bad or average.
• Capture in written form any detail that made an impression on you, whether good or bad
• Capture in written form some general context around the candidates that may help you remember them

Your role is to make a decision on hiring. “Maybe” is not a decision.

After the interview: there is no such thing as “maybe”

The objective of a technical interview is to determine whether the candidate is viable or not. To this extent, those who then need to decide on the hiring need you to be confident in your yes/no assessment. As a result of this, a “maybe” assessment is a big problem and you should try to avoid it as much as possible.

Still, on occasion, you may of course find yourself being very split on the matter.

For example, you may find that a candidate for a senior position is not good enough to be a senior but would be good for a mid-level role. In another case, you may find that a candidate applying for a senior developer role had a long career that moved them away from a purely technical role to the point where they would be brilliant in covering a non-technical role you know could help the team but not as a senior developer.

In both cases, you must strive to give the recruiter the tools needed to interpret your “maybe” assessment so that the underlying decision can always be clearly made. In both examples, you may state clearly that your “maybe” can turn to a “yes” if the candidate accepts a different role or “no” otherwise.

Best practice:

• Avoid unclear (“maybe”) assessments as much as possible
• When you can’t avoid a “maybe” state clearly what would turn it into a “yes” or a “no”

If you are taking an interview, try to relax and be honest.

For the candidates: come prepared, be honest and don’t panic

While the focus of this article is giving advice to the interviewers, there is also some advice that I would like to give candidates and while it would require a dedicated article to elaborate on it, there’s no harm in providing a few bullet points.

Come prepared:

• Try to remember who you’re interviewing with, look up the company, what it does and what technologies they use (it doesn’t matter if you never used them)
• Prepare some questions for the company based on what you want and don’t want for yourself: ending up in a company you don’t like is a waste of both your and the company’s time so use the interview as an opportunity to assess the company as well
• Try as much as possible to enter the interview with a productive mindset: interviewers have a lot of questions they want to go through and in order to do so they need your answers to be concise and on point. A productive interview will see you answer questions in a clear and reasonably concise way to make the interviewer understand you get the gist of it while leaving space to elaborate on aspects that matter to them

Be honest, as nobody knows everything:

• Interviewers are prepared to accept that you may not know some things they ask, so just admit when you don’t know something or when you are unsure of an answer you are about to give. Also, don’t discount the possibility that they may want to see how you would answer something you don’t know.
• Interviewers prepare their questions beforehand based on their own knowledge so they will immediately know when you try to make up an answer without prior knowledge. By attempting one such feat you are very likely to make a bad impression on them, so don’t do it.

Don’t panic:

• Interviewers know that the interview process can be very stressful for candidates and are prepared to deal with it. The ideal interview for them in most cases is a friendly talk between peers where opinions can be shared and personal views emerge clearly… so try to relax: things go the way they go.

Bonus:

• Be strategic. Taking interviews is a learnable skill. If you don’t have experience taking interviews, start from the companies you’re the least interested in and don’t be afraid to say no to the first two or three offers: you can use them to try and understand what questions are asked more often and how much money your current level of expertise is worth.

Planning and preparing for interviews are critical to their success.

Conclusion: preparation is key

Interviewing is in many ways the perfect incarnation of “first impression” and its problems. As an interviewer, you are given a very limited amount of time to understand whether a candidate is going to be a valuable addition to the company or not and report this outcome. This requires you to enter interviews knowing as exactly as possible what you want, how to determine if the candidate has it or not and how to report the outcome in a structured and objective way.

The bottom line of all this can be summarised in just a few bullet points:

• Know what the expectations for the role are and tune your questions accordingly
• Prepare a baseline of questions you’ll ask all candidates
• Make notes and capture information/outtakes in a structured way
• Make your assessment based solely on the aspects you are meant to assess
• Bonus: make sure 2 people are conducting interviews at all times. It helps with objectivity and can prevent other problems
• For candidates: come prepared and try to relax

All the above bullet points, then, can be further summarised in one single statement: preparation is key.

All images courtesy of burst.shopify.com

About the Author:
Filippo Possenti is a Java Technical Lead here at Version 1.