Anatomy of an effective interview, part two

Anatomy of an effective interview, part two

The last and most dramatic part of the series.

Stormy interviews have a crazy end

The first part is here.

Although strange for the technical part, there is a lot of psychology here. Let’s start with the obvious.

People are lazy. Interviewers are people too (most of them). So, interviewers are lazy.

How lazy, you ask. Very. Most interviewers have 2-3 favorite programming tasks that they remember from ten years ago and give them to every candidate they meet.

I’m not saying it’s bad, just an observation. If you want your interviewers to be more creative and keep up with the times, you need to factor that into your interview process and guide.

My recommendations are based on an interview lasting 40 to 60 minutes. The following recommendations work well for me:

1. Go from lung to complex. If there is enough time, I usually want to give the easier tasks first and increase the difficulty. If you give something really difficult from the beginning and the candidate is not very strong in that area, he will fail and you will not learn anything useful about him at all. After failing a difficult task, the candidate is likely to be too demoralized to work on an easier one.

2. The task should ideally take no more than 20-25 minutes, given the 60-minute limit.

3. I don’t like to give tasks that require knowledge of a specific algorithm (except the basic ones), unless it is a requirement of the position. The candidate may not know it, and that doesn’t really say anything about the candidate.

4. Give clear instructions, don’t try to play mind games and mislead the candidate. We’re not interviewing him for psychic abilities (unless that’s your intention, then go ahead).

5. I prefer to ask candidates to write code in Notepad or a text editor without highlighting the code to see how it can think without additional support. This is my preference, and it is as close as possible to an interview at the blackboard.

What should you pay attention to?

  • The right decision, of course.

  • Did the candidate ask questions? Did he tell you his decision before implementation? Many people rush coding without clarifying the conditions of the task, and as a result solve the wrong task. This is normal for junior/mid-level candidates. Seniors should not do this.

  • Did the candidate consider extreme cases? Again, seniors or juniors are expected to think through bottlenecks and edge cases and point them out or factor them into the decision.

  • Did the candidate check the solution? This is a very good sign of an experienced specialist.

  • Can the candidate accept criticism?

  • Big O. To be honest, I rarely ask this, and only for backend positions. If a candidate can explain the Big O, it’s a good sign that the candidate has spent time preparing for the interview. But that doesn’t really say much else.

Some general observations:

1. It is good if the programming task is related to the work that the candidate will perform in the company. Although this is not always possible.

2. You might want to give a programming task that will take more than 20-30 minutes. In this case, it is better to send it to the candidate separately and let him solve it outside the interview. This can work well if you have a 1-2 hour assignment with a real problem in the area you are hiring for. For example, for the frontend, you can ask candidates to build a specific UI component. I think this is much more relevant than general algorithmic tasks.

We give feedback

I prefer the term “feedforward” (aka feedforward), as Marshall Goldschmidt calls it, rather than just feedback. So why “feedback for the future”? There is a small but important difference here.

With feedback, you’re basically talking about things that went wrong, just like in cybernetics or machine learning – it’s a correction mechanism. Technically, when giving feedback, you should talk about the situation and not blame or insult the person. People are not machines – they can perceive things differently.

So while feedback works, if you have a good connection with the person and they know you’re not criticizing them, it can backfire. In addition, there is a fundamental problem with all types of feedback: it focuses on the past, which cannot be changed.

Just by changing your point of view a little – you will significantly improve the chances that the candidate will listen to you and follow your recommendations. So instead of discussing the past, give recommendations for the future that can help the candidate achieve positive changes in his behavior. Give us ideas for the future. In addition, this approach also reorients your thinking to help people learn to be right instead of proving them wrong. It’s much harder to behave more constructively if you keep that in mind.

Next, I suggest giving feedback immediately after the interview. This may not be complete feedback and should not include any verdict. Just discuss the interview itself and what the candidate might need to look into to refresh their memory and improve in the field. Here you can answer any questions the candidate has about the interview.

Candidate’s question

It amazes me how many candidates finish the interview without asking a single question. After all, after spending an hour on an interview, aren’t you interested in what awaits you if you are hired? It’s as if the person doesn’t care at all what he will do or what the company does in general!

I understand that many techies are introverts, so I’m not lowering my rating for that reason. Some people can’t comment too well, but still be a good professional.

So if a candidate asks intelligent questions, that’s a very good sign. Try to answer adequate questions as best you can.

Again, I suggest not giving any verdict right away, even if you’ve made up your mind. It is better to take a break to think. Just say that you will pass your feedback on to the HR/recruiter and they will contact the candidate after some time.


If you are interested in what I write about – subscribe to my personal blog, please!

I’m the co-founder of AI integrator Raft.

Good luck and positive mood to everyone!

Related posts