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).
Thanks for pointing out this from the point of view of someone who conducts interviews. However, let me address your points:
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!
I feel for you. I have failed a few interviews; I choked in the interview because I didn't simulate the interview environment in practice by whiteboarding and talking through problems alone. I recommend you read Steve Yegge's post about interviewing at Google (http://mlaroche.blogspot.com/2011/10/algo-interviews-are-ove...) - especially with regards to smart people having bad days interviewing. When I realized I'd make mistakes at interviews and still actually be a good person and good hire, I stopped choking and I stopped grasping at straws on interviews.
I've been told by a brilliant, but non-native English speaker, that (1) is very challenging.
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.
I agree this is an issue, and given that some of my smartest peers learnt English as a second (or third) language, I definitely don't want to make it harder.
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.
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.
I mentioned at the end that I do acknowledge this is a specific case, however, it is just an example followed by a conclusion. What I wanted to say is simply that technical interviews in general tend to focus on the question itself more than the person being interviewed.
I've done a lot of interviews. Hired a bunch of people. And I'll agree that technical interviews aren't a great proxy for how we really should be handling hiring (blogged about it a couple days ago http://mlaroche.blogspot.com/2011/10/algo-interviews-are-ove.... Must be college interview season where you are too if we're both thinking about it.).
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.
I just replied to another comment with a similar point. I am not suggesting we should never ask technical questions. All what I am saying is that we need a balance between technical questions and knowing about what the person did or can do. (Look like I might need to update the post to mention that)
Tweeted you a screen shot. Only happens through hacker news tweet link. Direct visit to your blog is fine. Wouldn't worry to much about it. Great post.
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).