Preparing for an AWS Solutions Architect interview: the customer-facing side
Solutions Architects sit between a customer's technical team and the account team. The interview usually tests both halves of that job: can you design something sensible, and can you work with a customer to find out what they actually need? This guide covers the customer-facing side, which is where plenty of strong engineers lose marks.
What the loop usually tests
Formats vary by team and region and change over time, so check the details with your recruiter. Most Solutions Architect loops combine four things:
| Area | What they're checking |
|---|---|
| Leadership Principles | Behavioural questions, often with a few principles assigned to each interviewer. Customer Obsession, Earn Trust, Dive Deep and Learn and Be Curious tend to come up often. |
| Technical depth | Breadth across compute, storage, networking, databases and security, plus real depth in one or two areas. They want to hear how you reason, not a list of service names. |
| Customer discovery | Whether you ask good questions before proposing anything: goals, constraints, skills, budget, deadlines and risk. |
| A customer scenario on the whiteboard | A design exercise, often framed as a customer conversation, where you gather requirements, sketch an architecture and explain the trade-offs. |
Some loops also include a presentation, where you explain a technical topic to a mixed audience. Ask your recruiter whether yours does and how long you'll have.
The stories to prepare
| Story | Principles it usually proves |
|---|---|
| You found the real problem behind a customer's request | Customer Obsession, Dive Deep |
| You told a customer their plan wouldn't work, and why | Earn Trust, Have Backbone |
| You explained something technical to a non-technical buyer | Earn Trust, Invent and Simplify |
| You helped an account team win or rescue a deal | Ownership, Deliver Results |
| You designed something simpler or cheaper than expected | Frugality, Invent and Simplify |
| You learned a new technology quickly for a customer | Learn and Be Curious, Bias for Action |
| A design or migration went wrong and you fixed it | Ownership, Earn Trust |
Put a number in every result: cost saved, time to launch, availability, users moved or the size of the deal you supported. "The customer was happy" isn't a result.
Run the whiteboard like a customer meeting
The design round is where the sales angle shows most. A structure that tends to work:
- Clarify the goal. What does the business want to achieve, and how will they know it worked?
- Ask about constraints. Traffic and growth, data sensitivity and location, availability needs, the team's skills, budget and deadlines.
- State your assumptions out loud before you draw anything.
- Start simple. Sketch a first version that meets the core need, then add resilience, security and scale.
- Explain trade-offs in business terms. Cost against availability, speed of delivery against flexibility, managed services against control.
- Close with next steps, as you would with a real customer: a proof of concept, a risk to check, a decision they need to make.
Question patterns to expect
- Tell me about a time a customer asked for one thing but needed another.
- Tell me about a time you disagreed with a customer on a technical decision.
- How would you explain high availability to a finance director?
- Design a solution for a retailer whose website slows down every time they run a sale.
- Tell me about a technical recommendation that turned out to be wrong.
- Tell me about a time you worked with a sales team to move a deal forward.
A one-week prep plan
Days 1 and 2: build your story bank
Write 10 to 15 real stories as STAR, with a number in each result. Include at least three that show customer discovery and two where you disagreed with someone.
Day 3: technical refresh
Review the core building blocks and the pillars of the AWS Well-Architected Framework, which AWS publishes on its website. Practise explaining why you'd choose one option over another.
Days 4 and 5: whiteboard practice
Run two or three design scenarios out loud with a friend playing the customer. Spend the first few minutes asking questions, not drawing.
Day 6: pressure-test
Ask "why?" three times at every step of each story and design. Swap "we" for "I" wherever you did the work.
Day 7: plan the loop
Map your stories to the principles, prepare questions to ask each interviewer and write a one-page cheat sheet for the day.
Questions
Is the AWS Solutions Architect interview technical?
Usually, yes, more than a sales interview. Expect a design or whiteboard exercise and questions on core cloud building blocks, alongside behavioural questions tied to the Leadership Principles. Check the format with your recruiter.
Do AWS Solutions Architects need sales skills?
Usually, yes. Solutions Architects work closely with account teams and customers, so discovery, explaining trade-offs in business terms and earning trust matter as much as the architecture itself.
How should I prepare for the Solutions Architect whiteboard round?
Treat it as a customer meeting: clarify the goal, ask about constraints, state your assumptions, start simple, then explain the trade-offs and agree next steps.
Related guides
Startups and ISV AE interview prep
Selling to founders and software companies, and the stories that land.
The AWS Account Executive interview
How the loop works, what it tests and a one-week prep plan.
AWS sales interview questions
The question patterns behind the questions, and what a strong answer shows.
Turn this into a prep plan you can actually follow
A Notion workbook for AWS sales interviews: a story bank that scores your stories as you write them, 29 question patterns mapped to the principles, a planner for every round and a day-of cheat sheet. £29, one payment.
Principled Pitch is independent and has no connection with Amazon or AWS. Amazon publishes the official Leadership Principles on its careers site.