TOP mistakes of tech interviewers

Over the past 2 years, I have conducted many technical interviews, but after the article by @AlfaTeam, I thought for a long time whether I had something to say or whether it was better to remain silent. In the end, I decided to describe the typical mistakes of interviewers that I did not notice before, but began to notice after this interview marathon.

Introductory

  • Venue: Fintech galley

  • Given: 1 technical stage and 1 hour of time.

  • Expected result: 4 grade options and general recommendations for departments where the candidate might be suitable.

There are many tips on the Internet about selecting specific people for specific places. Here we will consider the situation of stream interviews, when you write reviews like on a conveyor belt, and then people are assigned to random departments with typical tasks for uniform slapping.

Standardization of approach

  • a step-by-step guide is needed so that the process is approximately the same for different interviewers;

  • need a list of typical questions and tasks;

  • a standardized outcome questionnaire is needed;

Thus, whoever conducts the interview, its quality will be approximately the same level and the feedback from Petya, Vasya, Masha becomes more unbiased. All participants have the same +/- ruler in their heads.

TOP mistakes made by interviewers

Reads questions in order, as if during an interrogation

There are no interjections, no jokes, no ease of conversation. It feels like a robot is leading the conversation. This creates an unpleasant impression. If you can't get out of this mode right away, you can prepare a list of discharge phrases to try to insert into the dialogue. For example:

  • “Yes, that's true, but what do you say about…”

  • “Yeah, there is such a feature, but I had to deal with….”

  • “yes, why not, can you also say a few words about …”

About two years ago, during an interview at Tinkoff, I came across two such robot guys. As a result, in the middle of the interview, I simply interrupted him, saying that I was not particularly interested and we could not waste time. This point of the drive often goes together with the following.

Knocks out a specific answer or solution

Picks on minor details (like a missing comma), even if he understands that the solution is generally correct. This is bad, because few people will guess the wording intended by the author and it will not reflect the person's real knowledge on the issue. For example:

  • Yandex interview. The task is about some tree traversal. In general, everything is ready, but the interviewer has two points: “should start” and “cannot debug”. The guy got mad, and we spend 30 minutes looking for a typo (missed a comma). Despite the fact that I agreed to just skip the task and take the next one, so as not to waste time. It was like some kind of OCD attack.

  • Another similar case happened a year later, in another place on a binary search task. There, the interviewer himself started looking for a typo and debugging, because he did not understand why the solution did not pass one test, although he saw that it was correct. We spent 15 minutes (the +/- sign was mixed up).

Questions on one topic in depth for the entire allotted time

Here is my employer's problem. We have one technical stage, and we have to assign a grade to the candidate. If you always dig deep into one topic, it is impossible to understand the grade, because it assumes a balance of knowledge on completely different topics.

VK or Yandex can allocate one of the N stages to analyze specific skills in the area of ​​interest to them. For example, in VK I had two interviews, at one of which we spent an hour writing regular expressions, and at the second we spent 1.5 hours analyzing methods of compression and optimization of code. This was normal, since there are many stages and they are looking for a narrow specialization. But if you need a generalist in some typical department of the galley with a fixed grade, then you simply will not be able to say whether he will be able to “write acceptable code on average” or not, adhering to this interview tactic.

Ends on a negative note, leaving a bad taste in the mouth from the process.

This is an important point that many people do not understand. There are three factors:

  • from the applicant's point of view, he is experiencing stress;

  • from a psychological point of view, the last emotion remains the most vivid in memory;

  • from the point of view of the company’s HR brand, it is beneficial when applicants leave on a positive note, regardless of the result;

In addition, sometimes you come across a chatty applicant, and if you ask a couple of open questions about life at the beginning of the interview, it is not a fact that he will answer relatively briefly and to the point. Often such a conversation simply eats up 20 minutes of time, and then not every interviewer will be able to smoothly lead it into a technical interview.

I have repeatedly observed a strange abrupt transition, when in the middle of a leisurely dialogue a person switches on robot mode, realizing that it is necessary to urgently ask a technical question, which at this point may not be related to the topic of discussion at all. Therefore, it is better to stick to the sandwich model (positive-negative-positive). Example:

  • we start with easy short questions and tasks
    After five to ten minutes, the person relaxes as he answers. He becomes comfortable with the process going on, and we begin to increase the difficulty a little.

  • then we take him to complex questions and tasks
    The candidate will most likely drift. The middle of the interview will be the most negative part and will take the most time.

  • 20 minutes before the end we move on to general questions
    We talk about life, past projects, ask open questions and some theoretical digressions. The applicant will get the feeling that he may have drowned, but not completely. It seems like he told something. It seems like he swam up and ended on a positive note. In addition, open questions at the end protect us from talkative candidates.

