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.

  • 22
    I've never had to do it, but that kind of behavior on an interviewer's part would be met with "I'm sorry, you have failed the interview" followed by my departure.
    – Blrfl
    Commented Nov 12, 2011 at 17:16
  • 15
    I think you just explained why it is good to probe on arhictectural choices. It is better to find these things out before you've committed to a new job. I would however speak to the HR person before leaving the interview so that they can be aware of why you've left.
    – Lou
    Commented Nov 13, 2011 at 1:08
  • 6
    I've very limited interviewing experience, and typically I'll meet the candidate after (s)he had successfully dealt with the HR people. One candidate initiated an architectural discussion during the interview, and he actually identified a few things we could improve. When he got his first paycheck he was amazed to see that it included a second check for the couple of hours of the interview. The sad thing is that if he had probed the HR people, I'd probably never meet him.
    – yannis
    Commented Nov 13, 2011 at 3:50
  • 3
    I probably wouldn't ask "why use this over that". You just don't know. Instead you may just want to ask, "what was the decision behind using x language?"
    – Matt
    Commented Nov 13, 2011 at 6:39
  • 2
    I think my favorite part of the story is "When prompted to ask questions". So he asked if you had any questions, and then blew up when you did?
    – jhocking
    Commented Nov 14, 2011 at 12:59

