Is it wise to ask about design decisions made on a product during an interview?
Posted
by
Desolate Planet
on Programmers
See other posts from Programmers
or by Desolate Planet
Published on 2011-11-12T15:57:14Z
Indexed on
2011/11/12
18:06 UTC
Read the original article
Hit count: 391
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 Spring over EJB3 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 walked out the interview. He told me at the start of the interview that they had high stuff turnover, the product had gone from Modula 3 to Perl to Java then after asking him a technical question, he went in flames. It seemed obvious to me that he was toxic to the company with that kind of attitude.
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 solutions are and 2) To figure out if there are in line with how I would approach problems of that kind.
It's very possible that the interviewer who got angry was a bad interviewer and forgot that an interview is a two-way process. If I was asked this, I would have simply said something along the lines of wanting to leverage the container more, but I certainly wouldn't have tried to put him in a state of meek capitulation. The interviewer in question was the lead developer in the team.
© Programmers or respective owner