Software Architect interview questions and answers – entire process

Software Architect interview questions and answers – entire process

If you are someone who would like to get a job as a software architect, you are at the right place to get some guidance and tips on how to prepare for the interview.

Technical Architect, Solutions Architect, Platform Architect

What is the difference between this terms? There are many terms in use but they are mostly for the same type of work, one could argue that Platform Architect cares more about the platform, but it depends. First of all, it all depends on the company so you should always check the job description and what the company does.

I have also seen other titles such as Frontend Architect or Cloud Architect, both of them are more specific about where the bulk of the work you will be doing will be.

Software architects salaries are usually higher than software engineers, so it makes sense that people want to get into this position. They are usually on the level of a principal engineer and some companies even have their principals doing the work of an Architect. This means that this is the highest level of a contributor you can get in a given company. The only way higher I would say is that you also start managing teams. However some companies are paying salaries comparable to senior management to their architects, especially when they have proven their value to the company.

My Experience with Software Architect interviews

As a software architect myself I was subjected to several interviews and I also interviewed a lot of candidates, so I can tell you from personal experience what we are looking for in our candidates.

First of all you need to understand that companies have different requirements and different approaches on hiring technical architects and I can speak only from what I experienced and what I practice.technical architect questions

Commercial and Industry experience

Now before you apply you should know that to get a software architect position you need to have considerable experience in engineering and for some companies even specific domain industry experience. If you are a Junior developer I have bad news, that you will have to get some years of experience under your belt before companies would be likely to hire you. Off course there are exceptions here if you have done something amazing and are a brilliant engineer, but I am talking here about how most people progress into this field.

Whiteboard exercise

Before I go into specific questions you might encounter I would like to give you some insights about the whiteboarding session. In my opinion this is the most important part of the interview and it also tells me the most about the candidate. It tells me how the candidate approaches a problem, how he thinks, how much experience he has and so on.

In all of my interviews and every interview I did there was a whiteboarding exercise. This is nothing to be afraid off if you have some practice on how to do this type of exercise. So please do some whiteboard exercise at home to get a good understanding of it.

By practicing I mean, try to design a system on a piece of paper and ask a fellow engineer if he understands it. There are no strict rules about how to draw a system on a whiteboard. The most important thing is that it needs to be understandable, easy to read and make sense. The more systems you will design the easier it will become.

What are the usual problems you get that you need to solve?interview questions

From my experience there are 3 types of problems you could face:

  • How would you design X from scratch
  • How would you refactor X
  • How would you debug/profile and fix X

Now regardless of the type of problem you have to have a systematic approach to the problem. Don’t just jump into solving the problem, that is something that I see all the time and people fail the test for this reason very often.

The first thing you need to have is as much information as possible. I like to see my candidates ask a lot of questions before they even start doing anything.

You have to have a clear picture of the problem with all the requirements to make a good decision. Sometimes the requirements are defined better and sometimes you get just a broad problem, but you always can ask for more details, this is nothing wrong and it does not mean that you do not know the answer to to the problem. It just tells me ok this person knows that this is a complex problem to solve and the only way to make an informed decision is to ask as many questions as possible.

Second tip is to not think about a specific technology. I am not interested if you would do this in Java, JavaScript, GO or something else at this point. Try to find a technology agnostic solution. Unless you are actually asked about it don’t try to make any decision on technology.


This application needs an Auth Service, a Checkout service, a Database, CDN,…

Don’t say I would build this with React in the frontend and node in the backend, this doesn’t tell me anything, even tech recruiters would know to tell me this.

Next steps in the interview process

Some companies have specific requirements about technologies you need to know. Now there are many different technologies and it is not in the scope of this article to explain all of them. What I can recommend is that you check the job description and try to find out which technologies that might be. Once you know, just google what are the most common questions for that technology.

What are the most common programming languages that an Architect should know

The majority of companies will still have Java in their requirements. Java is closely followed by C# and the .Net ecosystem, however I see more and more that JavaScript with Node.js experience is also on the rise.

Principles, concepts and standards

