How a Spanish Solutions Architect Prepped for AWS in English
The architecture was there. Leadership stories in English were not.
What this case shows
A Solutions Architect in Spain had an AWS first round in London. Classes worked real questions, then corrected English on the same answers.
At a glance
| Role | Solutions Architect (~4 years) |
|---|---|
| Region | Spain |
| Starting Point | Strong cloud work; spoken interview English lagged |
| Target | AWS London - Solutions Architect, first round |
| Outcome | Technical + Leadership Principles answers structured in class |
Timeline
Several live classes
Focus
AWS first round: technical + behavioral
Outcome
STAR-F + T-shaped answers
“I want to practice in English and prepare strong answers - then get feedback on fluency, structure, confidence, and whether I sound like a customer-facing Solutions Architect.”
Profile
A Spanish-speaking Solutions Architect based in Spain. About four years in the role at a large enterprise software company. The next interview was a first-round Solutions Architect screen at AWS in London. The interviewer was another Solutions Architect. The round mixed technical design with behavioral / Leadership Principles questions - not a pure coding test. The first class covered one real question, then notes on English and interview skill together.
Pain Points
- Stories used “we” when the interviewer needed ownership (“I decided…”)
- STAR answers stopped at the action - the result and customer impact were missing
- Open-ended questions jumped into a long example with no short opening
- Grammar slips under pressure (“everything was smoothly”, mix-ups on build / built)
- “Why AWS?” answers drifted into reverse-engineering the company instead of a clear motivation
Goals
- Tell me about yourself - tight, customer-facing, no ramble
- Why AWS, and why this Solutions Architect role
- Why startups as customers, and how to advise them
- Explain AWS building blocks clearly: compute, networking, storage, databases, IAM, HA, monitoring, migration, cost
- Walk a customer scenario: discover requirements, design, trade-offs, recommend
- Behavioral answers with STAR, aimed at Amazon Leadership Principles
- Sound natural in English - fluency, structure, and confidence - not a memorised script
Lesson Notes
These are the classes we actually ran, not a generic curriculum. Each one started from a real interview question.
Class 1
Technical + behavioral mix
Intake and the first-round map
- Listed the live first-round prompts: on-prem data centre to AWS, high availability, containers, S3 objects and sharing, what happens when someone types a URL, most technically challenging project
- Coach note on the design answers: call out trade-offs, don’t only list services
- Agreed the next technical class would be share-screen architecture drawing - the same format as the round
Class 2
Mentoring, risk, customers, scale
Behavioural stories
- Mentoring a junior: switch “we organised a 1:1” to “I decided to schedule 1:1s” - then add a result (timeline, what they could do alone, promotion if true)
- Saying no to a customer: pronunciation of build / built; prepare the follow-up “how do you know when to push back?”
- Scaling a solution: coach praised diagnosing before building
- Introduced STAR-F - Situation, Task, Action, Result, plus the Framework / approach you used
Class 3
Amazon-style leadership
Leadership and motivation
- Bold idea: investigating cloud support models; correction “everything was smoothly in the deployment” → “everything was smooth”
- Learning with no immediate payoff: a certification story (“I passed with a score of 70%”) - still needed business impact, not only the score
- Build trust with a new customer: T-shaped answer - short general approach (X, Y, Z), then one recent example
- Why Amazon / this team: keep it specific; “spread tasks when someone is overloaded” as a working-style signal
- Most challenging part of the role: end on how you handle it, not only the difficulty
Class 4
Bad news, extra ownership, cost
Customer and ownership stories
- Delivering bad news: advertising customer, missed July date - talk to engineering, whitelist option, then explain clearly. Coach: finish the task in the story; don’t leave the customer hanging
- Improved something that wasn’t officially the job: saw an unanswered customer thread, stepped in, tightened escalation and timing. Follow-ups practised: whose job was it, and what stopped it happening again
- Learning HTTP/2 load-balancer behaviour on a tight timeline - strong actions, missing result
- Disagreement with a manager about an in-person partner meeting - practised the trade-off of delaying
- Difficult feedback on repeating words in a presentation - changed prep. Follow-ups: did you ask for the feedback, and how did you stop it
- Reduce cloud costs: Cost Explorer / metrics; “the cost that he is using” → “the cost they are using”; “is not so much utilised” → say underused / not being used
Feedback
Coach notes from those sessions, kept as they were given in class.
Open-ended questions need a T-shape
Start with a broad answer (“To build trust I would do X, Y, Z”), then one example (“For example, I recently…”). Don’t dump the story first.
Use I, then a result
Leadership Principles score ownership. “We organised 1:1s” hides who decided. “I scheduled weekly 1:1s. Within three months they ran discovery alone” is the shape interviewers can score.
STAR-F, not STAR with a missing R
Name the framework you used, then close with impact on the customer, team, or business. A missing result is the most common hole in these classes.
End hard questions on a positive
“What will be most challenging?” should finish with how you already handle that challenge - not only the fear.
Diagnose before you build
The scale story already did this. Keep that order in architecture answers too: requirements → constraints → design → trade-offs.
Common Mistakes
Corrections from live answers, the same patterns that showed up in class.
| Heard in class | Use instead |
|---|---|
| “Everything was smoothly in the deployment” | “Everything was smooth in the deployment” Smooth is the adjective. Smoothly is the adverb. |
| “We organised a 1:1 every week” | “I decided to schedule 1:1s every week” Interviewers score your ownership, not the team’s. |
| “To be near them” | “To work more closely with them” Motivation answers need a work reason, not a location phrase. |
| “Biled / build (for the past)” | “Built” Build → built. This came up in a “say no to a customer” story. |
| “The cost that he is using in the cloud” | “The cost they are using in the cloud” Keep the customer as they when you talk about their account. |
| “Is not so much utilised” | “It isn’t being used much / it’s underutilised” Cost stories need plain English plus the metric. |
Before and After
Before coaching
- Used “we” on stories that needed a personal decision
- Stopped STAR answers before the result
- Opened open-ended questions with a long example
- Grammar and pronunciation slipped on high-frequency verbs
After coaching
- Leads with I and a clear action
- Closes with impact on customer, team, or date
- Gives a short framework, then one example
- Names trade-offs in architecture, not only services
The interview process
| First round | Solutions Architect interviewer - technical design + behavioral in one conversation |
|---|---|
| Technical prompts practised | On-prem to AWS, high availability, containers, S3 sharing, URL in a browser, hardest project |
| Behavioral / LPs practised | Mentoring, calculated risk, saying no, scaling, bad news, extra ownership, manager disagreement, feedback, cost |
| Still ahead after these classes | Share-screen architecture drawing; more Glassdoor-style technical prompts |
Session snapshot
| Classes in this set | 4 (intake + behavioral + leadership + customer stories) |
|---|---|
| Interview format | AWS Solutions Architect first round - technical + behavioral |
| Location of round | London |
| Next planned | Whiteboard / share-screen architecture |
The Turning Point
The shift was the T-shaped answer on “How would you quickly build trust with a new customer?” Before, the story started in the middle of a project. After, the opening was three concrete habits, then one example. The same shape transferred to Why AWS and to cost conversations: framework first, proof second. That is what made the Leadership Principles round feel like a conversation instead of a memory test.
Proof of work - one mock session
| Problem | How would you quickly build trust with a new customer? (open-ended LP-style) |
|---|---|
| Old approach | A long project story with no opening |
| New framework | T-shape: name X, Y, Z you always do, then one recent example |
| Result | The answer became scorable in the first 20 seconds, then specific |
How answers sounded before
“So, I had this customer, and we were working on the environment, and then…”
How answers sounded after
“To build trust quickly I would do three things: set a clear cadence, show progress early, and flag risk before they ask. For example, I recently…”
The Result
These classes did not produce a job-offer claim - the notes stop at first-round prep, with a technical whiteboard still ahead. What did change: the first-round question list was no longer a surprise, behavioral stories had an owner and a result, and the same corrections (I vs we, smooth vs smoothly, built vs build) were on paper to reuse. That is the honest outcome from this coaching block.
Advice for Other Solutions Architects Interviewing at AWS
- Write the first-round question list before you polish vocabulary - you need both
- Rebuild every LP story as I + action + customer or business result
- For “how would you…” questions, give a short framework before the example
- Practise architecture out loud while drawing - silence on a whiteboard is still English
- Keep a running mistakes list from class; the same five errors will show up in the real round
Why This Matters for Solutions Architects Interviewing in English
AWS Solutions Architect rounds score two things at once: can you design, and can you sound like someone a customer would trust - in English. Native-level accent is not the bar. Missing results, hidden ownership, and fuzzy cost language are. The work is the same in every class: one real prompt, then notes on the English of that answer.
Preparing for a similar path? Read Preparing for a Amazon System Design Interview in English.
Learning paths
Practise in the course
Start with your introPractise explaining system design in English
No card required. Start with a 7-day free trial - a lesson, a mock interview, or both.
Join 500+ preparing for global roles
Other engineers practising interview English
Mockly knows what it takes to get hired. The preparation covers behavioral, algorithm, and system design interviews thoroughly - with real expertise in the STAR method, LeetCode, and Alex Xu’s system design frameworks. And when it comes to English and communication skills, the native-speaking mentors make all the difference.
Mockly’s approach is genuinely personalized - they use a variety of methods tailored to your specific needs. With their help, I improved my spoken English and prepared thoroughly for behavioral interview questions across different companies. This not only helped me refine my stories grammatically but also ensured I was using the right examples to answer specific questions effectively.
FAQ
Questions
More questions? Email us at contact@mocklyenglish.com.
Similar case studies
Preparing for a Amazon System Design Interview in English
Explaining system-design answers while an interviewer watched was the hurdle. This PM trained that skill for Amazon - no offer claimed.
How an American PM Prepped for Amazon in English
An American product manager was targeting Amazon. System-design answers in English were the gap. Here is what she practised.
More case studies
Related resources
Case studies are illustrative, based on patterns from real coaching sessions.