It's an interesting dilemma in my mind. I remember reading through the SRE book about how SREs a required to have both depth and breadth. Seems like a nearly impossible target to hit IMO, so how are you supposed to simultaneously reconcile deep/broad abilities with humility when hiring for SREs?
Our litmus test is this, I don't know if it gets to the heart of the question but I feel it does.
We look at essentially, (but not unequivocally) these things
1. Proven experience and desire to learn is a must. One of the best i have ever worked with came from a place where they worked pilot projects, and had to manage all their infrastructure themselves as the developers. No certs, no formal SRE experience (IE, thats not why he was employed previously). One of the best. He loved the work, and I could tell he learned so much doing this. It doesn't have to be this extreme, but having a proven interest in this line of work is top priority.
2. Is their depth better than their breadth? It is correct that you need a LOT of breadth, however I value the depth first. I'd rather someone have say, a medium about of breadth on the different technologies out there and a lot of depth on core subjects, like container management (this happens...everywhere nowadays) or cluster management. I don't need you know every single implementation of this in depth though. I need you to at least know one implementation of this in depth. I can build on that.
3. Because of the first 2, I need someone who is team oriented, as always.
> core subjects, like container management (this happens...everywhere nowadays) or cluster management
Curiously, these are subjects which most Google SREs won't know much about. One team deals with all that stuff as a service so the rest of us can get on with something else.
What would I pick out as our core skill sets? Ignoring technology-specific details that won't apply anywhere else: troubleshooting a system that you don't understand (reverse-engineering it as you go), and non-abstract large system design.
Depth + breath is another way of saying experience. Program long enough and you'll learn all sorts of little nasty things about garbage collection and permissions and tcp packet headers and faulty JSON parsers. All of it crystalizes into those little moments when you think "I've seen this shit before".
I always reconciled this as a T shaped graph instead of a box. It's important to have depth in the service area you can control and a breadth of understanding across your dependencies since Google builds service oriented architectures.
