[HerraBRE]

It's not mentioned in the article, but there is an underlying point that affects hiring for roles like this: you need people who can and will admit they don't know everything and will ask for help rather than wing it.

"Rock stars" are downright dangerous, as are people who prefer to make things up rather than admit ignorance.

A new SRE doesn't need to know everything (and can't). But he absolutely needs to be curious and willing to ask for help.

[btmiller]

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?

[no_wizard]

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.

[asuffield]

(I'm an SRE at Google. My opinions are my own.)

> 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.

[HerraBRE]

Mostly it meant SREs tended to be older than other engineers at Google (I was an SRE there for a while), I think by an average of nearly a decade.

Broad experience, depth on a few topics. It's not impossible at all, it just takes time.

(edit: Note this may have changed since I left the company in 2009. It's been a while!)

[wickawic]

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".

[inlined]

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.

[user5994461]

You don't, you just wait and struggle to find the 0.00x % of people who fits the role.

There is a reason that this is an impossible to fill role.