Do’s and don’ts of the interview process p.2
Last, and most dramatic part of this series.
Coding part
This is the third part of my article on interviews.
Surprisingly a lot of psychology here. Let’s start with some obvious things.
People are lazy. Interviewers are people (well, most of them are). Ergo, interviewers are lazy.How lazy, you might ask. Very. Most interviewers have like 2–3 favorite coding tasks they picked up ten years ago, and they give those to each and every candidate.
Not saying this is bad, though, just an observation. If you want your interviewers to be more creative, you need to account for that in your interview process and guidelines.
My recommendations are based on a 40 to 60-minute interview. These guidelines worked for me well:
1. Go from easy to hard. If there is enough time, I usually want to give an easier task first and increase difficulty. If you give something really hard from the start and the candidate is not super strong in this area — he will fail, and you won’t get to learn anything about him/her. After failing at a difficult task, the candidate is likely to be too demoralized to work on an easier one.
2. The task ideally should not take longer than 20–25 minutes, given the 60 minutes time constraint
3. I don’t like to give tasks that require knowledge of some specific algorithm (except for basic ones) unless this is a position requirement. A candidate might not know it, and this doesn’t actually say anything about the candidate.
4. Give clear instructions, do not try to play mind games, and mislead the candidate. We are not interviewing him/her for a psychic (unless you are, then go for it).
5. I prefer to ask candidates to 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 it is as close to a whiteboard interview as possible.
What to look for?
- A correct solution, obviously
- Did the candidate ask questions? Did he walk you through his solution before implementation? A lot of people rush into coding without clarifying task conditions and end up solving the wrong task. This is ok for a junior/mid-level. Seniors should never do that.
- Did the candidate take into account edge cases? Again, seniors or SDETs are expected to think through bottlenecks and edge cases and point them out or account for them in the solution.
- Did the candidate test the solution? A very good sign of an experienced veteran.
- Can the candidate take criticism?
- Big O. Well, I rarely ask this, and only for backend positions. If the candidate can explain Big O — it is a good sign, that the candidate invested time into preparation for the interview. But it doesn’t really indicate much else.
Some general observations:
1. Ideally, the coding task should be related to the job the candidate will be doing. Not always possible though.
2. You might want to give a coding task that is longer than 20–30 minutes. In this case, it is better to send it to the candidate separately and let the candidate solve it outside of the interview. This could work well if you have a task for 1–2 hours with an actual problem in the domain you are looking to hire for. For example, for the frontend, you can ask candidates to build a certain UI component. I think this is way more relevant than generic algorithmic tasks.
Giving feedback
I prefer the term feedforward, as Marshal Goldschmidt calls it, over feedback. So why feedforward? There is a small but crucial difference.
With feedback, you essentially talk about things that went wrong, so like in cybernetics or machine learning — this is a correction mechanism. Technically, giving feedback, you should talk about the situation and shouldn’t make this person wrong. People are not machines — they can perceive things differently.
So, although it works if you have a good connection with the person and they know you are not criticizing, it may misfire. Also, there is a fundamental problem with all types of feedback: it focuses on the past that can not be changed.
Just by changing your perspective slightly, you will tremendously improve your chances that an interviewee will listen to you and will act upon your guidance. So instead of talking about the past — make suggestions for the future that might help the candidate achieve a positive change in their behavior. Give ideas for the future. Also, this approach will re-orient your thinking as well, to help people learn to be right than prove they are wrong. It is much harder to act condescending if you have that in mind.
Next, I suggest giving feedback immediately after the interview. It may not be complete feedback, and it need not include any verdict. Just talk through the interview itself and things that the candidate may need to look at more deeply to refresh his/her memory on to get better in this area. Here you can address any questions that the candidate has about the interview.
Candidate’s questions
It is surprising to me just how many candidates end the interview without asking any questions. Like after spending an hour on the interview, wouldn’t you be interested in what awaits you if you are hired? It is like they are not interested in what they will be doing or in the company at all!
I understand that many tech people are introverts, so I don’t lower my assessment based on that, but many people do.
So candidate asking intelligent questions is a very good sign. Try to answer appropriate questions as best as you can.
Again, I suggest not giving any verdict right away even if you are the decision-maker. It is better to take a timeout to think. Just tell them that you will pass your feedback to the HR/Recruiter, and they will contact the candidate in a short while.
