Main image of article Solutions Architect: Must-Ask Interview Questions

Solutions Architects are tasked with figuring out how to structure a project or system. It’s a job that demands abstract thinking, and touches on an array of different hardware and software platforms – everything from storage and the cloud to machine learning and AI.

The Solutions Architect role is largely dependent on the unique technical and business needs of an organization. So, when interviewing for this role, you’ll want to look for a professional who can do all of the following: provide hardware and software selections that will have the best impact on a business outcome, demonstrate a solid understanding of the business itself, and communicate effectively with internal teams and customers.

Use these questions to interview Solutions Architects and uncovering a standout hire.

Interviewing another position? Check out Dice’s library of interview questions.

Interview Question: "What steps would you take to communicate to a customer who doesn't agree with, or who may not understand your assessment?"

Why you should ask: Solutions Architects need to listen effectively to customers and learn about their needs so that they can recommend the right solution to them. They also must be able to help customers understand why they are making a particular recommendation. This question will shine a spotlight on a candidate’s interpersonal abilities – in this case, whether they can clearly present their vision to others.

An answer you’d hear from a standout candidate: Let me tell you about the time when… (Note: Experienced Solutions Architects will have plenty of examples of when they had to go the extra mile to articulate to customers why the course of action they were recommending would work – and work best.)

Interview Question: "What are some arguments for and against PaaS-oriented development?"

Why you should ask: You’re essentially asking the Solutions Architect candidate if it’s better to build or buy a solution. Platform-as-a-Service (PaaS) and Infrastructure-as-a Service (IaaS) solutions can help save time in bringing a new product to market. But an experienced Solutions Architect knows that these solutions have limitations and can be difficult to integrate and maintain, especially if they aren’t enterprise-grade.

An answer you’d hear from a standout candidate: PaaS has time-to-value cost savings, and eliminates the need for network, database and OS administrator solutions. However, the components of PaaS technology are often difficult to debug and even deduce best practices usage. And while the technology is good for prototyping, it often poses issues for taking the application – or even machine learning mode – to a production level of runtime performance.

Interview Question: "What are the differences between RDBMS and NoSQL, and why would you choose one over the other?"

Why you should ask: Solutions Architects, when architecting solutions, must evaluate data storage and management to ensure they are delivering the best fit for the organization’s needs. By asking this question, candidates must explain their understanding of the strengths and weaknesses of each database, and how and why they would choose one over the other.

An answer you’d hear from a standout candidate: RDBMS (SQL) encompasses relational databases that are a good fit for structured data, while NoSQL encompasses flexible, nonrelational databases that work well for complex, large-scale data. But choosing one kind of database over another is entirely dependent on context and needs.

RDBMS databases can be used for a wide variety of applications, as long as the database model and its structure remain consistent. For example, reporting and transactional use cases are more suited to SQL databases.

NoSQL databases, such as MongoDB and CouchDB, don’t require consistent data structure, and work well if a database layout changes often. They’re flexible and known for scalability. For example, online catalogues, user profiles and storing and fetching JSON strings are all well-suited to NoSQL databases.