Slightly off topic, but I am interested in interview technique.
Neither the candidate nor the interviewer wants to waste time and a
structured, planned interview is one way to best ensure this.
Apart from a chatty preamble, I ask candidates the same questions and
compare them on the answers to questions that they knew, answers to
questions that they got wrong, and response to questions that they
don't know.
I explain this to candidates up front, and tell them not to be
disheartened if the questions appear unfair.
This is partly a response to increasing number of phone interviews
where candidates have prepped answers to common technical questions
(and are googling with Cone of Silence over the keyboard :-) )
The questions are intentionally increasingly obscure to push into
i-dont-know territory. I like an explanation of the system statistic
/transaction rollbacks /for instance, /enq: TM - contention, /things
like that.
Once there, you get a better idea of how someone deals with pressure
and how well someone acknowledges that they don't know something; but
know how to find out.
I judge the third ("I dont know, but....") most seriously; the breadth
of what an oracle professional now deals with is huge, and I am very
dubious of anyone that claims subject matter expertise on the entire
product.
I also dislike technical jargon and any language that attempts to
obscure clear meaning: whenever I hear the word "solution" I ask them
to describe it using any other word.
Attempting to bounce technical questions back at an interviewer is
counter-productive I think. Iit is not necessary for an interviewer to
have more expertise on a topic in order to judge the quality of your
response, both immediately and in retrospect while comparing with
other candidates responses. If the interviewer does not appear to be
recording your responses seriously then I'd feel free not to take them
seriously either.
