Software architect interview questions, with worked answers

How to use these questions

Architecture questions rarely have one right answer, so the interviewer listens to how you get to yours. Practise saying the qualities you are optimising for before you name a technology. Bring two or three decisions of your own, including one that turned out wrong and what you learned.

What a software architect is expected to know

• Trade-offs and qualities: performance, availability, security, cost and changeability, and how to make each measurable.
• Structure: modular monoliths, microservicesAsked in 4% of software architect ads (as of 5 Nov 2026).Know when splitting a system into services pays off, and the operating cost it adds when it does not., events and the patternsAsked in 2% of software architect ads (as of 5 Nov 2026).Use shared solutions by name, such as adapters, queues or anti-corruption layers, and know their costs. that connect them.
• Data: who owns which data, consistency across services, and databases such as PostgreSQLAsked in 8% of software architect ads (as of 5 Nov 2026).A relational database many architects choose by default; know transactions, replicas and limits..
• Platforms: a cloud such as AWSAsked in 10% of software architect ads (as of 5 Nov 2026).The building blocks of Amazon's cloud, their limits and their price, at the level of whole systems. or AzureAsked in 14% of software architect ads (as of 5 Nov 2026).Microsoft's cloud, common in European enterprises; landing zones, identity and managed services., containers, and the cost of what you choose.
• Decisions and people: decision records, diagrams, governance, and explaining choicesAsked in 14% of software architect ads (as of 5 Nov 2026).Explain a technical choice to people who are not engineers, in terms of risk, time and money. to people who are not engineers.

Trade-offs, qualities and structure

How do you decide between two architecture options?

What they check: that you decide from the system's needs, and say what you give up.

Short answer: "I write down the qualities this system needs most, such as how fast it must answer, how often it may fail and how quickly teams must change it, and score each option against them. I also ask how hard each choice is to undo. A choice that is cheap to reverse I make quickly; one that is expensive I test with a prototype first."

The full answer: Every option wins on some qualities and loses on others; pretending one is best at everything is the classic mistake. Make the trade-off explicit in a small table: the options, the qualities, and a short note on each. Add cost, team skills and time to market, because they decide more projects than technology does. Then record the decision and the reason, so the next person knows what would justify changing it.

A weak answer: "I pick the most modern technology." Follow-up: "The team prefers the option you scored lower." If the gap is small, their skills and ownership may outweigh it; if it is large, show them the scenario where it hurts.

What are quality attributes, and how do you make them concrete?

What they check: that "fast" and "scalable" become numbers a team can test.

Short answer: "Quality attributes are the properties a system must have besides its features: performance, availability, security, changeability, cost and others. I turn each into a scenario with a measure, such as: when traffic doubles on a sale day, nine in ten searches still answer within half a second. Then the design can be tested against it."

The full answer: A scenario has a source, a trigger, the part of the system affected, the expected response and how it is measured. Collect them with the business, rank them, because they compete, and keep the top few visible. ISO 25010, the international model of software quality, is a useful checklist so nothing obvious is forgotten. Check the important ones automatically where you can, with load tests or alarms, so the system keeps them after release.

A weak answer: "It must be scalable and secure." Every system says that. Follow-up: "Availability and cost pull in opposite directions here." Show what each extra level of availability costs, and let the business pick the level it will pay for.

Would you build a new product as a monolith or as microservices?

What they check: that you match the structure to the team and the problem, not to fashion.

Short answer: "For a new product with one or two teams I usually start with a modular monolith: one deployable application with clear internal modules and boundaries. It is simpler to build, test and run. I split a module into its own service when there is a concrete reason, such as a team that needs to release on its own or a part with very different load."

The full answer, in four points:

1. What microservices buy. Teams that release independently, parts that scale on their own, and failures that stay contained.
2. What they cost. Network calls that can fail, data spread across stores, distributed tracing, more pipelines, and people to run the platform. A small team pays this cost without the benefit.
3. Boundaries first. Split along business capabilities, such as orders, payments and stock, not along technical layers. A boundary that is wrong inside a monolith is cheap to move; between services it is expensive.
4. The way back. If services were split too early, merging some of them again is a valid decision, not a failure.