Now this type of questions are also quite common. I usually don’t ask them, or at least only the most well known as they are highly theoretical and if someone memorises them this doesn’t help him being a better architect.

Some example questions:

  • What does SOLID stand for? What are its principles?
  • What are the differences between continuous integration, continuous delivery, and continuous deployment?
  • What is Dependency Injection?
  • What are acid transactions?
  • Explain what is DDD domain driven development
  • What kind of design patterns do you know
  • What Does Eventually Consistent Mean?

What does SOLID stand for? What are its principles?

S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin.

S – Single-responsiblity principle. A class should have one and only one reason to change, meaning that a class should have only one job.
O – Open-closed principle. Objects or entities should be open for extension, but closed for modification.
L – Liskov substitution principle. Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
I – Interface segregation principle. A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.
D – Dependency Inversion Principle. Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

What are the differences between continuous integration, continuous delivery, and continuous deployment?

Developers practicing continuous integration merge their changes back to the main branch as often as possible. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.
Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.

What is Dependency Injection?

In software engineering, dependency injection is a technique whereby one object supplies the dependencies of another object. A dependency is an object that can be used. An injection is the passing of a dependency to a dependent object that would use it. The service is made part of the client’s state. Dependency injection is also a creational design pattern.

What are acid transactions?

In computer science, ACID is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc. In the context of databases, a sequence of database operations that satisfies the ACID properties is called a transaction.

Explain what is DDD domain driven development

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.

In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.

What kind of design patterns do you know

There are three basic kinds of design patterns:

  • structural
  • creational
  • behavioural

Structural patterns generally deal with relationships between entities, making it easier for these entities to work together.

Creational patterns provide instantiation mechanisms, making it easier to create objects in a way that suits the situation.

Behavioural patterns are used in communications between entities and make it easier and more flexible for these entities to communicate.

What Does Eventually Consistent Mean?

Unlike relational database property of Strict consistency, eventual consistency property of a system ensures that any transaction will eventually (not immediately) bring the database from one valid state to another. This means there can be intermediate states that are not consistent between multiple nodes.

Eventually consistent systems are useful at scenarios where absolute consistency is not critical. For example in case of Twitter status update, if some users of the system do not see the latest status from a particular user its may not be very devastating for system.

Eventually consistent systems can not be used for use cases where absolute/strict consistency is required. For example a banking transactions system can not be using eventual consistency since it must consistently have the state of a transaction at any point of time. Your account balance should not show different amount if accessed from different ATM machines.


Software -ilities

This is a list of things you should know and be able to explain them.

  • Usability
  • Maintainability ( or Flexibility / Testability)
  • Scalability
  • Availability (or Reliability)
  • Extensibility
  • Security
  • Portability

AWS Network Architecture Diagram

The cloud

With the rise of cloud solutions, there is a ever increasing need for architects with cloud experience. It is very beneficial to have some sort of cloud experience under your belt. Currently there are two main players, AWS and Azure. While both of them offer similar services there are distinctions between them.

I personally would not hire a Architect with 0 experience with the cloud providers. And saying that you set up your blog on an EC2 will let me know that you don’t know what the cloud providers are offering. It is not simply a hosting provider.

What I would expect you to have an idea of for AWS for example:

If you understand what the majority of this services do, than you are on a good way to get a job with me.

There will also be other type of questions like they are on every other type of interviews but this is also not in the scope of this article. I wanted to focus purely on the specifics of questions that you might be asked on the interview for a Software Architect position.

Expand your Engineering and Architecture knowledge with this books

In order to broaden you knowledge you can also read some books that will give you a really good understanding about software development and architecture in general. Here is a must read list of books every Software Architect really should read. They are not specifically written for architects, but can give you solid foundation for and software engineering position.

And if you want to read more about this topic, I would really recommend following Martin Fowler he is one of the leading authorities in this space. You can find a lot of Youtube videos with his talks.

I am well aware that there might be other approaches and that I didn’t put everything here, purely because I am not aware of it. However if you have experienced something I haven’t mention please let me know in the comments below.

Leave a Comment