I strongly disagree with most of this. A single unfit colleague can significantly lower the efficiency of a whole team and bring down the morale. For everyone who is in, and who is going to join in the future, it is very important to pick the right candidate, so it is fair to take trade-off that make the process more uncomfortable as long as they make it better. As in this article.
One process does not fit all
This is absolutely true, but it important to figure out how a candidate handles uncomfortable situations. In real life you do not always get to pick the circumstances, neither should you be able to in the interview. However, which type of tests fits a candidate is relatively unimportant, therefore it is important to go through couple of different tests.
Test for things that are actually needed in the role
This is the point I disagree the most with. Ecosystems change fast, projects change fast, basics stay. It is good to know your tools, but I would prefer a sharp and fast learning candidate with a firm grasp of the fundamentals. If a candidate cannot provide a good approach to a reasonably chosen algorithmic problem, s/he is a bad developer, period. Actually getting to a solution involves a bit of luck, but the interviewer can see someone is good at problem solving in general even if the candidate does not manage to solve the problem at hand.
Important is to leave out stuff that is whether directly relevant to the task, nor useful in general. Citing the steps of an algorithm by name is such a skill.
Expecting multiple rounds of interviews from a candidate
This just makes sense. A team works when (ideally) every pair in the team work well together. Everyone that a candidate is expected to work together with closely is relevant and, as long as the total number stays manageable, should interview the candidate. It sucks to be eliminated at the last round, but assuming the process eliminates at least half of the candidates at any given stage, the average candidate is going to have less than two interviews. As other people in the comments suggested, it is good to be flexible with timing or pay for later rounds.
Plus, more rounds means actual measured skill will have more impact on the decision process than the CV, more people will be involved, and the candidate will have more chances to shine and will be less affected by random variations in interviews.
Ignoring previous experience
It is very hard to assess previous experience, especially in a large company, where it is easy to get by doing so little. Can the candidate show a product and a clear way to see which contributions were his? (open source projects, solo projects etc.), perfect, this is better than any other interview. Otherwise, it is better to ignore previous experience, as it can be "faked" much more easily than faking skill in an interview. It is not about picking the best resume, it is about picking the best developer.
Relying on personality tests
I completely agree on this, and also with most of the "what you can do" section.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I strongly disagree with most of this. A single unfit colleague can significantly lower the efficiency of a whole team and bring down the morale. For everyone who is in, and who is going to join in the future, it is very important to pick the right candidate, so it is fair to take trade-off that make the process more uncomfortable as long as they make it better. As in this article.
One process does not fit all
This is absolutely true, but it important to figure out how a candidate handles uncomfortable situations. In real life you do not always get to pick the circumstances, neither should you be able to in the interview. However, which type of tests fits a candidate is relatively unimportant, therefore it is important to go through couple of different tests.
Test for things that are actually needed in the role
This is the point I disagree the most with. Ecosystems change fast, projects change fast, basics stay. It is good to know your tools, but I would prefer a sharp and fast learning candidate with a firm grasp of the fundamentals. If a candidate cannot provide a good approach to a reasonably chosen algorithmic problem, s/he is a bad developer, period. Actually getting to a solution involves a bit of luck, but the interviewer can see someone is good at problem solving in general even if the candidate does not manage to solve the problem at hand.
Important is to leave out stuff that is whether directly relevant to the task, nor useful in general. Citing the steps of an algorithm by name is such a skill.
Expecting multiple rounds of interviews from a candidate
This just makes sense. A team works when (ideally) every pair in the team work well together. Everyone that a candidate is expected to work together with closely is relevant and, as long as the total number stays manageable, should interview the candidate. It sucks to be eliminated at the last round, but assuming the process eliminates at least half of the candidates at any given stage, the average candidate is going to have less than two interviews. As other people in the comments suggested, it is good to be flexible with timing or pay for later rounds.
Plus, more rounds means actual measured skill will have more impact on the decision process than the CV, more people will be involved, and the candidate will have more chances to shine and will be less affected by random variations in interviews.
Ignoring previous experience
It is very hard to assess previous experience, especially in a large company, where it is easy to get by doing so little. Can the candidate show a product and a clear way to see which contributions were his? (open source projects, solo projects etc.), perfect, this is better than any other interview. Otherwise, it is better to ignore previous experience, as it can be "faked" much more easily than faking skill in an interview. It is not about picking the best resume, it is about picking the best developer.
Relying on personality tests
I completely agree on this, and also with most of the "what you can do" section.