Solutions Architect Interview Preparation Guide

According to Glassdoor data, Solutions Architect interviews average 3–4 rounds and span 4–6 weeks from initial screen to offer, with candidates reporting that whiteboard architecture design sessions are the most decisive stage [12].

Key Takeaways

• Prepare architecture design walkthroughs, not just talking points. Interviewers expect you to diagram a system on a whiteboard (or virtual equivalent), defend your trade-off decisions in real time, and respond to evolving constraints — a skill set distinct from software engineering or project management interviews [12].
• Anchor every behavioral answer in measurable business outcomes. Solutions Architects bridge engineering and business stakeholders, so interviewers evaluate whether you quantify impact in terms of cost reduction, latency improvements, uptime SLAs, and time-to-market — not just technical elegance [6].
• Know your cloud provider's Well-Architected Framework cold. AWS, Azure, and GCP each publish formal pillars (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability) that interviewers use as scoring rubrics during design exercises [3].
• Demonstrate pre-sales and discovery fluency. Many SA roles sit within sales engineering or customer-facing teams. Expect questions that probe your ability to run technical discovery calls, translate business requirements into architecture decisions, and handle objections from skeptical CTOs [4][5].
• Practice explaining complex systems to non-technical audiences. Interviewers frequently ask you to re-explain your design as if presenting to a CFO or VP of Product — testing whether you can shift register without losing accuracy [6].

What Behavioral Questions Are Asked in Solutions Architect Interviews?

Behavioral questions in SA interviews focus on cross-functional influence, technical trade-off negotiation, and stakeholder management under ambiguity. Interviewers use these to assess whether you've operated at the intersection of engineering, business, and customer success — the defining characteristic of the role [12][11].

1. "Tell me about a time you had to push back on a customer's preferred architecture."

What they're probing: Your ability to maintain technical integrity while preserving the customer relationship — a daily tension for SAs embedded in pre-sales or post-sales engagements.

What they're evaluating: Stakeholder management, technical authority, diplomatic communication.

STAR framework: Situation — A financial services client insisted on a single-region deployment for their trading platform to minimize latency, ignoring disaster recovery requirements. Task — You needed to demonstrate why a multi-region active-passive configuration was non-negotiable for their RPO/RTO targets without alienating the CTO who had already committed to the single-region approach internally. Action — You built a failure-mode analysis showing projected downtime costs ($2.4M/hour based on their transaction volume), presented a multi-region design that added only 3ms of latency via Global Accelerator, and ran a tabletop DR exercise with their engineering team. Result — The client adopted the multi-region design, and the deal closed at 40% higher ARR due to the expanded infrastructure scope [11].

2. "Describe a situation where you inherited a poorly architected system and had to remediate it."

What they're probing: Your diagnostic process when walking into technical debt — do you assess systematically or react to symptoms?

What they're evaluating: Root cause analysis, prioritization under constraints, migration planning.

STAR framework: Situation — Joined an engagement where a SaaS platform was running a monolithic Java application on oversized EC2 instances with no auto-scaling, resulting in $47K/month in wasted compute. Task — Design a phased migration path that reduced costs without requiring a full re-architecture (the client had a 90-day timeline to show board-level savings). Action — Conducted a workload analysis using AWS Cost Explorer and Compute Optimizer, right-sized instances as a Phase 1 quick win (saving 35% immediately), then designed a containerization roadmap using ECS Fargate for their three highest-traffic microservices. Result — Monthly compute costs dropped from $47K to $19K within 60 days; the containerization roadmap became a $300K professional services engagement [11].

3. "Tell me about a time you had to align engineering and sales teams on a technical decision."

What they're probing: Whether you can operate in the organizational seam between revenue teams and engineering — the exact space SAs occupy.

What they're evaluating: Cross-functional influence without direct authority, translation between technical and commercial language.

STAR framework: Situation — Sales committed to a customer that your platform supported real-time CDC (change data capture) from Oracle to Snowflake, but engineering had only validated batch ETL. Task — Determine feasibility within the deal timeline, propose a realistic scope, and prevent either team from losing credibility. Action — You ran a 48-hour proof-of-concept using Debezium and Kafka Connect, documented the latency characteristics (sub-5-second propagation for 80% of change events), and presented both teams with a "what we can commit to" versus "what requires a roadmap item" breakdown. Result — The deal closed with an accurate SOW, engineering added CDC to their Q3 roadmap, and the customer's first production deployment hit their SLA targets [11].

