I agree with much of this. Some additional comments:
> Ask questions as close as possible to real work: This is achieved by making interview question as similar as possible to the job you want the candidate to do (or to the skill you're trying to measure).
This "or" thing in parentheses is really important. Interviews should not be "as similar as possible to the job." They should be all about the skill you want to measure. And there's quite a difference between these.
People can be trained, assuming you have time and resources.
The point of standard algorithm interviews is to measure a particular skill: intelligence. The belief behind this is smart people will tend to solve problems well in the real world. It's okay if they don't know all the skills they need; they can learn them. (And if there's a particularly challenging skill, then maybe you need to add that into the process.)
> Avoid hard questions: If a candidate solves a really hard question well, that tells you a lot about their skill. However, because the question is hard, most candidates will fail to solve it well. The expected amount of information gained from a question, then, is heavily impacted by the difficulty of the question. We find that the optimal difficulty level is significantly easier than most interviewers guess. This effect is amplified by the fact that there are two sources of signal when interviewing a candidate: whether they give the “correct” answer to a question, and their process / how easily they arrive at that answer.
You don't give examples of what qualifies as hard vs. easy, so it's a little difficult to judge this. But generally, I'd advocate for people asking harder questions.
When a question is easy, a little thing -- small point of confusion, etc -- can make a big difference in whether the candidate seems to have gotten to that answer well or not.
When a question is hard, this is when you can actually see a great differential between great vs. good vs. okay. You can offer help and see how effectively they pick up on that advice.
If your interviewers are just throwing out a question and then sitting back and seeing what happens, then yeah, candidates won't be able to tackle a hard question. But that's not what they should be doing.
To be clear here: hard does not mean "ask about some obscure data structure [skip lists, etc]." It means a challenging question involving common knowledge (hash tables, strings, arrays, maybe binary search trees).
> 5. Ask every candidate the same questions: [...] there is no justification for asking different questions to different candidates. If you evaluate different candidates for the same job in different ways, you are introducing noise.
I think this is overplayed a little.
If you're doing algorithm-style interviews, any question should be basically evaluating the same skill (problem solving skills). If I ask my favorite question and you ask your favorite question, but they're evaluating the same skill, then it doesn't really matter. There's nothing to make one question better than another. Why not let each interviewer ask the question that they like?
Now, if every interviewer asks a different question, you won't be able to give a well-defined metric on what good performance looks like for that problem. But that's okay. You can't really do that anyway.
When companies give well-defined metrics, they get too rigid. The candidate takes slightly longer to complete the code because the candidate thought things through more thoroughly, and now they're pushed into a lower performing bucket. And that's wrong.
These standardized metrics sound good in theory, but they don't work well in reality (for algorithm interviews, anyway).