[dvtrn]

I recently had a first round interview with a hiring manager, not a recruiter. It served as the screening call and hiring manager call.

I was a bit surprised, as I’ve long said how much I want to talk to the HM as early as absolutely possible.

Of course then I learned said HM had only been at the org for two months and the entire Infra team was ostensibly just the hiring manager on the other side of the zoom call and I was suddenly a great deal less enthused and interested in the role.

[kolanos]

> Of course then I learned said HM had only been at the org for two months and the entire Infra team was ostensibly just the hiring manager on the other side of the zoom call and I was suddenly a great deal less enthused and interested in the role.

Why?

[dvtrn]

Rant incoming, you asked for it ;)

Having been in organizations where the Devops/Infra org was brand new, it's not something I'm remotely eager to be a part of again.

Some people have the tolerance to be the 'founding' Devops/SRE talent, who help the company go through that "transformation" from the ground up, implement the IR process, create the standards, win the hearts and change the minds, and thrive when the Devops tradecraft and practice is very new to the parent organization.

I'm not one of those people.

Some people would balk and say "shouldn't this be done by a CTO?"

and my honest answer would be "I don't know anymore", because I really don't. I keep hearing Devops needs buy in from the top. And I used to think so too. Then I found myself eight years into this field and seeing the rhetoric was CONSISTENTLY failing to match the reality of whatever the hell we're "supposed" to be doing in Devops, because it can mean whatever the org needs it to mean. And I'm just cynical enough to think, nowadays, that companies know this. They know they can just slap the Devops job title or SRE job title on any assortment of tasks that do not improve developer experiences, minimize toil, improve quality or provide visibility to applications, services and infrastructure and get droves of candidates.

So many Devops/SRE job descriptions lately point out the painful truth that so many companies are cargo culting their way through operations; they don't know what they actually need, they don't know who they need to be hiring, and as a result you end up with companies hiring "Devops enginees" to do any kind of technology work that isn't writing app features or building a product thing.

I've gotten around this by having a litany of very specific questions I ask in interviews (which have been commented on "wow you ask some VERY tough questions". Yes. I know. That's intentional), and a pencil cup full of little yellow, orange and red flags that I look for when deciding if I want to continue interviewing at an organization or not.

"Our devops team is brand new, I'm the manager, and I just started a month ago"

is one such red flag. Doesn't mean it's a bad organization or they have bad people, just that it's a bad organization for me.

[kolanos]

> Some people have the tolerance to be the 'founding' Devops/SRE talent, who help the company go through that "transformation" from the ground up, implement the IR process, create the standards, win the hearts and change the minds, and thrive when the Devops tradecraft and practice is very new to the parent organization.

As someone who has been this founding engineer in the past, in my experience, this is a fun situation to find yourself. There is rarely a "win the hearts and minds" aspect when at such an early stage. As long as it works, you're golden. You literally get to call all the shots, pick all the tech, lay the foundation and the bill really only comes du when you're building a team around it and your engineering hires start asking questions. They're usually good questions, and are usually known issues (although sometimes you can learn a lot from another experienced engineer assessing your architecture), but it becomes work from that point forward. Assuming you get that far, which if you do you've largely succeeded as engineer #1 as your technical decisions didn't take the company down with them.