[swatow]

I don't see how that relates to my post. If anything, the post I replied to was describing an attempt to pass the interview by force of personality and slickness, in that they were describing how to avoid answering the question the interviewer wanted to ask.

I'm not looking for personality, self-confidence or slickness. I just want a person to directly answer the question.

[tptacek]

Yes, I understood what you were saying, and I was observing that even on a message board the question in the abstract was already a battle of wills.

I've done a lot of job interviews. It's not as simple as "candidate gave wrong answer, ding them and move on". If you're taking your job seriously, you're somewhat nervous too, and have to ask yourself if the answer they're giving is better than the one you're looking for. So now it's a debate, and now you're influenced by more than something you can look up in a book for the right answer.

[swatow]

But in my view there is no battle of wills. If the question is an algorithms type question, then there is no ambiguity, and either the interviewee answers it or they don't.

Now if I had asked for a good way to construct a map, and the answer had been that hash maps are good on paper but have high overhead, then I would have to consider their answer carefully. But if I ask how an AVL tree works and the answer is "why do you want to know that" then they have just avoided the question, and I have to insist they answer it.

[mechanical_fish]

If the question is an algorithms type question, then there is no ambiguity, and either the interviewee answers it or they don't.

Imagine that our interview goes like this:

---

Q: Can you implement a red-black tree?

A: I don't know. My Ph.D. is not in CS and I never actually seem to get around to reading the copies of Knuth and CLRS that I optimistically keep on my shelf. Nobody really wants to pay me to read about trees. So mostly I just use other people's trees, particularly the ones that are hiding inside Postgres and MySQL.

It would be fun to try to figure out how to implement a binary tree by asking you twenty questions -- it's one of my favorite party games -- but it will take a bit of time, and I'm in an interview and feeling nervous, so I'm not sure my odds of success are that high.

I did read on Wikipedia the other day that operations on balanced binary trees are O(log N) which makes intuitive mathematical sense, given that a branched structure with n levels will have 2^n leaves. So I guess balanced trees are pretty fast.

---

What do you do next?

I presume that, given that I've failed to answer the specific question, and demonstrated a degree of "slickness" and "force of personality" in the process, that you will ask me if I have any questions, shake my hand, send me out the door, inform your colleagues (including the one who referred me to your company) that I'm a NO HIRE because I couldn't remember the algorithm for constructing a red/black tree, and send me a polite rejection letter the next day?

Perhaps that strategy would have the virtue of being fair. But could you please get it over with during the phone screen? Better yet, could you make sure your recruiters never even email people who don't explicitly advertise CS degrees? Because I'd hate for you to waste a single minute thinking about me, and vice versa. Time is precious. If I find enough of it, I might even get around to reading Knuth!

[tptacek]

Have you never had the experience of discovering that the answer you were looking for in an interview was not the best possible answer? You've never been surprised by a candidate?

[jbergens]

i think many of us feel that questions that you can discuss is more meaningful and tells you more about the person being interviewed than strict algrorithmical question. In some cases those kind of questions only tell you if the other person has studied that exact question recently, nothing more.