Supreet Sethi

Posted on Nov 27

I Hired AWS SAs for 5 Years. Now That I've Left, I Can Tell You the Truth

tl;dr: I spent five years interviewing SA candidates at AWS. Comprehensive AWS training doesn't correlate with hire decisions. Production talk and clear thinking do. Now that I'm external, I can say it plainly: most interview prep is wasted effort.

The Uncomfortable Truth

I was a Principal SA at AWS for two years. I sat on hiring panels as a Manager after that for three years. I made hire/no-hire decisions. I watched hundreds of candidates prepare the wrong way and then blame themselves for not studying hard enough.

Now that I've left, I can say this plainly without corporate-speak: your comprehensive AWS study guide is doing more harm than good.

We don't care if you memorized the Well-Architected Framework. We didn't care if you studied all 200 AWS services. We cared if you could think clearly about tradeoffs, defend a decision under pressure, and admit when you didn't know something.

Yet every study guide, bootcamp, and LinkedIn thread screams the same lie: you need comprehensive AWS training.

You don't. In fact, it often works against you.

What Happens in the Room

Your interviewer—especially if they're a Principal or staff engineer—already knows you haven't deployed infrastructure across 47 different AWS services. They're not testing breadth. They're testing depth of thinking and production judgment.

Here's what I paid attention to when candidates walked in:

1. Production context—where's the real decision?
"I've built with EC2 and RDS" is fine. But I listened for why you made choices. Instance families? Why? Scaling problems? Walk me through one. Connection pooling in production? Perfect—now we're talking about real engineering.

The candidates I voted to hire almost always had one or two services they knew cold because they shipped something real. The ones reading from study guides tried to sound like they knew everything, and it was immediately obvious.

2. Can you think on your feet?
I watched how people handled "how would you architect X?" If they recited a framework answer, I'd already mentally moved on to the next candidate. If they asked me clarifying questions, identified genuine tradeoffs, and said "I'd lean toward Fargate here because—," I'd lean forward.

The best moment in an interview is when a candidate says "I haven't used that, but here's my hypothesis based on..." That's the real move. That's how actual architects work. They don't know everything. They think.

3. Honest gaps are revealing
I built my hiring questions specifically to find the difference between "studied this last week" and "this is my blind spot." When someone said, "I'd need to research that, but here's my starting point," they immediately became more credible than someone bulldozing with buzzwords.

The worst interviews? Candidates stalling on basic questions while clearly trying to remember what slide 47 of their bootcamp said.

The Training Industrial Complex (Or: Why Your $500 Course Hurt Your Chances)

Five years on the hiring side has shown me a clear pattern: candidates who take comprehensive AWS training courses often perform worse than those who don't.

It's counterintuitive, but the data's there:

Candidate studies 200 services -> interviews with surface-level knowledge of many, depth in none
Candidate ships one project with EC2/RDS -> interviews with real architectural thinking
Interview panel immediately spots rehearsed answers and deprioritizes
Candidate blames themselves: "I should have studied the ECS section more"

Wrong diagnosis. Your study guide didn't help you; it convinced you that breadth matters more than depth.

The cruel cycle:

Candidate feels anxious > buys $500 "Complete AWS for SAs" course
Course teaches 200 services at surface level
Candidate memorizes facts they'll forget in 2 weeks
Interview panel spots the rehearsed answers within 10 minutes
Candidate doesn't get the job
They blame themselves for not studying harder

I've sat through hundreds of interviews. The training industry profits off this anxiety loop while genuinely hurting candidate performance.

What You Actually Need

For the phone screen:

Production experience with at least one primary service (compute, database, or whatever)
Ability to discuss a real project: what worked, what didn't, what you'd change
Willingness to think through new problems without pretending you have all the answers
AWS fundamentals (VPC, IAM, Security Groups, GW, basic networking)—these are legitimate

For the technical discussion:

