The Anatomy of an Effective Interview, Part Two
The last and most dramatic part of the series.
The first part is here.
Surprisingly 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). Therefore, interviewers are lazy.
How lazy are you, you ask? Very. Most interviewers have 2-3 favorite programming tasks that they remembered ten years ago, and give them to every candidate they come across.
I'm not saying this is bad, just an observation. If you want your interviewers to be more creative and move with the times, you need to factor this into your interview process and guide.
My recommendations are based on interviews lasting between 40 and 60 minutes. The following recommendations work well for me:
1. Go from easy to difficult. If there is enough time, I usually want to give the easier task first and increase the difficulty. If you give something really difficult from the very beginning, and the candidate is not very strong in this area, he will fail, and you will not learn anything useful about him at all. After failing on a difficult task, a candidate will likely be too demoralized to work on an easier one.
2. The task should ideally not take 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 for basic ones), unless this is a requirement for the position. The candidate may not know it, and it doesn't really say anything about the candidate.
4. Give clear instructions, do not try to play mind games and mislead the candidate. We do not interview him/her for psychic abilities (unless that is your intention – then go ahead).
5. I prefer to ask candidates to write code in Notepad or a text editor without code highlighting to see how he/she can think without additional support. This is just my preference and is as close to a whiteboard interview as possible.
What you should pay attention to?
The right decision, of course.
Did the candidate ask questions? Did he tell you his decision before implementation? Many people rush into coding without clarifying the conditions of the problem, and end up solving the wrong problem. This is normal for junior/mid-level candidates. Seniors shouldn't do that.
Has the candidate considered edge cases? Again, seniors or seniors are expected to think through bottlenecks and edge cases and point them out or factor them into the solution.
Has the candidate checked the solution? This is a very good sign of an experienced specialist.
Can the candidate accept criticism?
Big O. Honestly, I rarely ask this, and only for backend positions. If a candidate can explain Big O, it's a good sign that the candidate 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 may want to assign 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 of the interview. This can work well if you have a 1-2 hour task 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 problems.
We give feedback
I prefer the term “feedforward”, as Marshall Goldschmidt calls it, rather than just feedback. So why “future feedback”? There is a small but important difference here.
With feedback, you're essentially talking about things that went wrong, just like in cybernetics or machine learning – it's a correction mechanism. Technically, when giving feedback, you should be talking about the situation and not blaming or hurting the person. People are not machines – they can perceive things differently.
So, although feedback works, if you have a good connection with the person and he knows that you are not criticizing him, it can fail. Additionally, 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, make recommendations for the future that can help the candidate achieve positive changes in his behavior. Let's have ideas for the future. Additionally, this approach will also refocus your thinking to help people learn to be right rather than prove them wrong. It is much more difficult to behave more constructively if you keep this in mind.
Next, I suggest giving feedback immediately after the interview. This may not be full feedback and should not include any verdict. Just discuss the interview itself and what the candidate might need to look at in more depth to refresh their memory and improve in that area. Here you can answer any questions the candidate has about the interview.
Candidate Questions
It amazes me how many candidates end the interview without asking a single question. After all, after you've spent an hour interviewing, aren't you wondering what's in store for you if you get hired? It's as if the person is not at all interested in what they 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 communicate very well and still be good professionals.
So if a candidate asks smart questions, that's a very good sign. Try to answer relevant questions as best you can.
Again, I suggest not giving any verdict right away, even if you have made a decision. It's better to take a break to think. Just say that you will pass on your feedback 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 blogPlease!
I'm a co-founder AI integrator Raft.
All the best and positive mood!
