Good Architecture Interview Questions [closed]

Question

Architecture is one of those things that isn't simply a trivia question (e.g., design pattern uses) and is a lot more subjective than other interview topics. There often isn't a single correct architecture so that makes it trickier to evaluate someone. The most you can get is an idea of how the interviewee thinks.

I would suggest that you describe to the interviewee a complex product or part of a product that you (the interviewer) are most intimately familiar with. Then ask him to think of how he would architect it and explain his reasoning, and then focus on specific decisions and ask questions.

Of course, only do this if:

• You are open to hearing other designs that are not your own.
• You are able to take potential criticisms and acknowledge that your own design might be imperfect

An added bonus is that you would see how you might handle disagreements if he is hired.

An alternative approach if your product has ever been rearchitected is to describe the architecture of the old version and ask the interviewee how he would rearchitect it. If the result is close to the current architecture, it is likelier that the candidate would be a good fit with the style and mindset of your group.

1. Ask who in the "community" they follow and admire for their architectural ability and why? This will give you an indication of the philosophical bent of their architectural style. Also, if they can't name anyone or why they admire them, that's a big red flag because they clearly aren't keeping up with the communities best practices and advances.
2. Ask them to name some problem/con/tradeoff with an architectural design pattern relevant for the interview. It they can't do this, this is a red flag as they may be unconsciously incompetent (ie: a fanboy) as opposed to having real experience and insight in this area. It is a lot easier to name the advantages posed by a given architecture, whereas really understanding the disadvantages requires deeper insight.

Assuming that you have already checked them out for culture/personality fit and development skills, I would suggest doing the following:

1. Ask the candidate to describe the architecture of a medium-to-large scale system that they actually designed and/or implemented. Ask probing questions around the design tradeoffs they made.

2. Provide the candidate with the design of a system that has more than a few known flaws. It can be one you made up or one that is well-known to all. Ask the candidate to identify the flaws and redesign the system, assuming they had no time or money constraints.

3. Present the candidate with a set of requirements for a non-trivial system (i.e. a distributed system for reviewing medical images in a hospital environment) Have them whiteboard the components of the system in increasing levels of detail until you feel comfortable with their ability to elicit requirements from the stakeholder (you) and make appropriate tradeoffs in their design.

None of this will guarantee that you'll select the best "architect" (I have the same issue with the title architect as Joel and Jeff do). However, these are definitely good filtering techniques and should help you identify someone with worthwhile characteristics for your team.

"So, I'm not going to jerk you around here: can you tell me something that will convince me that you know a lot about architecture?"

I'm a little concerned by your question. At first blush, I'd suggest something along the lines of "please describe the influences of the midwest prairie forms on modern arts and crafts designs".

Removing tongue from cheek, I would suggest what Chris did above. Provide the candidate with an opportunity to interact with you and your team on the design of an architecture relevant to your work. If you don't feel equipped to judge their competence based on seeing them solve problems instead of canned problems, you NEED to get somebody else involved in the interview. Or else take a page from the book of Joel and Jeff and scratch the term "architecture" and start looking for competent software engineers.

In my opinion, ability to design or "architect" is a skill, not a set of knowledge. Asking them a bunch of questions like "what are the performance ramifications of using J2EE vX vs J2EE vY" or "which is better, CORBA or RMI" is just going to make you look silly.

The problem with asking questions like this is that there's not really a 'right' answer, so the main thing is to get the candidate start talking. I would ask them to describe an architecture that they've implemented that they are proud of. And then follow up with things like, 'what about it are you most proud of?'. And you can then ask them what mistakes they've made in the past, that sort of thing.

I feel more comfortable about that because you getting a feel for the person, and not their ability to answer a canned question.