4. "Describe a time you had to make an architecture decision with incomplete information."

What they're evaluating: Comfort with ambiguity, reversible vs. irreversible decision frameworks, risk communication.

STAR framework: Situation — A healthcare client needed a HIPAA-compliant data lake design, but their data governance team hadn't finalized classification policies for PHI vs. de-identified data. Task — Deliver an architecture proposal within two weeks despite the unresolved data classification. Action — Designed a two-tier architecture with separate S3 buckets and IAM policies for PHI and non-PHI data, using AWS Lake Formation for fine-grained access control, and documented explicit assumptions about data classification that the client would need to validate. You flagged the classification gap as a project risk in the design document with a recommended remediation timeline. Result — The architecture was approved, the client completed classification within 30 days, and zero redesign was needed because the two-tier approach accommodated both outcomes [11].

5. "Tell me about a failed architecture recommendation and what you learned."

What they're evaluating: Self-awareness, post-mortem discipline, and whether you treat failures as learning inputs.

STAR framework: Situation — Recommended a serverless-first approach (Lambda + API Gateway + DynamoDB) for a logistics company's shipment tracking system. Task — The system needed to handle 50K concurrent WebSocket connections for real-time tracking updates. Action — After deployment, Lambda cold starts caused 2–4 second delays during traffic spikes, violating the 500ms latency SLA. You conducted a post-mortem, identified that the WebSocket connection pattern was a poor fit for Lambda's execution model, and redesigned the real-time layer using ECS Fargate with Application Load Balancer WebSocket support. Result — Latency dropped to sub-200ms at P99. You documented the failure pattern as an internal architecture decision record (ADR) that became a reference for the SA team's serverless suitability checklist [11].

What Technical Questions Should Solutions Architects Prepare For?

Technical questions in SA interviews differ from software engineering interviews. You won't typically write production code on a whiteboard. Instead, you'll design systems, defend trade-offs, estimate capacity, and demonstrate fluency across infrastructure, networking, security, and application architecture [12][3].

1. "Design a multi-tenant SaaS platform that serves 10,000 customers with varying workload profiles."

What they're testing: Multi-tenancy isolation strategies (silo vs. pool vs. bridge), noisy neighbor mitigation, and cost allocation models.

Answer guidance: Walk through the trade-offs between database-per-tenant (strong isolation, high operational overhead), schema-per-tenant (moderate isolation, moderate overhead), and shared-schema with tenant_id partitioning (low isolation, low cost). Discuss how you'd implement tenant-aware throttling using API Gateway usage plans or custom rate limiters, and how you'd handle tenant data residency requirements for regulated industries. Mention specific services: Amazon RDS with read replicas per tier, DynamoDB with partition key design for tenant isolation, or Azure Cosmos DB with dedicated throughput per tenant [3][6].

2. "How would you migrate a legacy on-premises Oracle database to a cloud-native solution with zero downtime?"

What they're testing: Migration methodology (assess, mobilize, migrate, modernize), DMS/SCT tooling knowledge, and cutover planning.

Answer guidance: Outline a phased approach: use AWS Schema Conversion Tool to identify incompatible stored procedures and Oracle-specific PL/SQL, set up AWS DMS for continuous replication during the migration window, implement a dual-write pattern during cutover to validate data consistency, and define rollback criteria (e.g., if replication lag exceeds 30 seconds or data validation checks fail on more than 0.1% of records). Discuss target database selection — Aurora PostgreSQL for OLTP workloads vs. Redshift for analytical workloads — and justify your choice based on the query patterns described [6].

3. "A client's application experiences intermittent 504 Gateway Timeout errors under load. Walk me through your troubleshooting approach."

What they're testing: Systematic debugging methodology, observability stack knowledge, and ability to distinguish between infrastructure and application-layer issues.

Answer guidance: Start with the request path: client → CloudFront/CDN → ALB → target group → application. Check ALB access logs for target response time vs. idle timeout (default 60s). Examine target group health check configuration — are unhealthy targets being drained properly? Review application-level metrics: thread pool exhaustion, database connection pool saturation (check HikariCP or pgBouncer metrics), or downstream service timeouts. Mention specific tools: CloudWatch Container Insights for ECS, X-Ray for distributed tracing to identify the slow span, and VPC Flow Logs if you suspect network-level drops [3].

