As somebody who has done numerous technical interviews, as well as given some, I have to disagree with some of the points he makes.
1) "I don't code out loud": neither do I, nor as an interviewer would I honestly want you too in a 'real' work environment. What I do want to know (or attempt to know) is how you think. If you can articulate your thought process as you solve a question, it shows me that a) you can think logically under pressure, and b) you can convey your thoughts and ideas to somebody who might be a fellow team mate.
2) Talking about a project you have done is cool, but I personally don't care what technologies or hacks you used. I want to know if you can code. If you can't code, then it doesn't matter what you know since I can't use you on my team. If you can code, then I'll use what I learn from (1) to determine if you have the ability to choose the right algorithm/tool/technique/etc for a job.
One might retort that (2) can be easily solved by showing them project code. Unless its a github account, I don't really care, because I can't tell what you did versus somebody else and it is far to easy to control what the interviewer sees (as you showed when discussing your "team motivation" skills).
At the same time, TSC definitely made some simple mistakes in the types of questions they asked you, especially for an on-site. A proper technical question (IMO) is one that can tell me easily if it's not a fit, but has enough different solutions that let me gauge just how good a candidate is. A question that is a no if you get it wrong, but not a yes if you get it correct (hex CSS colors) would be a wast of both our time (and would probably get me kicked off the interviewing team).