That brings to mind another interesting point--even if you can tell what DevOps isn't, so much of a "DevOps" role at any particular company is dependent on the technologies that the company has adopted. I imagine DevOps looks wildly different at a company that deploys a monolith to an EC2 autoscaling group versus the company that deploys microservices to Kubernetes. Similarly, whether you use a monorepo or a multirepo. These sorts of concerns drive virtually everything about the DevOps role--the entire structure of the CI/CD pipeline, the strategies for fast rollbacks, the local developer tooling, how much time you spend at which layer (e.g., if you deploy to EC2, you're probably spending a good chunk of upfront time configuring log exfiltration and process management versus something like Fargate). And this says nothing about which cloud provider you're familiar with, or the cultural concerns (one company's DevOps might be chartered with driving cultural change while another's is taking strict orders from management).

Given how large the gap between any two given DevOps positions, I wonder how valuable it is to have "DevOps" job reqs or conferences or other "DevOps" things.