4. "Explain how you would design a data pipeline that processes 5TB of clickstream data daily with a 15-minute freshness SLA."

What they're testing: Streaming vs. micro-batch architecture decisions, cost modeling, and data quality handling at scale.

Answer guidance: Calculate throughput: 5TB/day ≈ 58MB/s sustained. For a 15-minute freshness SLA, a micro-batch approach (e.g., Spark Structured Streaming on EMR or Glue Streaming with 5-minute trigger intervals) is more cost-effective than true real-time (Kinesis Data Analytics or Flink). Discuss schema evolution handling with a schema registry (Confluent or AWS Glue Schema Registry), dead-letter queues for malformed events, and partitioning strategy in the target data lake (partition by event_date and event_hour for query performance in Athena or Redshift Spectrum). Address data quality: implement Great Expectations or Deequ checks as a pipeline stage before data lands in the curated zone [6][3].

5. "What's your approach to designing for cost optimization without sacrificing reliability?"

What they're testing: Whether you treat cost as an architectural constraint (like latency or availability) rather than an afterthought.

Answer guidance: Reference the AWS Well-Architected Cost Optimization pillar specifically. Discuss concrete patterns: Spot Instances for fault-tolerant batch workloads (with Spot Fleet diversification across instance types and AZs), Reserved Instances or Savings Plans for steady-state baselines, S3 Intelligent-Tiering for unpredictable access patterns, and right-sizing through Compute Optimizer recommendations. Quantify: "In a recent engagement, shifting 60% of a batch processing fleet to Spot reduced monthly compute from $28K to $11K with zero job failures by implementing checkpointing in the Spark application." Mention FinOps practices like tagging enforcement, showback dashboards, and anomaly detection alerts [3][6].

6. "How do you evaluate build vs. buy decisions for a client?"

What they're testing: Business acumen and total cost of ownership (TCO) analysis — not just technical preference.

Answer guidance: Frame the decision across four dimensions: (1) Strategic differentiation — does this capability create competitive advantage, or is it undifferentiated heavy lifting? (2) TCO over 3 years — include engineering salaries for maintenance, not just licensing costs. (3) Time-to-value — a managed service deployed in 2 weeks vs. a custom solution in 6 months has an opportunity cost. (4) Vendor lock-in risk — assess portability using the reversibility of the decision. Give a concrete example: "For a client's notification system, I recommended Amazon SNS + SES over building a custom email/SMS platform because notifications weren't their core product, and the build option required 2 FTEs for ongoing maintenance — $350K/year in loaded cost vs. $8K/year in SNS/SES usage" [6].

What Situational Questions Do Solutions Architect Interviewers Ask?

Situational questions present hypothetical scenarios that mirror real SA engagements. Unlike behavioral questions (which ask about past experience), these test your reasoning process in real time [12].

1. "A prospect's CTO tells you during a technical deep-dive that they've already decided to use Kubernetes for everything, including simple CRUD APIs with minimal traffic. How do you handle this?"

Approach: This tests whether you can diplomatically challenge over-engineering without undermining the CTO's authority. Acknowledge the CTO's Kubernetes expertise, then ask discovery questions: "What's your team's current K8s operational maturity? How many engineers will manage cluster operations?" Present a TCO comparison — EKS cluster costs ($73/month per cluster + node costs) vs. Lambda + API Gateway for low-traffic CRUD services. Frame it as "right-sizing the platform to the workload" rather than "you're wrong." Offer a tiered approach: Kubernetes for stateful, high-traffic services; serverless for low-traffic endpoints [6].

2. "You're three weeks into a proof-of-concept and discover that the client's actual data volumes are 10x what they stated during discovery. The architecture you've designed won't scale. What do you do?"

Approach: This evaluates your escalation judgment and redesign agility. First, validate the new data volumes with specific queries against their production systems — don't take a verbal estimate at face value twice. Quantify the impact: which components break at 10x (database IOPS? network throughput? storage costs?). Present the client with three options: (1) redesign the data tier for the actual volume (timeline impact: +2 weeks), (2) implement a data retention/archival policy to reduce active volume, (3) phase the rollout to handle current volume now with a scaling roadmap. Document the discovery gap in the project risk register and adjust the SOW if the scope change affects commercial terms [6].

