Tip 3 is huge. I ask hard questions during interviews, and I don’t expect a perfect answer. What I do want is the interviewee to handle failure without being defensive, and to ask probing questions.
Same here. Some of my goto questions are questions I don't expect a solution to. I'll tell people that - I know some people use similar questions without telling candidates that, but I don't think the extra pressure is necessary. I also explicitly explain to people that what I want to see is how they think, more so than the final solution.
It tells me a lot about how a candidate will work within a team if they're capable to actually bounce ideas back and forth and explain their thinking, and I've often preferred someone who doesn't get as far but who can show me better communications skills and who seems eager to learn.
I've found you can somewhat mitigate it by asking questions yourself. For example in one tech screen once I had the algorithm pretty much done I asked if I should look to optimize and to add test cases/handle odd input and the interviewer said it's fine as is and let's talk more about other topics like architecture in the real world.
Absolutely, that's something I pointed out in my writing: if the interviewer doesn't explain their expectations, you can and should ask. Interviews work best when both parties are engaged heavily in the success of the interview.
On the other hand, I go through months where half my job is devising ways to extract requirements from users who just want me to "make this problem go away"! I consider it very reasonable to test someone's ability to work out what problem they're meant to be solving.
I like to ask open-ended questions. "I am trying to solve X problem, how should-I do it?". That reduces the rote bias and also checks if the candidate can communicate.
Heh, I once was introduced to a particular interview question. It has a solution that is hugely better than the best naive solution, but is basically a giant gotcha that seems obvious in retrospect. I couldn't find it myself even though I was stumbling around in its neighborhood. Obviously I gave this question informally to a ton of people as entertainment (Bay Area techies in various companies), and most couldn't find it either.
However, one guy told me he now uses the question as his actual interview question because he thinks the way people suffer thru a seemingly impossible problem reveals how good of an engineer they are :D
Sorry, I was offline for the break. You have a singly linked list with each node having a "random pointer", an extra field that points to another node in the list (including itself or null). You need to make a copy of the list, in such manner that random pointers in the copy correspond to the original list, e.g. if the 10th element of the original points to the 3rd element of the original, 10th element of the copy needs to point to the 3rd element of the copy.
Was it clear for the candidate what you were looking for, like "if it happens you don't know the answers or else, I'd like to know how you think about it"? Because that is what I do in the beginning of the interviews I lead, I dislike the approach "let's slap this guy and see if she calls her mother". It puts the interviewer on the throne and the candidate of their knees, it is an interview and not the "real" job, and the candidate may have studied for months and might be rightfully defensive when they see their months of work go up in smoke after your "slap".
I don’t go out of my way to encourage the behavior I’m hoping to see, but I do indicate that the question isn’t one I expect a complete answer for and that it’s more of a discussion than an interrogation.
