Architect Interview Questions

1. What are the important responsibilities of Architect?
2. How should an ideal architect be like?
3. What are the modern programming practices an architect should be aware of?
4. How do you ensure that the Code Quality is maintained?
5. How do Agile and Architecture go hand in hand?
6. How do you ensure the team is following sound engineering practices?

What are the important responsibilities of Architect?

Below is a high level summary

• Creating a clean architecture based on sound principles. Architecture covering all Non Functional Requirements.
• Having good governance in place. Good review processes in place for Architecture, Design and Code.
• Ensuring teams are as productive as they can be. Right tools.
• Ensuring teams are following the best engineering practices.
• Ensuring clear communication about architecture with business and technical teams.

How should an ideal architect be like?

Most important qualities I look for in an Architect are

• Impeccable Credibility : Somebody the team looks up to and aspires to be.
• Super diagnostic skills : The ability to do a deep dive on a technology issue. When developers are struggling with a problem (having tried different things), Can he/she provide a fresh pair of eyes to look at the same problem?
• Forward Thinker and Proactive : Never satisfied with where we are. Identifies opportunities to add value fast.
• Great Communication : Communication in the widest sense. Communicating the technical aspects to the stakeholders, project management, software developers, testers, etc.

What are the modern programming practices an architect should be aware of?

For more details refer to design interview questions.

How do you ensure that the Code Quality is maintained?

More than everything else, code quality is an attitude. Either, the team has it or not. The attitude to refactor when something is wrong. The attitude to be a boy scout. As an architect, it is important to create an environment where such an attitude is appreciated. (There are always bad sheep, who take the code quality to such depth that it is not fun anymore, but I like them more than developers who keep churning out bad code).

Have a good static analysis tool(and is part of Continuous Integration). Sonar is the best bet today. Understand the limits of Static Analysis. Static Analysis is not a magic wand. For me, results from Static Analysis are a signal: It helps me decide where I should look during peer or architect reviews?

Have good peer review practices in place. Every user story has to be peer reviewed. Put more focus on peer reviews when there is a new developer or there is a new technical change being done. Make best use of Pair Programming. The debate is ongoing : Is pair programming more productive or not? I would rather stay out of it. You make your choice. However, these two scenarios are bare minimum:

• Onboarding a new programmer. Makes him comfortable with all the new things he has to encounter.
• Implementing a complex functionality.

Next question is how to approach a Code Review. Difficult to cover everything. I would make a start. When doing a code review, I start with static analysis results (for example, sonar). I spend 10 minutes getting an overview of components and/or layers (focusing on size and dependencies). Next I would pick up a unit test for a complex functionality. I feel unit tests are the best place to discover the dependencies and naming practices (I believe good names = 50% of maintainable code). If a programmer can write a simple and understandable unit test, he can definitely write good code. Next, I look for 4 principles of Simple Design. After this, there are 100 other things we can look for - You decide.

How do Agile and Architecture go hand in hand?

First of all I’m a great believer that agile and architecture go hand in hand. I do not believe agile means no architecture. I think agile brings in the need to separate architecture and design. For me architecture is about things which are difficult to change : technology choices, framework choices, communication between systems etc. It would be great if a big chunk of architectural decisions are made before the done team starts. There would always be things which are uncertain. Inputs to these can come from spikes that are done as part of the Done Scrum Team.But these should be planned ahead.

Architecture choices should be well thought out. Its good to spend some time to think (Sprint Zero) before you make a architectural choice.

I think most important part of Agile Architecture is Automation Testing. Change is continuous only when the team is sure nothing is broken. And automation test suites play a great role in providing immediate feedback.

Important principles for me are test early, fail fast and automate.

How do you ensure the team is following sound engineering practices?

I ask the following questions:

• How often is code committed?
• How often is code released?
• How often do builds break? Are they immediately fixed?
• How often is code deployed?
• What steps are part of continuous integration build? Is deployment and automation suite part of it?
• Does the team develop vertical slices when implementing a new functionality?

More questions are covered in the section on Design Interview Questions.