A weak answer: "Microservices, because that is how modern companies work." Follow-up: "The monolith has grown to eight teams who block each other." Find the module with the most independent change and the clearest data, and move it out first.

When is event-driven design the right choice, and what does it cost?

What they check: that you know both the decoupling and the complexity events bring.

Short answer: "Event-driven design means services announce what happened, such as "order placed", and others react in their own time, instead of calling each other directly. It fits when many parts must react to the same change, when the producer should not wait, or when a history of changes is useful. The cost is that the system is only eventually consistent and harder to follow."

The full answer: A log such as KafkaAn event log many services read at their own pace; know ordering, retention and replay. keeps events so consumers can read at their own pace and replay them; a broker such as RabbitMQA message broker for work queues and commands between services. suits work queues. Design for messages that arrive twice or out of order: consumers must be idempotent, which means handling the same event twice does no harm. When a service must update its database and publish an event together, the outbox pattern writes both in one transaction and publishes afterwards. Invest in tracing early, or nobody can follow a request through the chain.

A weak answer: "Events make everything loosely coupled." They hide coupling in the event format. Follow-up: "A team wants to change the format of an event five services read." Version the event, publish both versions for a while, and agree a date to retire the old one.

Data, APIs and failure

In a system of services, who owns which data?

What they check: data ownership, the most common reason service designs fail.

Short answer: "Each piece of data has one owner, the service responsible for that part of the business, and only that service writes it. Others ask the owner through its API or keep a copy updated from its events. Two services writing to the same tables are not separate services; they are a monolith with network calls."

The full answer: Draw the business capabilities and the data each needs to do its job. Where two want to write the same data, the boundary is in the wrong place. Copies are fine when everyone knows which one is the truth and how stale a copy may be. Reports that need everything read from a separate analytics store fed by events, not from the services' own databases. For personal data, ownership also decides who answers a deletion request under the GDPR (EU).

A weak answer: "They all share one database, so the data is always consistent." Follow-up: "A process must update orders and payments together." Use a saga: a sequence of local steps, each with an undo step if a later one fails, rather than one transaction across services.

How do you design an API that many other teams will depend on?

What they check: contracts that last, and change without breaking consumers.

Short answer: "I design it from the consumers' needs, not from the database tables, agree the contract in writing before building, and plan for change: additions that do not break anyone, versioning for the changes that do, and a deprecation period with dates. Errors tell the caller what went wrong and what to do."

The full answer: REST APIsAsked in 8% of software architect ads (as of 5 Nov 2026).Design APIs other teams depend on: clear resources, versioning and errors that say what went wrong. suit resources with clear identities; GraphQLAsked in 5% of software architect ads (as of 5 Nov 2026).An API style where the client asks for exactly the fields it needs; useful for many front ends. suits many front ends that each need different fields; events suit notifications. Whatever the style, publish a specification, test against it in the pipeline, and measure who calls what, so you know who a change will hurt. Set limits on rate and size from the start; adding them later breaks callers.

A weak answer: "We will change it when we need to." Follow-up: "A large customer depends on a field you need to remove." Keep it, mark it deprecated, help them move, and remove it only after the agreed date.

How do you design a system that keeps working when parts of it fail?

What they check: availability as a design quality, built in rather than hoped for.

Short answer: "I assume every call over the network can be slow or fail. Each call gets a timeout and limited retries with a pause, a circuit breaker stops calling a service that keeps failing, and each feature has a fallback, such as showing cached prices. Critical parts run in more than one zone, and we test failures on purpose."

The full answer: Decide first how available each part must be: checkout may need far more than the recommendation panel. Isolate parts so one slow dependency cannot use up all the threads or connections, an idea called bulkheads. Queues absorb peaks. Watch the signs users feel, such as error rates and response times, with alarms. Practise: switch off a dependency in a test environment and see what users would see.

