Most Technical Interviews Suck
mynameisjehad.com
mynameisjehad.com
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).
1) I absolutely understand that "thinking out loud" is just a way for the interviewer to know how I think. The problem with that, however, (at least for me) is that now I have two tasks a) to write code and b) to tell what I am thinking without saying anything wrong. I know that it is ok to say something wrong, at the end, you don't get the answer immediately but I am under pressure to show you my best and that what comes to mind.
2) Maybe I didn't show that clearly in the post but I do think it is ok to ask technical questions, I just think you need to also give the interviewee a chance to tell you more about who they are, what projects they worked on, and what kind of technologies they applied. This is essential for many reasons including a) it gives me the confidence before the technical question, b) it tells you a little bit more about what I am able to do, and c) it gives you a better understanding of the interviewee since the question you just asked doesn't tell you enough about me or my talents (in my opinion)
That has been said, you raise some good points. Thanks for taking the time to reply!
They think in their native language, and have to not only solve the problem you present them, but also translate their thoughts at the same time. Can you see yourself doing that?
I don't have a solution to propose. I just wanted to raise the issue.
If I realize that they are not native english-speakers, then I typically give them the option to work on the code, the stop at a breakpoint and have them explain what they did and why they did it. This seems to keep undue Stress off the applicant while still letting learn about how they think.
Some of the worst candidates have had the best resumes. I'd bet good money they could have talked coherently about their projects, made it sound like they'd cured cancer. But when I asked them to do something not much harder than FizzBuzz on a whiteboard, they choked. Ask them to intersect two lists? They'd use Excel. Ask them how Excel would implement that? They freeze, the interview is over. This was a normal pattern. Thankfully, our recruiters started asking pulse-checking questions, and the number of these interviews dropped.
Interviews need something that can't be directly prepared for and directly rehearsed. Unfortunately, I don't think your solution has provided that. I think it would tend to hire silvertongued people who cut and paste.