Exercising sound judgment consists of the ability to incorporate your past experiences, stakeholder needs, priorities, facts, and constraints to arrive at a decision that is going to be the most beneficial for the organization. It requires the ability to deal with situations in a realistic and sensible way, even if theoretical wisdom would advise taking a differing solution. You need to be able to deal with ambiguities to help figure out which items are truly important.
There are a couple of reasons an interviewer may ask this question. One is to determine your level of understanding of the current architectural landscape. The other is to determine your level of context awareness. Are you able to realize when there might be a better way to do something?
A good response will indicate that you have a solid understanding of the current architecture. You should also have an idea of something significant that could be changed to make the architecture better. If you have specific examples of how you acted on an idea to implement an architectural improvement, be sure to mention it.
A poor response is one that is so trivial that it really doesn't provide much added value. This is usually an indication that a candidate hasn't reached an engineering maturity to think at an architectural level. They would likely struggle with tasks that involve some level of design and architecture.
This is a question that helps determine a candidate's awareness of the overall technology landscape. While the question is rather open-ended and fairly large in scope, it creates a starting point for architectural conversations. There are a number of key characteristics that will be demonstrated by the candidate during this exchange.
A good response will exhibit a number of the following characteristics.
A poor response may exhibit some of the following characteristics.
The interviewer is trying to gauge a candidate's understanding of business context. Ultimately, engineers and architects need to be the gatekeepers of product quality, but there may be real-world situations where technology tradeoffs need to be made because of an urgent business need. Maybe a product needs to make an extremely fast entry into the market to capitalize on a specific market opportunity.
The pace of technological change has dictated that organizations are able to adapt very quickly to changing business needs. As outlined in The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries, it is extremely important that there is a very tight feedback loop in the Build-Measure-Learn process. Sometime when producing new products, it may necessary to put out a product that has significant technology deficiencies, with a plan to re-architect future versions. In these types of situations, the learning from the customer feedback may be more important than the product architecture, as the actual product may be re-architected using information learned during the initial release.
However, if the functionality in question would require a technical hack to a core piece of the technology framework, there should be some very serious conversations about the technical implications. In these sorts of situations, it should require an extremely compelling argument from the business folks before the technical gatekeepers would agree to implement a solution that could damage the ability of the platform. Additionally, it is extremely dangerous to give the engineers the impression that it is acceptable to check in garbage code because 'It works'. Andy Hunt and Dave Thomas talk about the dangers of the Broken Window Theory in their book The Pragmatic Programmer: From Journeyman to Master. In these situations, the benefits of producing an inferior product faster are far outweighed by the maintenance and support cost of implementing a poor technology decision.
While every situation is unique, and there isn't a prescriptive answer about whether the business needs or the technology needs are more important, there are a few things that the candidate should demonstrate when addressing this question.
It is important that a candidate consider both the technical and business factors when making design decisions. Candidates who will make product changes for the business without regard for the effects to the technology platform will create a product that will soon become unmaintainable.
Candidates who are so religious about an implementation that they won't consider alternatives when business needs dictate a different solution are similarly unproductive. While it is good for a candidate to have a passion for creating a great technological solution, it is important that they don't become so focused on the solution that they don't attempt to understand why the solution is important. Candidates who have trouble with the business context often have trouble understanding the technology context as well. A good engineer will usually consider a wide range of factors and constraints, both business and technical, when make technology decisions and choices.
If you had the choice to use Chef, Puppet, Docker, Ansible, or something else for configuration management, what would you choose? Why?
The interviewer is attempting to see how a candidate makes a choice between competing products. They may also ask this question of products that are actually complimentary. While the interviewer may or may not have a specific preference, they are looking for the candidate to articulate a logical explanation on why they would chose one over the other.
A good response will exhibit a number of the following characteristics.
If a candidate is not able to articulate the pros and cons of both technologies, or only understands one technology well, it may be an indication that they lack intellectual curiosity and passion to discover whether another product would work better in a particular context. It may indicate that once they become comfortable with a particular technology, they are resistant to change or new ideas.
Thanks for reading (this sentance)! This is the section where I ask you to do things that will have no apparent benefit to you (like sharing this article). However, if you thought it was a good article (I was going to say 'great article', but figured that I would probably be setting the bar too high), sharing it will make you look smart amoung your friends. If you thought it was terrible, you could still share it (and ask your friends if they think it's as terrible as you do). In either case, you will continue to impress your friends with your ability to discern a good article from a bad one. And as a side benefit to me, it might increase (if only for the briefest moment), the incredibly meager visitor traffic and rather terrible SEO ranking that is currently possessed by this site.
However, if asking you to share a bad article (or even just an 'OK' one) would cause too much damage to your stellar reputation, you can still help more anonymously. If you found the slightest thread of value in this post, you could read one more article from this site. This would help my bounce rate, which is hovering just under 100% (if you're not familiar with the metric, that's a pretty poor number). Of course, if you found this article totally worthless, I would suggest not coming back. While the quality of the articles may improve as I get more practice, I really doubt if they'll improve enough to change your mind.