How to Lose Candidates: A Story from a Company’s Perspective

Figure 1: Photo by Dylan Gillis on Unsplash

Everybody knows that interviews are a crucial part of the hiring process. There are a lot of stories about how candidates fail the interview because they don’t know anything about the company or are not prepared for the interview. But there are fewer posts about how companies fail interviews and lose great candidates. I believe we should consider this topic from different perspectives, especially from the company’s point of view.

Let me tell you a story.

Step 1: Intro

Once upon a time, a company called B was looking for web engineers. One day, the People Operation department of the company found a candidate named K, who had 10 years of experience in the web development and leadership team, the last few years K helped in a few different teams. K had been researching new opportunities since their previous company had been acquired, and all engineers were laid off. For the company B K looked like a great fit, and they were connected.

📔 Before doing any steps, we should not forget the following:

Both a company and a candidate should do homework - learn about each other

📔 Companies fail here when they don’t check candidates’ CVs and waste time talking with unsuitable candidates. Each interview is a stress for people, so let’s have as few as possible. Talk to the people you want to. From my experience, companies do their homework better than candidates in this step. I often encounter candidates who need to be made aware of the company and what it expects. If the candidate doesn’t know anything about a company, maybe you don’t want to have such a person in the team.

Candidate K and company B did their homework, and the first step went well. K had an excellent conversation with B, and they discussed everything about the company, K’s experience, and further steps. B clearly explained what they were looking for and what needed to be expected. Moreover, company B described its values and their vision of engineering growth. At the end of the call, B explained the whole process of the interview and which steps K may expect.

Step 2: Technical Task

Company B was happy with Candidate K, and they moved forward. Based on company B’s policy, the candidate should complete a test task.

📔 I’m not sure that the test task makes sense today. What does the company want to understand? How the candidate writes code? — you have GitHub, solve a problem — you don’t know if the candidate does it themselves or if someone helps them.

Skip useless steps. Save your time and time for the candidate who will be more satisfied with the faster process

📔 But if your company’s policy is to send a test task, be sure that the candidate gets precise requirements. Here companies make a mistake when they think a candidate understands the task as a company does. It’s called the Illusion of Transparency.

📔 When working on a project, it’s crucial that both your expectations and the candidate’s understanding of the task are 100% aligned. To achieve this, the task should clearly outline the context, expected results, limitations, and what the candidate can and cannot do. Keep in mind that a candidate can’t read minds! If there are any uncertainties, encourage the candidate to ask questions. But even after answering any questions, there may still be minor points that the candidate may have a false-positive grasp of.

Anything the candidate does outside the specified requirements should still be considered a correct solution as long as it aligns with the overall project goals

In this step, our candidate K was tasked with creating a simple web service to parse text into phrases. The task specified that no custom parser was necessary and that the use of any library was acceptable. The company provided an empty project with predefined default libraries.

K conducted thorough research and chose the best parser library available. However, during the development process, K encountered an issue with the “parser” library and took it upon themselves to find a solution. They patched the library, left a link, commented and made the necessary changes. In addition, K decided to change the default libraries to more suitable ones, added a connection to the DB, and added tests to the project, which looked like a wise choice given that it was a web project.

After double-checking K made a Pull Request and began to wait. In a few days, K received an answer.

Hello K.

Thank you for submitting the technical task. Unfortunately, we cannot proceed with the next steps.

Here is the feedback from our engineers:
* You created a custom parser, which you should not do. 
* You did not use default libraries for the tests
* You changed the DB library that is used for the DB connection

Thanks, and have a good day.

K was surprised because company B had not mentioned any such limitations in the task description. How should they understand it?

📔 Here we have one more mistake on the company’s side. When someone reviews a technical task, it is essential that at least a Senior Engineer does it. It is highly important that the engineer understands what happens and what a very new engineer has made. Ideally, it should be someone who has previously mentored and helped junior- and mid-engineers, and of course, who understands the task and what is worth having there. In any case, the company should always have a call with a candidate to discuss the technical task. It is possible, and even preferably, to have it together with the next step: a technical interview.

Find a proper person to do a review and don’t leave the test task without a discussion with a candidate

To rectify the situation, K decided to answer and explain the situation. Unfortunately, there were no further responses…

📔 Company B lost the candidate. We won’t say whether K can or can’t pass other steps in the interview, but the reasons for rejection sound weird..

⚠️ Here is one available scenario. Let’s consider the more positive case where K passed the technical task.

Step 3: Technical Interview

The next obvious step for both the company and the candidate was a Technical Interview call.

K and company B scheduled a call to discuss technical questions and problems. K was discussing different development approaches, how to work with a team, and even arguing with the technical guy from B. They had a friendly technical conversation covering all areas. Of course, K was well prepared, having read books and reviewed information that could have been missed. The same company B read K’s CV and prepared questions and a plan for the technical interview.

📔 I would not stop on this a lot since everyone has heard about technical interviews and how smart and stupid they can be. Over the past years, I’ve done dozens of different types of interviews, and from the company perspective, I would recommend not forgetting to check CVs. You are reviewing the candidates just as the candidate reviews the company. From the candidates’ side, I can add — be prepared as you can and stay calm.

📔 Have a friendly conversation. You should not try to prove that you are a better engineer than the other — you are looking for a teammate. Imagine you are already on the team, and you both solve the problem. Communicate and collaborate. At the same time, it doesn’t mean the interviewer should solve every task; it means the interviewer may help the candidate be part of the team. Don’t forget about the Illusion of Transparency*.*

Be in a team with a candidate

Figure 2: Photo by Helena Lopes on Unsplash

Step 4: Final

In a few days, K got an email saying that company B was happy to proceed to the final stage and schedule the final call. K and B had a nice chat with the Director of Engineering, where they discussed the company’s business and a future project one more time, including what K might expect and what the company was looking for. At the end of the call, K was offered the job.

📔 In this final step, it is crucial to let the candidate know how they performed during the interview process. Thank them for the time and effort they have put in. Literally, the company has the last chance to check the cultural side. Be polite and clearly envision what the new engineer will do. Do not withhold any information. Remember, you are looking for a new teammate.

I haven’t added it to each step, but the company should appreciate the time and make space for the Q&A section with the candidate every time.

Some studies have shown that IT companies can lose as much as 60–70% of their candidate pool between the initial application and the final hiring decision. However, this can vary widely based on the specific company and job market conditions. Therefore, it is essential to keep this in mind and not forget the value of each candidate. Never.

And finish the story I’d like with the following:

It is up to you to decide what is real and what is fiction here

Figure 3: Photo by 愚木混株 cdd20 on Unsplash