[dvtrn]

I don’t know anymore, and honestly I don’t care anymore. If the job wants to call me an SRE fine, if they want to call me Devops, sure.

I’m more focused nowadays on “what problems are you hiring me to solve?” since it feels more and more like the Venn diagram of the three job titles has nearly completely coalesced into a perfect circle.

Difference for me is I’m scrutinizing far more intentionally in job interviews about why an org is hiring for SRE/Devops before accepting any offers. Too often orgs are hiring for this talent and turning them into kitchen sinks for anything and everything the SWEs aren’t doing.

Compliance? Send to Devops.

Upcoming audit and need a pen test done in 3 days? Send to Devops.

Did a bad job prioritizing bug fixes and now shits crashing? Devops.

Etc. once you go through that a few times you start to figure out the right questions to ask in an interview and figure out if you’re about to join a company with Devops practitioners or pretenders.

[dilyevsky]

> “what problems are you hiring me to solve?”

Interviewed with dozen of companies over my career - never been able to get a straight or truthful answer to this

[scottyah]

I’ve experienced similar. What are some of the questions you ask?

[dvtrn]

Take what works you, ignore what doesn't, good luck.

- Why are you hiring Devops/SRE?

- What is a Devops/SRE going to bring that isn't/can't being done by engineers presently?

- Why isn't it being done presently? What have you tried so far?

- How many other SREs/Devops do you have? When will I get to interview with them (if applicable)

- Who is responsible for platform? Infrastructure? Deployments? How are they involved? When are they involved?

etc. As mentioned in my last comment, a lot of it comes through the baptism of working at a lot of really crummy shops to know the kind of bullshit you don't want to put up with. You gotta deal with some of it no matter where you go, but you sure ain't gotta deal with it all.

This is a lot of boilerplate stuff, sometimes you're lucky and these questions get answered before you can ask them, sometimes they're in the job description. So let me talk about that for a minute.

You really want to take your interviewing to the next step? Learn how to inquisitively, but tactfully challenge what you're reading in job descriptions. The answers I've gotten have been far more revealing than "what will I be doing day to day?" if you ask for more details about a bullet point or two and why those bullet points matter, or who they matter to. That includes, yep, on-call.

Most of my other questions are very probing questions about things in the job description; not necessarily because I'm looking for a specific answer, I want to see how the hiring managers and others describe those topics. Can they actually talk about why they're looking for someone to do x, y and z? Can they have a meaningful dialogue about what those responsibilities mean for the team or are they just parroting back what the job description says, like someone in a zoom call just reading words off a powerpoint slide?

Here's an example:

Job says they want a Devops to come in and also be responsible for security, risk and compliance in the infrastructure? Okay, here's my counter-inquiry about that: if Devops has the responsibility for security, risk and compliance, talk to me about the authority Devops has to recommend or deny certain actions in the platform if it is assessed to be too risky or costly to maintain a compliant and secure posture were we to do it anyway (if you've ever been in that unenviable position, you probably know exactly what I'm getting at with this question).

Interviews are two way streets, and in my thirties with a family where "family time" has no fungible cost, I'm driving very defensively on my side of the street.