We've hired a lot of cloud engineers. And we've noticed a pattern: the question that filters most cleanly isn't about specific services, certifications, or even past experience. It's this:
"Walk me through how you'd design a system that processes 10,000 events per second, where some events are time-sensitive and others can be batched. You have a $500/month budget."
The question isn't designed to have a correct answer. It's designed to reveal how someone thinks under constraint.
What the strong candidates do
They ask clarifying questions first. "What's the acceptable latency for time-sensitive events?" "What does 'processed' mean — stored, transformed, forwarded?" "Is $500 inclusive of storage and egress?"
Then they reason out loud, making their trade-offs visible. "I'd use SQS with two queues — a standard queue for batch work and a FIFO queue for the time-sensitive path. Lambda for the processors, keeping an eye on cold start latency for the critical path. DynamoDB for state. At this volume we're probably looking at $180–220/month for the compute and messaging, which leaves headroom for storage."
What the weak candidates do
They jump straight to a solution. Often it's the architecture they know best, applied without interrogating the constraints. The budget mention barely registers. The distinction between event types gets flattened into one processing pipeline.
What this tells you
Cloud architecture is 20% knowing what services exist and 80% knowing which constraints matter most in a given situation. The engineers who compound over time are the ones who've internalised that trade-offs are the job — not service selection.
If you're preparing for cloud interviews: practice thinking out loud with constraints. The architecture is almost always secondary to the reasoning.