A weak answer: "The cloud provider guarantees availability." They guarantee their part, not your design. Follow-up: "Retries made an outage worse." Retries without limits and pauses multiply the load on a struggling service; add backoff, a budget for retries, and a circuit breaker.

Decisions on paper, cost and legacy systems

How do you record architecture decisions?

What they check: that decisions and their reasons survive people leaving.

Short answer: "With architecture decision records, ADRs for short: a page per significant decision, with the context, the options, the decision, and the consequences we accept. They live next to the code, are reviewed like code, and are never edited after the fact; a new ADR replaces an old one."

The full answer: The value of an ADR is the why. A year later someone asks why the system uses a queue here; the record tells them what was known then and what would justify a change now. Keep them short, a page at most, and write them when the decision is made, not at the end of the project. Not every choice needs one: write them for decisions that are costly to reverse or that other teams depend on.

A weak answer: "The decisions are in the meeting minutes." Follow-up: "Nobody reads them." Link them from the code and the diagrams, and point to them in design reviews until people do.

How do you document an architecture so people actually use it?

What they check: diagrams for readers, not for the architect.

Short answer: "I use the C4 model: four levels of diagram, from the context, the system with its users and neighbours, to containers, the deployable parts, to components inside a container, and only rarely to code. Most readers need the first two. Each diagram has a title, a legend and a date, and lives with the code."

The full answer: A diagram answers a question for a reader: a manager wants to know what the system does and who uses it; a new engineer wants to know where to make a change. Draw for that question and leave the rest out. Keep diagrams in a format that can be reviewed and versioned, and update them in the same change as the system. Add the decision records and the quality scenarios, and you have most of what a team needs.

A weak answer: one huge diagram with every box and line in the company. Follow-up: "The diagrams are out of date." Delete the ones nobody uses, generate what you can from the running system, and make the update part of the definition of done.

How do you bring cost into architecture decisions?

What they check: that cost is a quality attribute like the others, designed and measured.

Short answer: "I estimate the running cost of each option at today's load and at the load we expect, not only the cost to build it. In the cloud the design decides the bill: always-on servers or pay-per-use, data moving between regions, managed services or our own. I make cost visible per team or product, so the people who decide also see the bill."

The full answer: Cost hides in traffic between zones and regions, in logs nobody reads, in test environments left running and in oversized databases. Tag every resource with an owner. Managed services cost more per unit but save people; count both. Revisit the big items every quarter, because load and prices change. Sometimes the cheapest design is the one that is simplest to run.

A weak answer: "Finance looks after the cloud bill." Follow-up: "The bill doubled after a release." Find which service and which item grew, compare with traffic, and look first at data transfer and logging.

How would you migrate a large legacy system without stopping the business?

What they check: a safe, step-by-step plan for the most common architect job of all.

Short answer: "Step by step, never in one big switch. I put a facade in front of the old system, then move one capability at a time to the new one behind it, sending traffic to the new part when it is ready. This is called the strangler fig pattern. Each step is small enough to undo, and the old system shrinks until it can be switched off."

The full answer, in five steps:

1. Understand. Map what the legacy system really does, including the rules nobody wrote down. Talk to the people who run it and read the data, not only the documents.
2. Pick the first slice. A capability that is valuable, fairly separate and not the riskiest, so the team learns on it.
3. Route. A facade or the API layer sends requests for that capability to the new code, and the rest to the old system.
4. Sync the data. For a while both sides need the data; decide which is the truth for each item and keep the other in step, often with events.
5. Retire. Switch off each old part as soon as nothing uses it, or the company pays for two systems for ever.

A weak answer: "Rewrite it from scratch and switch over at a weekend." Big rewrites run late and miss hidden rules. Follow-up: "The business wants new features during the migration." Build them in the new system, which pulls the migration forward instead of slowing it.