Deep knowledge of services you've used
Framework for thinking about tradeoffs (cost vs. complexity, availability vs. simplicity, etc.)
Ability to pivot and explore adjacent solutions
Comfortable saying "I'd need to research that, but here's my starting hypothesis"

That's genuinely it.

The Real Test: A Rugby Social Network Migration

Let me walk you through an actual scenario AWS uses in interviews—and what separates the good architects from the ones who fail despite being technically sound.

The problem: A rugby-focused social network with 2M users, growing 5x in the next 12 months. Currently on-premises in Dallas. Budget: $25K/month (15K hosting, 10K CDN via Akamai). Users spread: US 30%, Europe 50%, Asia 20%. They need to move to AWS.

Bad SA answer (technically competent, but fails):

"We'd use EC2 for compute, RDS for the database, S3 for video storage, CloudFront for CDN to replace Akamai, ElastiCache for sessions, Route53 for DNS, Auto Scaling groups, VPC with public/private subnets across three AZs, IAM roles for service-to-service auth, CloudWatch for monitoring, potentially Lambda for event processing, maybe Kinesis for real-time notifications, SQS for async jobs..."
Goes deeper: task definitions, RTO/RPO, security groups, NACLs, database backup strategies
Panel internally: "They know AWS components. But I have no idea if they can actually make a decision."
Rejected (despite being technically correct)

Good SA answer (the one I hire):

"Three regions: us-east-1 for US traffic, eu-west-1 for Europe, ap-southeast-1 for Asia. Each region gets an application tier and a database. We'll start with EC2 for the app layer—I'd use t3.large with ASGs to handle the 5x growth. RDS Multi-AZ in each region for data durability. We're replacing Akamai with CloudFront, which saves 10K/month immediately and actually improves latency in Europe and Asia."
Pauses. Asks clarifying questions: "Are writes distributed or mostly from content creators? How real-time are notifications? Is the data read-heavy or write-heavy?"
Listens to answer, then adapts: "If it's 80/20 read/write, we could add ElastiCache in front of RDS to reduce database load during peak traffic. If the user base is mostly mobile, we might want to think about API Gateway + Lambda instead of EC2 to reduce operational overhead—but EC2 gives us more predictable scaling for a 5x ramp."
When asked about databases: "RDS is safe here because we're relational. DynamoDB would require a schema redesign we don't have time for during a 5x growth. We validate that choice once we see real query patterns."
Hired (someone who thinks, not someone who lists)

The difference? The good SA made three architectural decisions (regional distribution, EC2 over serverless, RDS over NoSQL) with clear reasoning based on constraints. The bad SA listed every service and hoped some combination was right.

Then I tweaked the problem: "What if we need to migrate 500TB of video content and we can't afford 6 months of dual-running on-prem + cloud?"

Good SA pivots in real time:

"We'd use AWS DataSync to replicate data continuously for the first month while we're in parallel. Once the on-prem systems reach end of life, we flip the DNS. But more importantly, we don't need S3 for video storage if we're staying with Akamai for CDN—Akamai has edge storage. So we replicate video to Akamai's origin once, we store backups in S3, but the application doesn't serve from S3. That keeps our architecture simple and maintains the budget."
Still hired (adapted correctly)

Bad SA in same scenario:

