I've been thinking about interview questions lately and I've been reflecting on bad interview experiences I've had in the past. One of particular note is where I had asked the interviewer why the team chose to use EJB 3 over Spring in their product. The interviewer pretty much tore my face off, yelling "Because Spring is not the be all and end all of Java software development, do you want this job or not?". In response to this, I told him that this probably wasn't the job for me and I promptly walked out of the interview.
I was informed at the beginning of the interview that the company had high staff turnover, the product they were working was initially created in Modula-3 then ported to Perl and finally to Java. I was handed a 10 page booklet of technical questions covering Java, EJB, SQL and JDBC and I was asked questions about the technology stacks I've worked with. When prompted to ask questions, I felt it was reasonable to ask them about their technology stack and and get reasonable answers back, not to send the interviewer into flames.
Question: Is it a good idea to probe on architectural choices taken in an interview? If not, why?
From my own point of view, an interview is a two-way process. If the interviewers are testing me on my technical skills, I've got every right to ask them the same questions to:
1) Figure out what their mindset and attitudes towards developing software are. 2) Determine if their approach is in line with how I would approach problems of that kind.
It's possible that the interviewer who got angry had poor interviewing skills and forgot that an interview is a two-way exchange. If I was asked this, I would have given a reasonable answer, but I certainly wouldn't have tried to put an interviewee in a state of meek capitulation where the head just bobs up and down with no conversation.