Hacker News new | ask | show | jobs
by awm 5345 days ago
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).

2 comments

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.