Is it wise to ask about design decisions made on a product during an interview? [closed]

Question

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.

Answer 1

Personally, I find interviewing people almost as exhausting and stressful as being interviewed. But that's because I agree with you that the interview process is a two-way exchange.

I don't care how good you are, I don't want to hire you if you're not going to be happy working there. That's an expensive game to play. So I want to answer any concerns you might have and show you the team and product as they are, so that you can make an informed decision.

When I'm looking for a job, I want to work with someone who shares that attitude. And, even if I suspect I know the answers to questions, I will ask them just to see the reaction. Aggression is never a sign of someone comfortable with a situation.

I don't lie in an interview, on either side of the desk, because then they think they're hiring someone different / going to work somewhere different. And I expect the same in return, from the person on the other side of the interview.

Unfortunately, that means that occasionally I run into interviews like the one you described. Are they horrible experiences? Yes. Do I come out of there knowing exactly where the interview went wrong? Yes.

But am I very sure that every horrible experience would have been considerably worse if I'd got the job or hired the wrong person? Hell yes.

Answer 2

Yes, it's ok to ask if you're genuinely curious and if the answer matters. I think asking shows you understand there's more than one way to do things, and it shows you are interested in how the software was written.

That being said, you've got to be very careful in how you phrase the question, and doubly careful about how you continue the conversation. It is easy to come across as challenging their decisions. The last thing you want is for the interviewer to believe you think you're smarter than them. If you're genuinely curious, ask. If you think they made a poor choice, keep your mouth shut.

If I had been in the situation described in the question, instead of walking out I might have said something like "oh yeah, I agree that spring is definitely not the right solution for everything. Thanks for letting me know a bit about your architecture! I'm always looking for insight into how to choose the right tools". (though, your question is odd -- you ask why they chose spring, and they chose it because it was not the be all end all?)

Answer 3

As someone who frequently interviews people, I'd personally welcome a discussion about why particular technology or design choices were made, what we'd do differently now if we either had the luxury of resources or were starting a new project. I'd generally see it as a sign about someone who cares about their craft, and unless their dogmas and ours weren't compatible, I'd probably rate that candidate more highly than someone who just answers technical questions competently.

I'm currently working on a project for a client which has a legacy of some well-meaning but poorly implemented architectural decisions, and candidates who express curiosity about the world as it is, and the path forward as we see it, are usually the types of people we'd like to work with. We want people who are able to do appropriate due diligence and validation on design and implementation decisions on our team. We generally value people who bring something to the table that we don't have, or don't have enough of.

When I've been a candidate in an interview, I take any sign of hostility or defensiveness when these types of discussions happen as a bad sign, as an organization not capable of self-examination is usually also in a technological and process morass that they are incapable of and probably unwilling to work their way out of. If I don't see motivation for continuous improvement on the existing team, there's a good chance I won't be happy there.

If I went in and they said, "Yeah, we've got this legacy app that we're not happy maintaining but it still brings in enough revenue to cover all our paychecks, and we want to make the codebase more maintainable by refactoring the pain points, or migrate component x to technology y" or "we chose technology a over technology b because we had more experience there and technology b was still in its infancy when we started; we're open to change but it's a slow process and we aren't in a position to just throw out our existing codebase", I can believe it's going to be a better experience for me than if I hear "Yeah, we are stuck on Borland C++ Builder version 6 and developers aren't allowed to make technical decisions because they've all already been made by the CEO's brother, who slept with an Oracle salesperson once and decided all future development will be done using Java 1.4 web services, Oracle ERP, and a Borland C++ frontend using mostly discontinued 3rd party GUI components and we'd rather spend $60,000 a month plugging holes to keep customers from jumping ship than revisit any decisions and make permanent improvements that might bring new revenue if we're lucky. Don't rock the boat, what's wrong with you."

Presuming you're in an area with other technology jobs, or you're willing to move, you likely have the luxury of choice. No gig is perfect, but you want to work with people who want to work with you. (I care more about this than the specific technology choices most of the time.) If something smells bad, it probably is.

So yeah, ask away. The more curiosity about our business, our process, and our design, the more seriously I'm likely to take a candidate. But I don't work at a Blub shop, so I can't say whether it'll help you get a Blub job. I can only say that it would work for you if you want to work with other people who care about their craft.

