It is a personal blog. The views and opinions expressed in this article are those of the author. They do not represent people, institutions, or organizations that the author may or may not be associated with in a professional or a personal capacity. All information is provided on an as-is basis.
Technology companies are growing and need new personnel. In addition, there is natural attrition in the companies. In a highly competitive market, people are leaving for various reasons, and these needs also have to be met through hiring new employees. Therefore, searching for, selecting, and hiring new co-workers are always a must – it is a standard business for every company.
Companies usually conduct interviews to assess and select their future colleagues from the pool of aspiring candidates. Even though it is the standard practice, there are a lot of controversies with this approach. You can see many social media posts about harmful practices, wrong questions, and ill-treatment of the candidate. One infamous example was when Google asked candidates in their interviews to estimate the number of golf balls that could fit in a bus.
Most of the people having a voice on social media express their opinion that this was total misuse. I tend to see some merit in using such questions, but, as often, personal opinions are irrelevant. So instead of starting a debate about this particular question or similar questionable practices, I will focus on the purpose and the practical approaches we apply when conducting interviews.
I mainly rely on the experiences I gained when completing interviews on behalf of my current employer, but I believe there is nothing company-specific in this article.
When I write ‘we’, I refer to the whole industry or at least to a large group of companies that follow good practice and not specifically to my employer.
What is the purpose of conducting interviews?
Any company could hire a candidate without any prior filtering, but this could cost them a lot. Suppose the candidate does not fit the company or meet the criteria to be successful in a position. In that case, the company would have to pay the salary for the probation period, colleagues guiding the new hire during the onboarding process would invest significant time and effort, and other resources, like office space, infrastructure, heating, network, and so on, that also costs money. It is not a good practice for a company.
However, the money the company loses is not the main issue. Companies have profit and loss, and you can consider the cost of selecting the right candidate as an investment. The highest cost is not monetary, and it is not on the company side. The candidate is the one who would pay the real price for such a practice.
Most of the candidates have a safe job and solid position when looking for a new one. However, losing the place at the new job, getting sent away is a substantial personal burden. As a result, candidates may find themselves “in the street” looking for a new position. Not having a current job is hard to explain during the HR interviews. At the same time, the financial burden and the time pressure may also put the candidate into a hard-to-negotiate corner during the salary discussions.
No company should do this to anyone. If a company wants to hire you without proper assessment: run. Fast and far away.
The thorough assessments of the candidates’ skills, experience, and knowledge are at the other end of the spectrum. Some companies do that by giving out homework, completing full-day assessments filled with role plays, coding tasks, and using other similar techniques to evaluate candidates. The simplest and cheapest way to do an evaluation, however, is an interview.
A full-day assessment almost certainly gives a more reliable result, but it requires significant resources from the company. So, as usual in business, we should follow the Pareto principle and shoot for the cheapest good-enough solution. I will talk a bit later about what ‘good enough’ is.
Overcomplicated hiring processes may distract candidates. Imagine a senior developer who is looking for a new position. How many full-day assessments will they attend? To participate in such a selection, candidates may need to use a vacation day from their holiday budget, and they have to keep it secret at the actual workplace. If your competitor offers you a late afternoon interview instead, you will most probably choose that option.
There are pros and cons. We cannot tell what the best approach is, and certainly, doing interviews as a selection tool is not the imaginable best, but probably the best existing, and indeed the best we know. Nevertheless, it is the industry standard practice.
What is a good interview?
We do not need to complete the best interview in the world, as I wrote above. We have to complete one that is good enough. To say that, we have to know what we consider to be a good interview. We should have a metric that can tell us which interview is “better”.
Candidates often tell me: “This was the best interview of my life.”, even when my conclusion is not to recommend them for hire. Although a happy candidate is essential in bringing your company a good image, it is not the metric we usually look for. A good interview does not need to be enjoyable for the candidate. That is just an extra, a possible byproduct of a good interview.
An interview’s most crucial quality measure is to differentiate a fitting candidate from a non-fitting one. Of course, there are other criteria, like proper communication, politeness, non-disclosure, and conduct. These are all very important. Nevertheless, the primary goal of the interview is the selection.
When doing an interview, there are four possible outcomes. The candidate can be fitting or non-fitting, and at the same time, the interviewer recommends or does not recommend the candidate for hire. These are two dimensions with two values each. Each pair is possible, resulting in the four possible outcomes.
The recommended fitting candidate and the non-recommended non-fitting candidates are the most uncomplicated cases. These are the happy paths.
The remaining two cases, false positive and false negative, are a bit more tricky. The case when the interviewer does not recommend the candidate, although they are fitting, is theoretical. Those candidates do not get employed, and none will discover their fitness. In other words, we will never know when a candidate and/or an interview fall into this category. This case is theoretical in the sense that though it certainly exists, we will never see it.
When a candidate is recommended but not fitting is the costly situation we already discussed. When it happens, it will be clear for many people in the company who will manage the consequences and deal with the problem.
The solution for the situation is often to find a better, more suitable position for the person inside the company. It is done falling into the trap of the sunk cost fallacy. The people involved subconsciously feel the relative cost and burden of finding a new position without an existing need and actual vacancy. This cost is born to the candidate. Feeling responsible for the situation, they do not want to put that on them.
When the company has a good hiring and interviewing practice, it rarely happens. We cannot avoid such situations, however. It is not because of the unique nature of the interviews. It is a general measurement theory. Any decision can have four outcomes: true-positive, true-negative, false-positive, and false-negative. No decision system could avoid the false parts. They exist by principle. The only thing we can tune is to push the scale between the false outcomes. What do we want to have less? Is it the false positive or the false negative result which is less desirable?
At this point, you can tell that I am advocating against the false positive cases, which means that we have to design the interview decisions to avoid those even if we get more false-negative results.
This advocation is not general, though. It is only for the interview decisions. For example, a cancer screening system should be scaled towards favoring false-positive cases. I would rather choose a few days of panic until the repeated test annuls the false-positive result than die because of a false-negative result not detecting the tumor at an early stage.
The fact that we should favor the false-negative cases means that the technical interviewers should recommend hiring only those candidates they are absolutely sure about. When there is any doubt that the candidate is bad, they are better not to be hired.
Note that by doing so, you will filter out some candidates who are good enough but are not very good. You have your doubts not without reason. The potential loss is insignificant in sending away some of the candidates who would fit but are not “really good”.
Do we judge the candidate?
Avoid judging the candidate is extremely important. In the previous section, I deliberately used “good candidate” and “bad candidate”. In addition, I used an example (medical screening) that subconsciously compared candidates to cancer. If you felt inappropriate when you first read that, you are on the right track. If not, you have to think about why you did not.
We must respect the candidates.
Technical interviewers have to be humble. Maybe non-trivial at first, but we also must not evaluate the person, and we should not use expressions that may even unintentionally imply that. You cannot do that if you look down on candidates and you do not respect them. The respect has to be authentic. If it is not, you cannot hide it. So the first thing is that you should feel and show genuine care and then work on your communication.
It is why I prefer to use the word “assess” instead of “judge”. We assess the knowledge, skills, and experience of the candidate. We do not “judge” these, even though linguistically, it would mean the same. For the same reason, I usually talk about the position fitting the candidate and not the candidate fitting the position. Thus, when I say that a position is not good for a specific candidate, nobody will think that it is generally bad, even less that it is stupid or dumb.
On the other hand, the sentence “The candidate is not good for the position.” is heard and interpreted as “The candidate is not good…” The end of the sentence often gets lost in the communication or during the interpretation. It has to be carefully avoided.
Sometimes, I meet lead developers, senior, or even architect candidates who lack even basic skills in their current employment. Even though I feel the temptation to doubt whether their current status is well justified, I don’t. If a candidate’s current position seems to be a lie in the CV, it does not matter. Companies are different, and they need different types of people. There is no such person who is generally not fitting a role. To assess a person’s fitness for a position, you have to compare the person’s qualities to the role. Otherwise, you could plainly say that the candidate is ok but can not tell us for what.
Work with the Candidate
When conducting the interview, you work with the candidate. The candidate helps you, and you help the candidate. To get a clear picture and understand whether the position is really the dream position for the candidate is in your mutual interest.
It means that you can be absolutely honest with the candidate. You can tell them all the things that I wrote in this article. You can explain the aim of the interview, what the possible outcomes are, the recommended and not recommended decisions, and so on.
I usually devote 7 minutes at the start of the interview explaining the above. Of course, it is a bit boring after several hundreds of interviews, but every job has its downsides and upsides, and it is crucial for each candidate.
You can even explain that when candidates are lying or cheating candidates, it might be harmful. It helps when a candidate gets a coding exercise that is too familiar to them. A few times, the candidate proactively warned me that they had already met the task beforehand. So we chose a different one.
Coding Exercise
The above paragraphs are generally valid for all types of interviews and not specific for software development. For example, doing a coding exercise is specific to technical software developer interviews. However, most of the debates on social media are related to this practice. The reason for that is simple. It is very easy to do it wrong.
I would never recommend a candidate who cannot demonstrate the coding skills in an interview. After all, what is the value a developer can deliver who cannot code? It is more questionable if a solution architect needs to code, and I would not get into that this time. I have my personal opinion about it, but it is irrelevant. Maybe I will discuss it in a different article.
I have met some developers hired from different vendors working in the same team for our clients who could not code. We never complained, and we did the extra work instead of them. The client personnel could see who did what and came to their conclusions most of the time. I will also not name the vendor ever. Let’s just say that these developers stay afloat in the industry until they find a different job and become BAs, PMs, or car salesmen. I accept them as a fact of life, but I do not accept hiring one in my workplace. In conclusion, we should agree that some performance measures are needed to assess the coding skills as a work theory.
An excellent coding exercise helps assess three things:
- The algorithmic thinking of the candidate.
- Coding skills and the muscle memory of the language we test. In my case, it is Java.
- Communication skills.
Each of these can easily go wrong, and hence negative stories quickly get to social media.
It is challenging to assess algorithmic thinking. It is much easier to test if the candidate can solve one specific problem or complete a task. That way, the assessment quickly degrades to testing if the candidate knows the particular algorithm. Even though I believe that learning and understanding the most important algorithms and data structures (quick sort, balanced trees, graph traversing) is vital for a developer, many developers do not possess even the fundamental computer science theory. I can also accept that there is no value in knowing many algorithms by heart. It is better to have the skillset to create the algorithm when needed.
To avoid testing the candidate knowing the task instead of solving it, I have several of them you cannot find on the internet. (Fun story about that at the end of the article.) We also discuss the solution while the candidate forges the code step by step. I realize if the candidate has known the algorithm beforehand.
You can test the coding skills easily. Many typical coding practices show off an inexperienced coder.
You can spot old coding constructs that we are not using anymore as the language (in my case, Java) develops. I sometimes see explicit type boxing, which we do not use since Java 1.4 Junior developers tend to compare a boolean value with ‘== true’ or write an ‘if’ statement and return ‘true’ and ‘false’ literal values from the execution branches. Some developers make mistakes, like indexing a ‘String’ as if it was an array.
As an interviewer, you should interpret those with a pinch of salt. The interview is not a normal coding environment. It is much more stressful, and such mistakes are many times caused by stress. The technical tools are usually less advanced than the usual IDE, with less support for code completion, syntax checking, and so on. Do not expect the candidate to know all the JDK API calls from the top of their head.
You can also check communication skills. For example, some candidates blamed me for presenting unprecise, even sloppy task descriptions. They were surprised when I told them that I was aware of that. It is to test if they clarify the task before making bold assumptions and just immediately start coding. Most of them do.
The coding exercise is the most challenging part of the interview. Not for the candidate, though. It is for the interviewer. It is a task that the candidate has to do together with you. If you, as an interviewer, see that the candidate is working on the coding task alone, you are doing it wrong. If you work together, then it is good. It may not be perfect, but most of the usual pitfalls you have already avoided.
Giving Feedback
At the end of the interview, you will know whether to recommend or not to recommend the candidate. If you don’t know, if you are not absolutely sure, then you should not recommend the candidate. I wrote that you must not recommend someone you are not sure about.
The recommendation, usually along with detailed analysis, is the primary outcome of the interview. There can be, however, another valuable byproduct. You can give valuable feedback to the candidate.
Interviewers seldom give feedback about the interview to the candidates, and this is not a good practice. I do not advocate giving feedback no matter what because it is a double-edged sword. If you provide feedback in the wrong way, it may cause a lot of harm to the candidate and the company. Providing valuable, thoughtful, and relevant feedback required some special skills.
Good feedback emphasizes the candidate’s strong points that they can build on and highlights the things that they can improve and that may result in enormous benefits.
The most benefit is evidently for the candidate, but it is also valuable for the company. Getting detailed feedback is always an invaluable help to better ourselves. Good feedback, however, is also beneficial for the company. Even if rejecting a candidate is the correct conclusion, a blatant and unexplained refusal may induce bad feelings towards the company. Feedback can mitigate this risk. Feedback explains the reasons so that the candidate can learn the reasons along with suggestions for improvement. Again, you can emphasize that the refusal is not a judgment; it solely recognizes the incompatibility between the candidate’s skills, experience, or knowledge and what the company requires in a specific role.
You do not know each other. Thus, you have to put a lot of emphasis on the good things that the candidate can build on. You can also explain that the feedback is limited as it is based on a 60-minute interview only.
Some candidates challenge some of my statements during the feedback. It is pointless from the feedback point of view. If I made a mistake, I misread the candidate in some aspect; they can ignore that part of the feedback. Some of the comments may likely be wrong due to the limited nature of the session. At the same time, I give feedback after the decision. It would be best if you did not change the decision based on any feedback debate. Even though I am usually lenient with candidates arguing about some points of the feedback. It reveals a lot about their personality that I can include in the subjective part of the interview record, and at the same time, it helps them vent their feelings.
I had candidates referred to our company by his friend I rejected but sent away with friendly but honest feedback.
Summary and Fun Story
Navigare necesse est. Doing interviews is unavoidable. Vivere no est necesse. Doing good interviews is difficult. In this article, I wrote about some aspects of the interviewing. There are other aspects that I did not discuss. Those I may address in a later article. I also know that many aspects of this topic are opinionated. You are welcome to comment, rant, criticize and tell the truth as you feel fit.
I promised you a fun story, so here it is.
Once I interviewed a candidate who was not outstanding. He had several knowledge gaps related to basic Java. He knew a few things wrong and was a bit stubborn. His coding skills were also less than what we required. When I ended the interview, I asked him if he wanted feedback. He said no, and disconnected the communication. (We usually do remote interviews using IP communication tools, like Zoom, Teams, Skype, etc.)
He immediately wrote an eMail to the talent acquisition team claiming that I was asking him wrong; I did not accept his correct answers and stating that I did not know Java. He also wrote that I was giving him a coding task that anyone can find on the internet, and I did not accept his correct solution because I did not like him. Even though he did not agree to video recording, the coding exercise does get recorded to crosscheck. I did not doubt that the solution was wrong, but his statement that I allegedly copied the exercise from the internet bothered me. So I googled some of the sentences of the task. I could find it on a site along with a wrong solution he also provided. It was word by word the same, including a typo. So you can guess who was copying from whom.
Your coding exercise tasks leak out. So you have to replace them frequently.
Published on Java Code Geeks with permission by Peter Verhas, partner at our JCG program. See the original article here: Why and how do to do technical interviews? Opinions expressed by Java Code Geeks contributors are their own. |