10 Answers 10


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.

  • 12
    I agree fully with this, even more so about telling the truth on both sides of the table. The last thing you want to do is sell a bill of goods to interview candidates and wind up with an environment full of malcontents. Commented Nov 12, 2011 at 16:36
  • 3
    Hell. freaking. yes. Commented Nov 13, 2011 at 19:13
  • 1
    If it's exhausting, you interview too much. In my company we have 30-odd interviewers, so we only get to do an interview every couple of weeks or so, and not at all if we're too busy. I like interviewing. It's a break from the routine. Commented Nov 14, 2011 at 16:06
  • 1
    @configurator: Nah, it's not that I do too many interviews, it's that I find one interview to be tiring. Although, I am an introvert, so that might be part of it.
    – pdr
    Commented Nov 14, 2011 at 16:25

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?)

  • "It is easy to come across as challenging their decisions" - This is exactly what I was thinking after the interview, but it was a simple technical question and I phrased it in a polite manner. I was simply curious why they chose technology x over technology y. Technical interviews (in my experience) always try to show your interviewers your analytic skills and how you address problems. Why someone would think that is a one-way street makes me question his communication skills. Commented Nov 12, 2011 at 17:14
  • 3
    You also need to factor in your personality. If you are a coworker that questions/challenges other people's decisions its better to find out how your future coworkers react to that sort of thing during the interview. Some cultures encourage disagreement and others do not, and as an interviewee I would want to know how that dynamic works. Commented Nov 12, 2011 at 17:29
  • 23
    You should be able to ask any question you want without the interviewer yelling and getting bent out of shape. Would you really want to work under that person's leadership? Walking out without taking the guy's head off first impresses me, but walking out is the only correct option in this situation. Commented Nov 12, 2011 at 18:38
  • 1
    Would I want to work under that person's leadership? Not unless I was on the verge of making my kids homeless. But that point is irrelevant -- the question wasn't "how do you handle an interviewer who is a jerk?", it was "is it wise to ask about design decisions?". Even if the interviewer is a jerk, there are ways to handle the situation. Commented Nov 12, 2011 at 21:23
  • @BryanOakley - Glad someone spotted that, it was a typo in the question. I've reworded it so it makes sense. This was about 2006 when EJB 3 was still in it's infancy and most developers were rather unforgiving about the issues with the specification driven EJB 2 and had opted to stay with the community driven Spring framework. That was the rational behind the question, this was the one company that I faced that didn't go with the status quo and I was curious as to why. I expected some wisdom in an answer, not to have my face chewed off. Commented Nov 12, 2011 at 23:31

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.

  • 2
    How to find companies like yours... Or is it just luck?
    – Erica Xu
    Commented Nov 12, 2011 at 21:09
  • 5
    You can usually find clues in the job description. The less their requirements look like a laundry list of technology alphabet soup and the more it's about the kind of person they want to hire, their development philosophy, and what they're trying to accomplish, the more likely they are to be interested in people who are smart enough to make, and eventually revisit, decisions. If there is such a thing as luck, it may be a factor, but your skills and ability to judge people (and lack of desperation for a job) will come into play too.
    – JasonTrue
    Commented Nov 13, 2011 at 3:09

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.

  • Isn't this answer too restrictive?I mean if the position is for a senior or technical leader it is fine.But a somewhat inexperienced engineer, why would he want to start asking questions on design decisions?
    – user10326
    Commented Nov 13, 2011 at 18:26
  • 2
    @user10326 - As you pointed out, the interviewee may well be inexperience and is looking for insight to learn why a company adopted certain technologies. It's one thing to read on a webpage what a technology has to offer and it's another to listen to how a company had applied it to their business processes and how it's paid off. At the end of an interview when I'm asking questions, I like to hear developers opinions on things as well as things they don't agree with. Commented Nov 13, 2011 at 21:02
  • 1
    @user10326: One of the most compelling candidates I've ever interviewed was fairly junior (less than 2 years). Half way through the interview, he asked a question. I answered. He said "do you mind if I run through a few more questions?" and pulled out an A4 sheet. Heck of a gamble but, for me, just by asking the right questions, he showed a very strong knowledge of what makes for good software development. It was all theoretical to him, and he knew it, but he was looking for a place where he could practice it.
    – pdr
    Commented Nov 14, 2011 at 0:28
  • 2
    Even a junior can sometimes have ideas about things, and has a right to question completely insane decisions. Commented Nov 14, 2011 at 15:41
  • 1
    @Wayne M or just be interested in the subject and want to understand the reasoning behind decisions. Commented Nov 14, 2011 at 16:57

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: 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.

  • 2
    I agree with your interpretation. I would just ask "How did you go about choosing technology X"
    – barjak
    Commented Nov 14, 2011 at 17:17
  • I partially agree with this. The word 'How' sounds more humble than a 'Why'. Even so, if you use 'how' at the beginning of questions, that could also be taken as you trying to psychologize their thinking behind opting to go for one technology over another. If I'm in an interview and find people asking me lots of 'why' questions, I'll normally ask a few 'why' questions back again. Judging by the behavior of the person who lost his tempter, any changes in the question probably would have made no difference no matter how humble it came across. Commented Nov 14, 2011 at 21:48
  • 1
    This is probably the case. However, I just wanted to make it clear that it is a different question. The "how" question suggests that you want to understand their methodology (they would probably touch on the "why" in their answer). Maybe they performed a POC on each technology and decided which would fit their situation best or maybe they just flipped a coin. The "why" question would seem to be requesting the actual reason that they chose one over the other.
    – smp7d
    Commented Nov 14, 2011 at 22:12

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.


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.


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.


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
  • 5
    ok. So what gives an interviewer the right to ask me those kinds of questions? Commented Nov 12, 2011 at 17:57
  • 8
    Asking a question does not imply that you think they were wrong. Even if they were wrong, I'm not going to be scared off a company who is honest about why they made mistakes. Not every decision I have made was correct in hindsight. I may be scared off a company who doesn't let technical people make technical decisions, but those companies don't want me, because I will fight what I see as a systemic problem. And that's all fine -- everyone gets what they want. So is it still unwise to ask?
    – pdr
    Commented Nov 12, 2011 at 18:35
  • @DesolatePlanet, tp1 gives some good reasons that the question might be unwise. It's not that you don't have the right to ask it, it's that it might not be the smartest move for the reasons given. As it turns out, it was a great question in this case -- it revealed a personality that nobody would want to have to work with.
    – Caleb
    Commented Nov 12, 2011 at 19:39
  • The main problem is questioning architecture choices. Architecture is decided once and then it's fixed for 10-20 years. It just cannot be changed. Good developers know when something is impossible to do. Focus your efforts to changing something which makes a difference. Jumping from one legacy platform to another is not productive.
    – tp1
    Commented Nov 12, 2011 at 21:44
  • 4
    He's asking the reason of the choice of the architecture, not why didn't they change it later! Commented Nov 12, 2011 at 22:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.