Solution Architect interview questions

I've been a solution architect for nine years, the last five in Oman. Started as a senior software engineer at an Indian tech consultancy, moved into architect roles for SaaS products, and for the past three years I've been principal SA at a regional systems integrator covering Oman, UAE, and Bahrain. My specialty is enterprise systems integration, especially around banking and government clients. I hold AWS Solutions Architect Professional and TOGAF Foundation. Recent projects include a multi-channel banking platform integration, an enterprise data lakehouse, and a government identity-federation programme.

Start with the requirements, especially the quality attributes (performance, availability, security, compliance). Then constraints: budget, team skill, existing systems to integrate with, regulatory environment. Only then to options. I document architecture decisions in lightweight ADRs (Architecture Decision Records): one page per decision, with context, options considered, decision, and consequences. Multiple options are evaluated against weighted criteria. The chosen design gets a logical view, a deployment view, and a sequence diagram for critical flows. Then I review with the engineering team and a peer architect before commitment.

Critical questions first: regulatory requirements (CBO mandates), latency budget (probably under 200ms p95), durability requirements (no data loss), and what 'transaction' means. For 50K TPS sustained, I'd consider an event-driven core with Kafka as the durable backbone, horizontally scalable transaction processors, and a write-optimised primary store (Cassandra or Spanner) plus a query store. CDC pipelines feed analytics. For regulatory: strict audit trail, encryption at rest and in transit, PCI DSS isolation. Disaster recovery: multi-region within Oman if data residency requires, with automated failover. Critically: this design only works if the operations team has the maturity to run distributed systems; otherwise simpler is better.

Security has to be designed in, not bolted on. Threat modeling at the architecture stage: STRIDE for major components, identify trust boundaries, mandate encryption across each boundary. Least privilege everywhere: service accounts with minimum permissions, no shared secrets. For data: classify it (public, internal, confidential, restricted) and design controls per classification. For identity: prefer federated identity with proper RBAC; avoid local user databases where possible. For audit: assume everything will be audited; design logging and retention to satisfy the strictest regulator we expect to face. Security reviews with the security team before any architecture commits.

I have three versions of every architecture diagram: a one-pager for executives (no boxes, just narrative and business outcomes), a logical view for product and project teams (boxes and arrows, no implementation detail), and a deployment view for engineers (actual systems and protocols). For exec audiences I always lead with the business outcome: 'this lets us launch new products in 6 weeks instead of 6 months'. Tech detail comes only if asked. I also avoid jargon ('eventual consistency', 'CAP theorem'); I translate. The architect's value to the business is communication as much as design.

For a senior solution architect role in Oman with my experience I'd target OMR 2,500 to 3,200 total package depending on the seniority and customer portfolio. Architects working with major banks and government clients command a premium. I'm on 90 days' notice. Beyond pay I'd want clarity on the technical authority: an SA role where I'm consulted but not heeded is frustrating. Authority and seat at the table matter more than basic pay at this seniority.