3. "Your client wants to go live in two weeks, but the security review hasn't been completed and you've identified that their IAM policies use wildcard permissions (Action: *, Resource: *). What do you recommend?"

Approach: This tests whether you'll compromise on security under deadline pressure. The answer is no — but the approach matters. Quantify the risk: wildcard IAM policies violate the principle of least privilege and would fail any SOC 2 or ISO 27001 audit. Propose a parallel path: use IAM Access Analyzer to generate least-privilege policies based on CloudTrail activity from the past 90 days, implement SCPs (Service Control Policies) at the OU level as a guardrail while fine-grained policies are developed, and add a "security hardening" milestone to the post-launch roadmap with a 30-day deadline. This lets the launch proceed with meaningful risk reduction rather than a binary go/no-go [3][6].

4. "A client asks you to design an architecture, but their engineering team is only two people with no cloud experience. How does this change your recommendation?"

Approach: This evaluates whether you design for the team you have, not the team you wish you had. Shift toward managed services aggressively: Fargate over self-managed EKS, RDS over self-managed PostgreSQL on EC2, Amplify or Vercel for frontend deployment. Recommend infrastructure-as-code with CDK or Terraform Cloud (not raw CloudFormation) for maintainability. Build operational runbooks for the top 5 failure scenarios. Factor in a training plan — and be honest about what this team can realistically operate without a dedicated SRE [6][3].

What Do Interviewers Look For in Solutions Architect Candidates?

SA interviewers typically evaluate candidates across five competency dimensions, often using structured scorecards aligned to the role's dual technical-commercial nature [12][5].

1. Architectural breadth and depth. Can you design across compute, storage, networking, security, and data layers — and go deep when challenged on any one? Interviewers probe for T-shaped knowledge: broad familiarity with cloud services and deep expertise in 2–3 domains (e.g., data engineering, security, or application modernization) [3].

2. Trade-off articulation. The strongest signal in an SA interview is how you explain why not — why you chose DynamoDB over Aurora, why you rejected a microservices approach for this specific workload, why you accepted higher latency for lower cost. Candidates who present a single solution without discussing alternatives score poorly [12].

3. Business outcome orientation. Interviewers listen for whether your architecture decisions connect to revenue, cost, compliance, or time-to-market — not just technical elegance. Saying "this reduces query latency by 200ms" is good; saying "this reduces query latency by 200ms, which their product team estimated would improve checkout conversion by 1.2%" is what separates senior SAs [6].

4. Communication range. Can you explain the same architecture to a CTO, a product manager, and a junior developer — adjusting depth and vocabulary for each audience? Interviewers often test this explicitly by asking you to "now explain that to a non-technical stakeholder" [3].

5. Red flags that eliminate candidates: Inability to say "I don't know" (SAs must be trusted advisors — bluffing destroys credibility). Designing without asking clarifying questions (SAs who skip discovery build the wrong thing). Presenting only one cloud provider's services when the client is multi-cloud. Focusing exclusively on technology without mentioning team capability, operational readiness, or cost [12].

How Should a Solutions Architect Use the STAR Method?

The STAR method (Situation, Task, Action, Result) is the standard framework for behavioral interview responses, but SAs need to adapt it with architecture-specific detail and business metrics [11].

Example 1: Designing Under Constraint

Situation: A Series B fintech startup needed a payment processing architecture that met PCI DSS Level 1 compliance, but their entire engineering team was 8 people and they had a 6-week deadline to launch their merchant onboarding product.

Task: Design a PCI-compliant architecture that the team could build and operate without hiring a dedicated security engineer, while meeting their 99.95% uptime SLA commitment to early merchant partners.

Action: Designed a tokenization-first architecture using Stripe Connect for payment processing (offloading PCI scope), with a VPC architecture that isolated the cardholder data environment into a separate subnet with NACLs and security groups restricting ingress to only the Stripe webhook IPs. Implemented AWS Config rules for continuous compliance monitoring and set up GuardDuty for threat detection. Created a 12-page architecture decision record documenting each PCI DSS requirement and how the design addressed it.