Governance and people outside engineering

How do you set architecture governance without slowing teams down?

What they check: guardrails that keep a system coherent while teams move fast.

Short answer: "I keep the rules few and clear: the decisions every team must follow, such as how services authenticate and how data is owned, and freedom for the rest. Where I can, the rules are checked automatically in the delivery pipelineAsked in 23% of software architect ads (as of 5 Nov 2026).Delivery pipelines that make small, frequent, reversible releases possible; architecture depends on them., so nobody waits for a meeting. Review boards look only at the decisions that are costly to reverse or affect many teams."

The full answer: Governance fails in two ways: no rules, and the system drifts into many incompatible pieces; too many rules, and teams route around them. Publish principles with examples, a short list of approved technologies with a way to propose new ones, and fitness functions: automated checks that a quality still holds, such as no service calling another's database. Measure lead time; if governance slows releases, fix the governance.

A weak answer: "Every design goes to the architecture board." Follow-up: "A team ignored the standard and shipped." Find out why; if the standard did not fit, change it; if it did, help them fix it and make the check automatic.

How do you explain an architecture decision to non-engineers?

What they check: that business people can follow you and decide with you.

Short answer: "I start from what they care about: time, money, risk and customers. Instead of "we will split the monolith", I say "releases will go from monthly to weekly, and a failure in search will no longer stop checkout; it costs two teams one quarter". One simple picture, the options with their consequences, and a clear recommendation."

The full answer: Non-engineers do not need the technology; they need the consequences and the choice. Use their words and their numbers. Offer two or three options, including doing nothing, with what each costs and risks. Say what you are unsure of. Afterwards, send a short written summary, so the decision is recorded in language they agreed to.

A weak answer: a slide full of boxes and acronyms. Follow-up: "The CFO asks why it costs so much." Break the cost into what it buys, and show the cost of not doing it, such as outages or slower releases.

Principal, enterprise and chief architect

These questions come up for senior and principal architect, enterprise architect and chief architect roles, and on the way to CTO.

As a principal architect, how do you lead many teams you do not manage?

What they check: influence without authority, the core of senior architecture work.

Short answer: "Through a shared direction that teams helped write, short principles they can apply alone, and being useful: I review their hardest designs, unblock them, and build the shared pieces nobody owns. I spend time with the teams, not only in boards. When I must say no, I explain the reason and offer another way."

The full answer: A principal architect earns trust with good calls and keeps it by listening. Write a target architecture for the next year or two, with the steps to get there, and revisit it each quarter. Grow other architects and senior engineers so decisions do not wait for you. Measure the result in the teams' terms: fewer cross-team blockers, faster releases, fewer incidents.

A weak answer: "Teams must follow the architecture." Follow-up: "Two senior teams disagree with your direction." Bring them into one room, compare the options against the agreed qualities, and decide; record the decision either way.

As an enterprise or chief architect, how do you connect technology to the business strategy?

What they check: at the top of the ladder, a technology plan the leadership team owns.

Short answer: "I start from the strategy and map the business capabilities it needs, such as selling online in new countries, against the systems that support them today. The gaps and risks become a roadmap of a few large moves, each with a cost and a benefit the leadership understands. I review it with them every quarter."

The full answer: An enterprise architect looks across all systems: which to keep, replace, merge or retire, and where duplicate systems cost money. Frameworks such as TOGAF give a common method; a capability map gives a common picture. The chief architect also sets the standards and the architecture practice, and works with the CTO on build or buy, suppliers and technology risk. Above all, the plan must be something the business funds, not a document on a shelf.

A weak answer: "I make sure all projects follow our standards." Follow-up: "The board wants to cut the IT budget." Show which systems could be retired or merged, and what risk each cut would add.

Your CV for these questions

An architect interview will test every decision named on your CV, so write the lines that set up the answers above. Put each under the job where you did it:

Scoring your CV against a real software architect job shows which decisions that employer cares about, and where your lines still lack proof.