[pedoh]

I think these are pretty good guidelines, but treat them as guidelines and not as hard and fast rules. For example, I'm a "DevOp", but have only a little amount of open source code published because for most of my career I've worked for companies that have owned my code and not released it as open source.

A good DevOp is continually trying to automate himself out of his job, and is always looking to make operations processes (like code deployment) smoother and simpler, even in the face of restrictions that inevitably get put into place when the company is facing acquisition or IPO and has to be SOX compliant. "cap deploy" is great, but will only take you so far until you'll need to at the very least wrap some ACLs around it.

[kfcm]

I wholeheartedly agree with these being guidelines. But--having been in this industry for 25 years--I know too many people would treat them as hard and fast rules. It's just simpler to check off boxes than to assess the capability of a person to learn.

What one really needs isn't a code portfolio in GitHub. It's not a mastery of Chef or Puppet. It's not knowing all the details of every relational database plus NoSQL. No, what's needed is the ability to learn and learn quickly; the other stuff is the nice-to-have-du-jour.

[jmccree]

I can't second this enough. I've held the job title "DevOps Engineer" twice, and the #1 thing is having enough of a background of all areas to pickup any part of the stack and run with it.

If you want to hire devops, the best interview question I've ever heard is (I believe) from John Allspaw. It's simply "describe what happens from when you enter an address and click go in your browser til the page is displayed".

The beauty of this question is, it's not a trick, there's no right or wrong, but it shows how narrow or wide a scope the person has. Do they mention the browser, os, resolver DNS caches? Do they focus on TCP or HTTP? Do they describe how BGP routing works and the carrier hotels the connections go through? Do they mention how they're may be proxies, load balancers, etc before getting to the web servers? Do they understand how the request is transferred to your programming language of choice? Do they know how css/js assets are loaded by the browser and benefit of using multiple subdomains? Do they walk you through how the browser does the rendering?

I've asked that question to every candidate I've interviewed since I've heard of it, and it's never failed to enlighten me of where the candidate's strengths lay.

From just my questions above, you can likely tell I have little interest in the OS/hardware layer. Somebody else may emphasize all the kernel caches and I/O operations, etc. :)