Result: The startup launched on time, passed their PCI DSS Level 1 assessment on the first attempt (their QSA specifically cited the architecture documentation as "unusually thorough for a company this size"), and processed $2.3M in transactions in the first quarter with zero security incidents. The architecture supported their growth to $18M ARR without requiring redesign [11].

Example 2: Stakeholder Alignment Under Conflict

Situation: During a cloud migration engagement for a manufacturing company, the VP of Engineering wanted to re-architect their MES (Manufacturing Execution System) as microservices, while the VP of Operations demanded zero production disruption and a 6-month maximum timeline.

Task: Develop a migration strategy that satisfied both stakeholders' constraints — modernization ambition and operational continuity — without letting the project stall in committee.

Action: Proposed a strangler fig migration pattern: lift-and-shift the monolithic MES to EC2 as Phase 1 (completed in 8 weeks, satisfying Operations' continuity requirement), then incrementally extract the highest-value services (production scheduling and quality inspection modules) into containerized microservices on ECS in Phase 2. Built a decision matrix scoring each module on business value, coupling complexity, and change frequency to prioritize extraction order. Presented both VPs with a unified roadmap showing how their goals were sequential, not competing.

Result: Phase 1 completed in 7 weeks with 45 minutes of total downtime during cutover. Phase 2 delivered the first two microservices within 5 months. The production scheduling service's deployment frequency increased from monthly to daily, and the VP of Engineering cited the strangler fig approach in their board presentation as a model for future modernization projects [11].

Example 3: Cost Optimization Discovery

Situation: Engaged with a media streaming company whose AWS bill had grown from $120K/month to $340K/month over 12 months, with no corresponding increase in user traffic or feature releases.

Task: Identify the cost drivers, design a cost-optimized architecture, and present a remediation plan with projected savings to the CFO and CTO within two weeks.

Action: Ran AWS Cost Explorer analysis segmented by service, account, and tag. Discovered three primary drivers: (1) untagged development environments running 24/7 ($68K/month), (2) GP2 EBS volumes that should have been GP3 ($22K/month savings from IOPS/throughput decoupling), and (3) a NAT Gateway processing 14TB/month of S3 traffic that should have used a VPC Gateway Endpoint ($12K/month). Designed an automated environment scheduler using Lambda and EventBridge for dev/staging, migrated EBS volumes, and deployed the VPC endpoint.

Result: Monthly bill reduced to $198K within 30 days — a 42% reduction ($142K/month savings, $1.7M annualized). Implemented a FinOps dashboard with Grafana and the AWS Cost and Usage Report so the engineering team could monitor spend in real time. The CFO approved the next phase of infrastructure investment based on demonstrated cost discipline [11].

What Questions Should a Solutions Architect Ask the Interviewer?

The questions you ask reveal whether you think like an SA or a developer. These demonstrate architectural thinking and business awareness [4][5]:

1. "What does the typical engagement lifecycle look like — do SAs stay involved through implementation, or hand off after design?" This reveals whether the role is pre-sales, post-sales, or full-lifecycle, which fundamentally changes your day-to-day work.

2. "How are architecture decisions documented and governed? Do you use ADRs, a formal review board, or something else?" Shows you care about decision traceability and organizational learning — hallmarks of a mature SA practice.

3. "What's the ratio of greenfield designs to brownfield migrations in your current project portfolio?" Signals that you understand these require fundamentally different skills and that you're assessing fit, not just accepting any role.

4. "How does the SA team interact with product engineering when a customer request implies a platform capability gap?" Tests whether the company has a feedback loop between field architecture and product roadmap — critical for SA job satisfaction and impact.

5. "What's the most common reason architecture engagements stall or fail here, and how has the team addressed it?" Demonstrates that you've seen engagements fail and you're evaluating organizational maturity, not assuming everything works perfectly.

6. "What cloud certifications or continuing education does the team prioritize, and is there a budget for re-certification?" Shows you're thinking about long-term growth while also gauging how seriously the company invests in SA development.

7. "Can you walk me through a recent deal where the SA's involvement directly influenced the technical win?" Asks for a concrete success story that reveals how the company values and measures SA impact [4][5].

Key Takeaways

Solutions Architect interviews test a combination of system design fluency, business acumen, and stakeholder communication that no other technical role demands in quite the same way. Your preparation should center on three pillars: (1) practicing whiteboard architecture sessions where you narrate your trade-off reasoning aloud, (2) preparing STAR stories that connect technical decisions to measurable business outcomes like cost savings, revenue impact, and time-to-market, and (3) demonstrating fluency with your target cloud provider's Well-Architected Framework pillars, since interviewers frequently use these as implicit scoring rubrics [3][12].

Build a portfolio of 3–5 architecture case studies from your experience, each with specific metrics (latency, cost, uptime, migration timeline). Rehearse explaining each one at three levels of detail: a 2-minute executive summary, a 10-minute technical overview, and a 30-minute deep dive. This range mirrors the actual communication demands of the role [11]. If you're refining your resume before applying, Resume Geni's builder can help you structure your SA experience around the architecture outcomes and business metrics that interviewers prioritize.

FAQ

How many interview rounds should I expect for a Solutions Architect role?

Most SA hiring processes involve 3–5 rounds: a recruiter screen, a hiring manager conversation, a technical deep-dive or system design session, a behavioral/leadership interview, and sometimes a presentation or case study round. Enterprise companies (AWS, Microsoft, Google) tend toward 5 rounds; mid-market companies and startups typically run 3–4. The system design round is almost always the most heavily weighted in the final hiring decision [12].

Do I need a cloud certification to get a Solutions Architect job?

Certifications like AWS Solutions Architect Professional, Azure Solutions Architect Expert, or Google Cloud Professional Cloud Architect are not strictly required, but they're strongly preferred — particularly for roles at cloud vendors or consulting firms. According to job listings on LinkedIn and Indeed, roughly 70–80% of SA postings list at least one cloud certification as preferred or required [4][5]. Certifications signal baseline competency and reduce ramp-up time, which matters to hiring managers filling revenue-generating roles.

How long should my STAR method answers be?

Aim for 2–3 minutes per STAR response. Under 90 seconds usually means you're skipping critical detail (especially the Action and Result sections, which carry the most signal for interviewers). Over 4 minutes risks losing the interviewer's attention and suggests you can't communicate concisely — a red flag for a client-facing SA role. Practice with a timer and have a colleague flag when you're adding detail that doesn't strengthen the answer [11].

Should I prepare differently for a pre-sales SA role versus a post-sales or delivery SA role?

Yes — significantly. Pre-sales SA interviews emphasize discovery methodology, competitive positioning (e.g., "how would you differentiate our platform against [competitor]?"), demo skills, and comfort with ambiguity in early-stage customer conversations. Post-sales and delivery SA interviews focus more on implementation depth, migration planning, troubleshooting methodology, and project delivery under constraints. Review the job description carefully for signals: "work with account executives" and "technical win rate" indicate pre-sales; "implementation," "deployment," and "customer success" indicate post-sales [4][5].

What's the most common reason Solutions Architect candidates get rejected?

The most frequently cited rejection reason on Glassdoor is "couldn't articulate trade-offs" — candidates who present a single architecture without discussing alternatives, constraints, or what they'd change given different requirements. The second most common is poor communication range: candidates who can go deep technically but can't simplify their explanation for a non-technical audience, or vice versa. Interviewers interpret both as signs that the candidate would struggle in client-facing engagements where adapting to the audience is a core daily requirement [12].

What tools should I be prepared to use during a whiteboard design session?

For in-person interviews, practice drawing architecture diagrams by hand with clear component labels, data flow arrows, and annotations for key decisions. For virtual interviews, familiarize yourself with Excalidraw, Lucidchart, Draw.io, or Miro — many companies will specify which tool they use, but having fluency in at least two ensures you won't fumble with the interface during a high-stakes session. Label every component with the specific service name (e.g., "Amazon Aurora PostgreSQL" not just "database"), include data flow direction arrows, and annotate your diagram with key metrics like expected throughput, storage estimates, and latency targets [12][3].

How do I handle a design question about a cloud provider I'm less familiar with?

Be transparent — say "My primary experience is with [AWS/Azure/GCP], so I'll design using those services, but I can map the concepts to [other provider] if that's helpful." Interviewers respect honesty over bluffing, and most SA design questions test architectural thinking (caching strategies, event-driven patterns, data partitioning) rather than service-name memorization. That said, if the job posting specifies a cloud provider, you should have working knowledge of that provider's core 20–30 services, their pricing models, and their Well-Architected Framework equivalent before the interview [3][6].