Doesn't ask about interesting projects

This mistake occurs when the interviewer strictly adheres to the methodology and cannot conduct a free dialogue. The question about “home” and “interesting” projects insures us against the case when we missed some super important fact in the chain of questioning the candidate. For example:

  • a candidate for 4 years at Sber has been writing a JSON translator and it has already become a muscle memory job;

  • in his free time he works on his ML project on github for 1000 stars or writes shaders for the Minecraft mod;

One variation of this trap is when the interviewer is strictly focused on the candidate's last job and does not want to know about the candidate's other experience.

Picks up a challenging task

When I first started interviewing, I tried to find the most hardcore tasks so that only super cool specialists would pass. But this approach does not allow for an increasing grade, since the answer is binary: either solved it or did not solve it.

Then I got one of Yandex's interviews, which ended in 20 minutes with a super simple (as it seemed to me) task. I asked the interviewer why he gave such an easy task? And he answered that it was quite normal, quite mundane and more than half of people fail on it or start writing nonsense. After that, in my interviews, I tried to give simple tasks and if the person solved them, I simply added a condition. It turned out that this is a really cool approach to lead in one direction or another on the fly (as the answers are given) or to cut short a drawn-out solution (if the candidate started to stall) without upsetting the candidate.

For example, let's take the super old problem of outputting numbers to the console in order:

for (var i = 0; i < 2; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}
  • we prohibit touching var;

  • prohibit writing closures (IIFE);

  • we prohibit passing the 3rd argument;

  • we ask to remove for explicitly and call it N times somehow else;

  • and so on.;

With such small tasks you can not only flexibly assess the depth of each topic, but also get a lot of lulz. An example of a solution to such a simple task from “Signor Pomodoro, 12 years of experience”:

404, so to speak

404, so to speak

Expects that the applicant's experience in the resume is equal to his knowledge

Sometimes people work for a long time, but their projects were as typical as possible (form-slapping and CRUD-slapping), and they themselves did NOT take anything more than was necessary for work (reading articles, books, watching videos, home projects). As a result, the Middle+/Senior Yandex developer gives this way to remove duplicates from an array:

So don't skip “trivial tasks” just because you saw “20 years of experience solving algorithms at Google” on a candidate's resume.

How to find areas of competence and assess horizons

I offer the candidate a quick yes/no question and fill out the following table:

Direction

Having experience

Layout

Mobile development

Development for TV

Assembly (Webpack, Gulp, Maven, etc.)

CI/CD (Nginx, Jenkins, Docker, etc.)

Canvas / WebGL

Working with graphs/statistics

GameDev

Working with sound

Creating a UI Kit

Testing

Localization

Parsing, mapping data

Anything unusual?

Next, I select a couple of points in which I had experience and ask a few questions in depth (but still superficial). For example, for a UI kit:

  • did you implement a table or Select?

  • Are there any points that are important?

  • let's come up with a list of typical props?

  • let's come up with a list of features for the table?

As a rule, half of the candidates simply worked with some library and did not delve deeply into it. And those who did will quickly tell about the pain and suffering, or some design error that they made and realized it at the very end.

General open-ended questions work well, such as: “how to speed up loading?” or “tell me something about security?” It is advisable to have a list similar to the one above. If the candidate has chosen a certain direction during the blitz, you can immediately get an “open-ended question” and see how deeply he can explain the topic.

Total

If you are interested in studying the topic in more detail, I can recommend Svetlana Ivanova's book “The Art of Personnel Selection. How to Assess a Person in an Hour.” I can't say that I was delighted with the book, but nevertheless, there are many thoughts about what methods can be used in interviews. Here are a couple of methods, to get you started:

  • Provocation. When you hint at the expected answer, thereby pushing a person onto a completely wrong path and trying to spin him up as much as possible later.

  • Three pros / three cons. When you try to understand, based on the order or detail of the answers, whether a person is inclined to something or not.

What annoys you about technical interviews?

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *