[rfoo]

The problem is, one with transferable skills can get themselves to "speak AWS" in maybe a few hours, once they know exactly what they are going to use (or what needs to be done).

[scarface74]

Those “skills” are only transferable if all you plan to do is spin up a few VMs. Have you looked at all of the different services that AWS as well Azure and GCP offers above just hosting services?

Anyone who comes to any cloud provider with that mentality actually is worse than someone who has no experience.

That’s just as bad as someone who models a schema for a database meant for analytics the same way that model a database meant for transactions and wonders why it isn’t performant.

[rfoo]

> Have you looked at all of the different services that AWS as well Azure and GCP offers above just hosting services?

I have checked their huge product offerings a few times when I needed something I know they must have, and used that, like AWS Batch and AWS SQS.

As for "all of the different services". No, I haven't, but I can, and I will do that, on demand. My point is exactly that I don't want to sink huge time into reading their documentations for something I may never use. And I don't believe it is correct to prefer candidates who did that.

[scarface74]

The problem isn’t knowing every service in detail. It is knowing the “what” and not necessarily the “how”.

But the attitude that a cloud provider is just a bunch of VMs leads to crap like hosting everything on VMs, reinventing the wheel etc.

You wouldn’t hire a database admin with no database experience and expect them to learn on the fly. Why hire someone with no experience with your cloud provider and hope they would learn on the fly?

Any technology/service/language has footguns and best practices that you only learn from experience.

[mettamage]

I think you and the comment above lay out both sides of the argument pretty succinctly.