Panics slightly. Falls back to memorized migration strategies.
Starts listing: "We could use AWS DataSync, AWS Direct Connect, AWS Snowball..."
Doesn't actually choose or reason about cost and timeline.
Still rejected (couldn't think under pressure)

Why "Describe Every Component" Actually Kills Your Interview

When you try to faithfully describe every possible AWS component in your architecture, you're signaling something deadly to the panel: you're not making decisions. You're reciting a design.

Here's what happens in the room:

The candidate who maps components:

Lists RDS, EC2, S3, CloudFront, ElastiCache, Route53, IAM, VPC, subnets, security groups, NACLs, KMS, CloudWatch, CloudTrail...
For each one, provides correct technical details
Panel thinks: "They know AWS. But I don't know if they'd actually make this decision if costs were cut in half. Do they know why each component is there, or are they just pattern-matching to 'enterprise architecture template #42'?"

The candidate who makes three decisions with reasoning:

"Multi-region for latency (us-east, eu-west, ap-southeast). EC2+RDS+CloudFront at each region. No serverless yet—5x growth means we need predictable scaling."
For each decision, brief reasoning: cost, operational burden, time-to-migrate
When challenged ("What about DynamoDB?"), they know why they chose RDS instead
Panel thinks: "If requirements change, this person will adapt the design, not rebuild from a different AWS architecture template."

The second person will design better systems under real pressure because they're reasoning about tradeoffs, not memorizing patterns.

The interview is testing your ability to:

Make decisions under constraint (time, budget, team skills)
Explain decisions in 30 seconds (broad strokes)
Change your mind when new information arrives (during the tweaks)

It's not testing whether you know all 200+ AWS services exist.

The cloud industry's obsession with breadth-first interview preparation isn't about better hiring. It's about justifying expensive training platforms while maintaining the illusion that AWS is harder than it actually is.

AWS is not hard. Thinking clearly about tradeoffs is hard. And no course teaches that. Only production teaches that.

Now that I'm building hiring processes at a new company, I'm explicitly deprioritizing "studied the most material" in favor of "shipped the most thoughtful decisions." We ask fewer "how many EC2 instance types exist?" questions and more "walk me through a bad architectural decision you made and how you'd change it." That's actually predictive. That's the kind of candidate who will design better systems under real pressure.

How to Actually Prepare (The Right Way)

Stop thinking in components. Start thinking in decisions.

Pick a real migration or scaling problem. Use the rugby case as a template:

2M users growing 5x in 12 months
Geographic distribution (not just US)
Budget constraint ($25K/month)
Existing infrastructure you're replacing

For your practice problem, write down:

Three architectural decisions. Not "use EC2, RDS, and CloudFront." Write: "Multi-region distribution because 50% of traffic is Europe and latency matters. EC2 instead of Fargate because we need cost predictability during 5x growth and ops team is Linux-comfortable. RDS instead of DynamoDB because schema is relational and migration timeline is tight."
Why each decision, in one sentence. If you need three sentences to justify it, you don't understand it well enough.
What you'd change if... Cost cut in half? Timeline compressed to 6 weeks? User base only in US? Changing any constraint should trigger a design change. If your design doesn't flex, you don't own it.

In the interview, lead with the broad strokes:

"I'd go multi-region, EC2+RDS in each region, CloudFront for CDN, and here's why..."
Don't list components. List decisions.
When they ask about a component you didn't mention ("What about caching?"), say: "Good point—I'd add ElastiCache if query patterns show we need it, but we validate that in week two post-migration. Right now, I'm optimizing for certainty over premature optimization."

Be ready for the tweaks:

"What if migration takes 2 weeks, not 2 months?" → "We'd use DataSync and parallel run, but that changes our budget. What's the hard constraint?"
"What if the team is Node.js only, not infrastructure-familiar?" → "Serverless becomes more attractive. Lambda+RDS+API Gateway probably safer than managing ASGs."
"What if they won't pay for multi-region?" → "Single region initially, but we architect for multi-region addition—CloudFront origin failover, RDS read replicas we can promote. Route 53 health checks point to healthy region."

This is how real architects work. You start with broad strokes, you defend those strokes, and you pivot when constraints change.

Final Thoughts

If you're preparing for an AWS SA role and thinking "I'm not ready because I haven't studied enough," stop. You're probably overthinking this.

You're ready if you can talk about real production problems and think through new ones. That's the job.

Stop cramming. Start shipping. The interview will feel different when you have stories instead of slides.

Curious if your production experience translates? Talk about a real architectural decision you made, no matter how small. That's your interview prep.