30 Software Architect interview questions and answers

30 Software Architect interview questions and answers

If you are a software engineer with many years of experience under your belt and are looking for the next step in your career, one of the options you could take is to apply for a Technical Architect position. Interview process for this position is generally different compared to a software developer interview. You will need to show a different set of skills, which are usually not required for an engineering position, so you might want to practice them in order to display your best knowledge.

I have worked as a Technical Architect for a numerous companies and went through this process multiple times myself. I was also involved in the hiring process for new Technical Architects, so I know how this process looks like.

In this article I will try to explain what the process looks like and what I am looking for in a candidate. The article also contains a list of questions and some answers you might be asked in the interview process for a Software Architect.

But before we dive into that let us quickly run over how a career progression might look like, so you can better understand if this is the right step for you.

Career progression overview

The career path for a software engineer looks somewhat like this:

  • Junior / Associate developer
  • Developer / Engineer
  • Senior developer
  • Lead developer

After this point the career path splits up into multiple options, which are:

  • Principal Engineer
  • Technical Architect
  • Engineering manager

Please bear with me, this is not how every company is doing it, and there some companies don’t have certain roles, or even have more levels, something like Developer level 1 and Developer level 2 and so on.

Lets dive a little bit into the three options you might have as a next step if you are currently a Senior or Lead developer.

Principal Engineer

Principal engineer is in some companies a super experienced engineer, who works on improving the standards across the entire organisation and multiple teams and in some companies that role might be much closer to that of a Software Architect where he designs applications and systems. I will describe it more in details in the following section.

Software Architect

Technical/Software Architects job is basically to design highly scalable systems, to take care about different integrations between systems and have a long term technical direction in mind. You will have to understand large projects and find the best way to migrate it to a new more suitable technology.You will be doing a lot of white boarding stuff you will be drawing diagrams and you will have meetings with stakeholders where you will have to present your plan. But the most difficult part will be, how to get engineers to do what you designed.

Engineering Manager

A Engineering Managers job is to manage a team of engineers. You should be technical and in most cases you will still have to be hands on to some extent. You will have a say in what the team is working on and you will directly line manage your engineers. This means you will be doing weekly one to ones, performance reviews and reports, manage any potential tensions and negative behaviour. You will have to work closely with stake holders and go to a lot of meetings.

Now after briefly explaining what options there are and roughly what you would be doing there and you 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 best prepare for the interview.

Technical Architect, Solutions Architect, Platform Architect, AWS 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 my personal and professional 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.

You need to have experience working on many different large scale projects, different teams of different sizes, preferably for multiple different companies.

Software Architecture – The Difference Between Architecture and Design

First you truly need to understand what is Software Architecture and what is Software Design.

The Definition of Software Architecture

By definition, software architecture is the process of converting software characteristics such as flexibility, scalability, feasibility, reusability, and security into a structured solution that meets the technical and the business expectations. Now this definition might be ambiguous as it doesn’t tell you anything unless you truly understand all the terms mentioned.

What is Software Design

While software architecture is responsible for the skeleton and the high-level infrastructure of a software, the software design is responsible for the code level design such as, what each module is doing, the classes scope, and the functions purposes, etc.

The basic technical terms you must understand in an interview

1. DNS

“The Domain Name System is a hierarchical and decentralised naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities.”

Source Wikipedia

2. Load Balancer

“A load balancer is a device that distributes network or application traffic across a cluster of servers. Load balancing improves responsiveness and increases availability of applications.

A load balancer sits between the client and the server farm accepting incoming network and application traffic and distributing the traffic across multiple backend servers using various methods. By balancing application requests across multiple servers, a load balancer reduces individual server load and prevents any one application server from becoming a single point of failure, thus improving overall application availability and responsiveness.”

Source Citrix

3. Web Application Servers

“A web server‘s fundamental job is to accept and fulfils requests from clients for static content from a website (HTML pages, files, images, video, and so on). The client is almost always a browser or mobile application and the request takes the form of a Hypertext Transfer Protocol (HTTP) message, as does the web server’s response.”

Source NGINX

4. Services

