I Asked 20 Hiring Managers What They Look For in Cloud Interviews - Here's What They Told Me
Why technical skill gets you into the room but storytelling and impact get you the offer.
Hey, it’s Lefteris 👋 I’m the voice behind the weekly newsletter “The Cloud Engineers.”
If you’ve ever walked out of a cloud engineering interview thinking “I answered everything correctly… so why didn’t I get the offer?” then this article is for you.
Over the past few months, I spoke with 20 hiring managers across startups, scale-ups, and large enterprises who regularly interview for Cloud Engineer, DevOps, SRE, and Solutions Architect roles. I asked them a simple question: “When two candidates have the same technical skills, what makes you say yes to one and no to the other?”
The answers were remarkably consistent. And almost none of them were about knowing more AWS services.
Here’s what they’re actually looking for.
The #1 theme: candidates who tell stories, not spec sheets
Nineteen of the twenty managers used some version of the same phrase: “I want to understand how they think.”
The weakest candidates answer questions like they’re reciting documentation. Ask them how they’d design a highly available system and you get a list: “Multi-AZ, Auto Scaling, load balancer, RDS with a read replica.” All correct. All forgettable.
The strongest candidates answer with a story that has a shape:
Context: what was the situation and the constraint?
Decision: what did you choose, and critically, what did you choose not to do?
Impact: what changed as a result, measured in numbers?
Managers don’t just want to know that you can use CloudFront. They want to know that you understood why it was the right call over the three other options you considered, and what it did for the business.
“Anyone can list services. I’m hiring the person who can tell me why they picked one over another and what it cost them when they got it wrong.” — Engineering Manager, fintech scale-up
Why storytelling wins (even for deeply technical questions)
There’s a misconception that storytelling is only for behavioural rounds. It isn’t. The best technical answers are also stories, because storytelling is really just structured reasoning made visible.
When you narrate your thinking as a story, you demonstrate four things at once that a bullet-point answer never can:
Judgment: you weighed trade-offs, not just memorized the “right” answer.
Ownership: you were close enough to the outcome to know what actually happened.
Communication: you can explain a complex system to a stakeholder who isn’t in the weeds.
Self-awareness: you know where it went wrong and what you learned.
Those four qualities are exactly what separates a mid-level engineer from a senior one. And they’re impossible to fake with a list of services.
Impact is the word that closes the interview
The second theme was even blunter. When I asked what makes an answer land, managers kept coming back to one word: impact.
Engineers love to talk about what they built. Hiring managers want to know what changed because you built it.
Compare these two answers to “Tell me about a system you optimized.”
❌ Without impact:
“I migrated our batch jobs from EC2 to Lambda and set up EventBridge to trigger them on a schedule.”
✅ With impact:
“Our nightly batch jobs were running on a fleet of always-on EC2 instances that cost us about $4,000/month but were only active two hours a day. I moved them to Lambda triggered by EventBridge on a schedule. That cut the compute bill for that workload by roughly 80%, around $38k/year, and eliminated the on-call pages we used to get when an instance failed overnight.”
Same technical work. Completely different signal. The second answer tells the manager: this person understands that engineering exists to serve the business.
A simple rule: every technical story you tell should end with a number, a saved hour, or a problem that stopped happening.
A worked example: how to turn a flat answer into a winning one
Let’s take a classic cloud interview question and walk through the transformation.
The question: “Tell me about a time you improved the reliability of a system.”
The flat answer (what most candidates say)
“We were having downtime issues, so I added a load balancer and put the service across multiple Availability Zones. After that it was more reliable.”
It’s not wrong. But it has no context, no trade-off, and no measurable outcome. The manager learns almost nothing about how you think.
The storytelling + impact answer (using Context → Decision → Impact)
Context: “We ran a customer-facing checkout API on a single EC2 instance in one Availability Zone. It was fine until we had two outages in one quarter, once from an AZ disruption and once from a bad deploy, and each one took checkout down for about 40 minutes. For an e-commerce product, that’s direct lost revenue, and it was eroding trust with the business team.
Decision: “I proposed moving to an Auto Scaling group across three AZs behind an Application Load Balancer, with health checks that pulled unhealthy instances out automatically. I deliberately didn’t go straight to containers or a full EKS setup, even though it was tempting, the team had no Kubernetes experience, and I didn’t want to trade one reliability risk for a bigger operational one. The ALB-plus-ASG approach solved 90% of the problem with 10% of the complexity.
Impact: “After the change, we went from two multi-outage quarters to zero customer-facing checkout outages over the next nine months. Deploys became safe because we could roll instances one at a time. And because Auto Scaling replaced failed instances automatically, our overnight on-call pages for that service dropped to essentially zero, which the on-call team definitely noticed.”
Notice what that answer does:
It quantifies the pain before the fix (two outages, 40 minutes each, lost revenue).
It shows a deliberate trade-off (ALB + ASG instead of Kubernetes), proof of judgment.
It closes with measurable impact across three dimensions: reliability, deploy safety, and team quality of life.
That’s the difference between “I know the services” and “I know how to use the services to move the needle.”
How to prepare before your next interview
You don’t need to memorize more services. You need to package what you already know into stories. Here’s a practical drill:
List your last 5–6 real projects. Anything you touched like a migration, a cost cut, an incident, a pipeline.
For each, write three lines: the Context (the constraint), the Decision (and the road not taken), and the Impact (with a number).
Attach a metric to every story. Dollars saved, latency reduced, deploy frequency increased, incidents eliminated. If you don’t know the exact number, estimate it honestly (”roughly”, “about”) as managers value the instinct to measure.
Practice the trade-off out loud. For each story, be ready to answer: “What else did you consider, and why didn’t you pick it?” This is where senior candidates separate themselves.
Do this for six stories and you’ll have a toolkit that covers almost any technical or behavioural question they throw at you.
The takeaway
Twenty hiring managers, one message: technical skill gets you into the room, but storytelling and impact get you the offer.
The candidates who win aren’t the ones who know the most services. They’re the ones who can take a real problem, walk you through how they thought about it, name the trade-offs they made, and show with numbers what changed because of it.
Next time you prep, don’t ask “Do I know enough AWS?” Ask “Can I tell the story of what I built, and prove it mattered?”
That’s the answer hiring managers are actually waiting for.