Answer 4

Question: Is it a good idea to probe on architectural choices taken in an interview? If not, why?

It absolutely fine, I would view it as a positive.

If your interviewer can not handle that, it says a lot about them - not you.

I would be worried if a junior was NOT interested in design decisions, it would show a lack of curiosity/interest in the subject area, and exhibits no desire to improve themselves.

Answer 5

I'm of the mindset it's essential. I've worked at far too many jobs with nonsensical design decisions either because nobody knew any better, didn't care to learn, or there was a mandate from management to use whatever the CEO read about in a magazine/saw online/had someone tell him was the "next big thing" without any consideration of alternatives. These jobs were all miserable places to work.

You shouldn't necessarily criticize a design decision unless it's something that spits in the face of common sense or just sounds like crazy talk, but it's common to question things that seem "off" to find out if there's a legacy reason or something that came up that facilitated the need for using an unorthodox approach.

Asking questions like this also has the effect of gauging the company's interest in improvement and competency. As someone else above said, it's one thing if you get an answer like (I don't know Java but use .NET so will use .NET examples) When we wrote the app there were no mature ORMs, so we used stored procedures with a data gateway layer. We'd like to move to Entity Framework in the future and another thing entirely to get an answer like We just use stored procedures. Entity Framework looks scary and might require work to refactor, and we can't refactor anything because the CEO has a laundry list of new features he wants us to work on, and if we spend the time looking at Entity Framework he'll fire us for wasting time. One indicates understanding and a desire to improve, the other indicates a mediocre at best environment where everyone does the bare minimum to scrape by.

A company that takes offense at you questioning their decisions or wanting to discuss why they chose to use Product A instead of Product B is playing their hand and showing that they don't want a free thinker but a drone who won't question, and chances are it's not the kind of company any competent developer wants to work for.

Answer 6

answer: It is a good idea to ask about architectural decision making. But you need to be careful how you ask such questions.

Simply put: You should ask "How did you go about choosing technology X over technology Y?".

You want to phrase it in a way to communicate that you are generally interested in the process of decision making within the team. Nobody will want to go over every legacy decision the company has ever made with a candidate.

When you ask "Why did you choose technology X over technology Y?", it may come off that you disagree with their decision (which is ok...but can be taken as hostile) or that you want to boast about how much you know about the technologies in question (which would be annoying for anyone), despite your good intentions.

Answer 7

I'm fond of asking an interviewer to tell me about a failed design decision they made, and what was done next. This gives you some good pieces of information:

1. If the boss can't admit any form mistake or temporary failure, that's a boss you probably don't want to work for.
2. You can tell how the company handles a stressful situation.

It might not be popular, but I always have great respect for the managers with the stones to recognize a project is going to fail and kill it to stop wasting money, or that something is headed in the wrong direction and needs to be killed or rebooted.

Ultimately if you're talking about job satisfaction the technology (language/platform/compiler/whatever) doesn't matter so much as the personalities involved and the work environment.

Answer 8

A few years back I was in an interview and had been asked various technical questions about a programming language... which I hadn't done well on (60/40 correct/incorrect). The discussion moved onto the project they had in hand and I started asking questions about the design and then pointed out a couple of problems and limitations they would introduce.

I was offered the job the next day. Unfortunately I was unable to take it up for personal reasons.

Asking questions about design shouldn't be a problem if they are intelligent questions especially if you can then relate them to their business.

Answer 9

I've not done much interviewing, but, from your experience, I would conclude:

a) It's OK if you want to make an informed decision about whether you want the job;

b) It's not OK if you already decided you want the job.

People can easily get offended by benign quentions about their choices. That's an awfully bad trait, but a common one.

Answer 10

Here's some advice

1. Asking why they chose some existing solution might be bad question, because probably the development team was not given chance to change or choose it.
2. Also the team likely already knows why the technology was not the best choice
3. But unfortunately, the last thing any development team needs is people trying change the architecture or questioning choices that were made 10 years ago -- it gives impression that their technology is already old legacy stuff and such messages going around in the team can make developers unhappy about the current situation
4. Thus in an interview, the last thing you should do is give impression that you're going to complain all the time about the choices the team has no control over