Systems Architect Interview Guide

Track record of owning system-level architecture decisions, not just contributing to them: partitioning, interfaces, and technology choices you defended and stand behind

Trade-off reasoning: the ability to articulate why one architecture was chosen over credible alternatives — cost, performance, risk, and time-to-market all weighed explicitly

Depth in at least one discipline (mechanical, electrical, software, or systems) combined with genuine fluency across the others — architects cannot design in isolation from any of them

Experience with architecture frameworks and modelling: SysML, C4, ADLs, or equivalent structured approaches to describing a system

Long-horizon thinking: designing for platform reuse, modularity, and evolvability rather than optimising a single product generation

Influence without direct authority: architects steer engineering teams, product management, and senior stakeholders toward a shared technical direction

Evidence of owning architecture decisions, not just documenting requirements — architects are judged on the calls they made

Ability to defend a decision against credible alternatives with clear, weighted trade-off reasoning

Cross-disciplinary fluency: comfort operating across mechanical, electrical, and software boundaries at once

Long-horizon thinking — architecture decisions that held up across product generations, not just a single release

Influence and communication — architects steer engineering direction without direct authority over the teams involved

Architecture decisions you personally owned, including the alternatives you rejected and why

The modelling or documentation approach you used to communicate the architecture: SysML, block diagrams, ADRs

How your architecture was verified or stress-tested against requirements before implementation began

Cross-disciplinary fluency: mechanical, electrical, and software boundaries you have architected across

Platform or reuse thinking: architecture decisions that paid off across more than one product

Formal design review experience: PDR, CDR, or architecture board participation and outcomes

How you handled disagreement with senior engineers or stakeholders about an architecture direction

Presenting architecture work as a list of diagrams produced rather than decisions made and their consequences

Not naming the alternatives that were rejected — an architecture decision only reads as credible when the road not taken is explicit

Conflating systems engineering (requirements, verification, interfaces) with systems architecture (structural decisions with long-term consequences) — these are related but distinct

No evidence of technical depth in any single discipline — architects who cannot go deep anywhere struggle to earn engineering team trust

Omitting the scale and lifespan of the system: a platform architecture decision that must last a decade reads very differently from a single product

Not showing how the architecture survived contact with real constraints — supplier limitations, cost targets, or a late-breaking requirement change

Q1

Walk me through an architecture decision you made and the alternatives you rejected. What criteria decided it?

Q2

How do you balance short-term delivery pressure against a long-term platform architecture decision?

Q3

Describe a time your architecture had to change after a late requirement or constraint appeared. How did you handle it?

Q4

How do you communicate an architecture decision to engineers who disagree with it?

Q5

What is the difference between systems engineering and systems architecture in your view, and where does the boundary sit in your experience?

Open each role with the system and its scale: what it was, how many subsystems, how many engineers built against your architecture

Name a specific architecture decision you made, the alternatives you considered, and the criteria that decided it — this is the centrepiece of an architect CV

Show how your architecture aged: did it accommodate a requirement nobody anticipated, or scale to a follow-on product? Evolvability is the real test

If you have run or contributed to formal architecture reviews (PDR, CDR, architecture board), name them — it signals your decisions face real scrutiny

For ASML and Philips-style roles, emphasise experience architecting across mechanical, electrical, and software boundaries simultaneously — narrow specialists rarely land senior architect roles

A next-generation precision motion platform needed to support three different customer configurations without tripling development cost.

Existing product architectures were single-purpose, and a fully custom design for each configuration would have blown the programme budget and timeline.

Proposed and defended a modular architecture with a shared core and configuration-specific interface modules, running trade-off studies against two alternative approaches and presenting the cost and risk case to the architecture review board.

Development cost across the three configurations was reduced by 20% versus fully custom designs. The shared core architecture was reused unmodified in a fourth configuration two years later.