Once an app reaches a certain scale, there will likely be certain “services” that are carved out to run as separate applications. They take care of a specific problem and nothing more. They’re usually not exposed to the external world but the app and other services interact with them. This transition can be continued to micro services and even further to nano services.

5. Database Servers

“A Database Server is a computer in a LAN that is dedicated to database storage and retrieval. The database server holds the Database Management System (DBMS) and the databases. Upon requests from the client machines, it searches the database for selected records and passes them back over the network.”

Source Ecomputernotes

6. Caching Service

“In computing, a cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.”

Source Amazon AWS

7. Job Queues

“In system software, a job queue, is a data structure maintained by job scheduler software containing jobs to run. Users submit their programs that they want executed, “jobs”, to the queue for batch processing. The scheduler software maintains the queue as the pool of jobs available for it to run.”

Source Wikipedia

8. Full-text Search Service

While it’s possible to do full-text search directly from some databases (e.g., MySQL supports full-text search), it’s typical to run a separate “search service” that computes and stores the inverted index and provides a query interface. The most popular full-text search platform today is Elasticsearch though there are other options such as Sphinx or Apache Solr.

9. Data

Today, companies live and die based on how well they can harness data. Almost every app these days, once it reaches a certain scale, leverages a data pipeline to ensure that data can be collected, stored, and analysed. Data is digital gold of todays age.

10. Cloud storage

“Cloud storage is a cloud computing model that stores data on the Internet through a cloud computing provider who manages and operates data storage as a service. It’s delivered on demand with just-in-time capacity and costs, and eliminates buying and managing your own data storage infrastructure. This gives you agility, global scale and durability, with “anytime, anywhere” data access.” according to AWS.

11. CDN

“A content delivery network (CDN) refers to a geographically distributed group of servers which work together to provide fast delivery of Internet content. A CDN allows for the quick transfer of assets needed for loading Internet content including HTML pages, javascript files, stylesheets, images, and videos. The popularity of CDN services continues to grow, and today the majority of web traffic is served through CDNs, including traffic from major sites like Facebook, Netflix, and Amazon.”

Source Cloudflare

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 white-boarding 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 some practice and understand it better.

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?

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

  • How would you design system X from scratch
  • How would you refactor system X
  • How would you debug/profile and fix application 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 very reason very.

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 before you even start designing the application that makes sense. 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.

Example

Application X needs an Auth Service, a Checkout service, a Database, CDN,… See this are technology terms, they are not frameworks or specific technologies. When you start with a high level design you don’t know what will be the best technology for it, that part comes later.

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. This is a big red flag for me. It tells me that you might be just a framework developer, and I will start drilling what other technologies could be used to solve this problem.

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, but only if you generally have experience in that field. Don’t try to learn it and pretend you understand it. Trust me, if the company works with some technology, it’s pretty easy for them to recognise if you don’t have any experience.

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 specially with the rise of full stack developers where companies run JS on frontend and on backend.

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, but I have definitely been asked about this types of questions.

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.
🔗Source: scotch.io

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.
Source: Atlassian

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 types 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.

Some examples of design patterns

  1. Layered pattern
  2. Client-server pattern
  3. Master-slave pattern
  4. Pipe-filter pattern
  5. Broker pattern
  6. Peer-to-peer pattern
  7. Event-bus pattern
  8. Model-view-controller pattern
  9. Blackboard pattern
  10. Interpreter pattern

Here is a good article by Vijini Mallawaarachchi explaining them 10 Common Software Architectural Patterns in a nutshell.

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.

Source: fromdev.com

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

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.

Security

Security in software is a big thing, trust me, you need to have at least basic understanding of how you can implement security in software.

You need to know what owasp top 10 security risks are:

  1. Injection
  2. Broken Authentication
  3. Sensitive data exposure
  4. XML External Entities (XXE)
  5. Broken Access control
  6. Security misconfigurations
  7. Cross Site Scripting (XSS)
  8. Insecure Deserialization
  9. Using Components with known vulnerabilities
  10. Insufficient logging and monitoring

You need to understand how to implement authentication in an Application. What is the difference between Session Based Authentication and Token Based Authentication?

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