As somebody who has done numerous technical interviews, as well as given some, I have to disagree with some of the points he makes.<p>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.<p>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.<p>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).<p>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).
The title is "Most Technical Interviews Suck". The content is about how what a series of interviews at one specific company sucked, and the interviews didn't sound all that technical. Bad day, sure. But definitely not supporting the title.