steering an interview is all about steering the human(s) giving the interview.
real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport.
He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars.
So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.
This is the kind of thing that people want to avoid. Hiring a person because they share a hobby is ridiculous. If a candidate tried to steer the interview to non-technical questions I'd point that out to the relevant people and make sure it was highlighted in my feedback.
If you let the candidate steer the interview in the wrong direction, the fault is in the interviewer, not the candidate.
I have been on both sides of the equation.
My stories:
1) Brain teaser questions sometimes aren't as easy or as straightforward as everybody thinks--don't ask them as an interviewer unless you genuinely KNOW the question.
Digital VLSI design loops almost always have a question that makes you use a state machine--this is actually a decent question for a whiteboard as long as you don't do something stupid like use J-K flip flops in CMOS. There are a host of basic questions you can use ... but beware of traps.
I was once asked the following question: "You have a serial bitstream that represents a binary number. Keep track of the value of that number modulo 3." This is a decent question ...
Or a really hard question ... depending upon whether the number is being clocked in MSB first or LSB first.
Unfortunately, when I wrote the numbers down on the whiteboard, I chose the "hard" direction. And had to really think ... and the interviewer kept getting more and more agitated and finally complained "Look, this is easy, just do 3 states like this". To which my response was "But clock in any of the numbers in that I wrote on the board. Your machine fails at the second clock."
His machine, of course, works just fine for one direction. But that wasn't the direction I picked and documented picking by writing it on the whiteboard. And his machine didn't work with the bitstreams I chose. And 20 minutes wasn't enough for me to see what he got wrong and demonstrate it back. And he didn't understand his question well enough to flag the reverse order.
Exercise for the reader: There are two answers to the question depending upon MSB-first or LSB-first. One answer only requires 3 states. The other answer requires 6 states, but it is NOT clear that 6 states are enough without some serious thought (you can prove 6 are enough inductively if you are clever).
2) I used to always bring to electrical engineering interviews 2 printouts with the same program--one in Python and one in Perl. This meant that when I was asked "Do you know Perl?" I could force the interviewer into MY subset of Perl--and I could explain why I avoided Perl nowadays with a compare and contrast. This simply steamrolled all but one interviewer.
3) I was interviewing with an RF company who was needing VLSI digital designers. A poor slob of an analog engineer drew the short straw for handling the digital questions and was so completely out of his depth that I felt sorry for him. After about half the interview of glazing his eyes with advanced digital architecture, I threw him a bone. I made an off-handed comment about digital really not being digital and how the old audio guys used to use the 4000-series CMOS inverters as audio amplifiers. Baited and hooked. We spent the rest of the interview discussing that as an audio amp (of course, I knew the answers to that question cold--that's why I mentioned it).
4) As an interviewer, I used to run a really difficult section of the VLSI design loop which used to intimidate candidates horribly. I had very stern words with HR that my section was supposed to always be at the end (we almost lost a REALLY excellent candidate because he hit me first, did excellently but THOUGHT he bombed, and then flubbed everybody else afterward). I only had a couple of questions, but they were bottomless. If I had a PhD in front of me, I could make him explain complicated things. If I had a newbie in font of me, I would take him one step further than he was comfortable with and see how he reacted. The candidate steered the interview, but within the bounds I set.
5) My favorite interview was when an interviewer asked me my own difficult question back. It took a moment until I realized exactly what he did, and then I launched 30 minutes into the bottomless pit until I was sure that everybody had glazed eyes and then some. We all had a good laugh afterwards.
real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport.
He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars.
So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.