Coding part: Do's and don'ts of the interview process p.3

This is the third part of my article on interviews. Part 1. Do's and don'ts of the interview process. Part 2. The anatomy of an effective interview.

Surprisingly a lot of psychology here. Let's start with some obvious equations.

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 minutes 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 likely to be too demoralized to work on an easier one.

2. 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 a position requirement. 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 the 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?

1. A correct solution, obviously
2. 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.
3. 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.
4. Did the candidate test the solution? A very good sign of an experienced veteran.
5. Can the candidate take criticism?
6. Big O. Well, I rarely ask this and only for backend positions. If the candidate can explain Big O - it is a good sign, 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 frontend, you can ask candidates to build a certain UI component. I think this is way more relevant than generic algorithmic tasks.