As far as a general behavior checklist, this one is fairly accurate in my interviewer experience. It is surprising how often candidates do many of the "Don'ts" in the list.
In the end, I'm looking for candidates I can see myself working with. If we were to pair up on a task or project, I want to be reasonably sure I'm not going to dread the event; I should look forward to it.
One example was a candidate from one of the Big 4. He was having trouble in Java (his preferred language) handling 400 and 500 level errors in an HTTP request that was part of the interview problem. I told him at the beginning that he can use whatever resources he wants, etc. I also told him that I am not a Java person but would help him where I could (we are not a Java shop). While he was reading documentation, I googled how to handle the errors, and said something along the lines of, "it looks like you should be able to do such-n-such with whatever class's method." He just said, "no." A few minutes later, still stuck, I suggested that he give it a try. "That's not how that works." We had to eventually skip the error handling to get back on track.
What I got out of that part of our interaction was that he wouldn't likely be pleasant to work with. He could have said why my proposal would not work or anything beyond simply dismissing my attempt to help. I got the distinct feeling of, "this guy is kind of a jerk." He was applying for a senior developer position. Part of that role would be mentorship and leveling up your team (this was explained early on in the process, before the on site). With our limited time together, he did not convey anything of the sort.
Post interview, he mentioned to our interview organizer / in-house recruiter that it was apparent I did not understand Java development. Post interview, I also took his submitted code and implemented my suggestion and it worked.
In short, I think much of the post's checklist is accurate. Behavior during an interview counts. It is not just technical aptitude.