Certs are a waste of time tbh. If you have 8 years of experience, you should have more than enough to fill out a resume already.

An AWS cert is almost certainly even more useless for you specifically unless you wanted to get into devops/sre and do systems design. I have been in sre for a very long time and have never even heard of anyone writing tooling in Java. That section of the industry is entirely dominated by go, python, and (more often than anything else) bash for really quick automation.

A small container running in kubernetes on an old laptop.

As a counter balance to that though, interviewers need to understand what they are hiring for and tailor the questions asked to those requirements.

For example, there is genuinely very little coding required of an SRE these days but EVERY job interview wants you to do some leetcode style algorithm design… Since containers took over, the times I have used anything beyond relatively unremarkable bash scripts is exceptionally small. It’s extremely unlikely that I will be responsible for a task that is so dependent on performance that I need to design a perfect O(1) algorithm. On terraform though, I’m a fucking surgeon.

SRE specifically should HEAVILY focus on system design and almost all other things should have much much less priority… I’ve failed plenty of skill assessments just because of the code though.

Containerization (even for small things) makes modern infrastructure a LOT easier.

I honestly love it. Of course it’s not perfect but I don’t ever want to go back to the old way if I can avoid it.

Most resistance I have seen mostly comes down to a misunderstanding in the benefits that kubernetes offers. The assumption is that kube is used for autoscaling and that, if the inbound traffic is predictable then the added complexity is unnecessary. When that happens the “kube isn’t right for all situations” turns into “kube isn’t right for any situation” whether the person in question would ever admit that or not…

All of this ignores the MASSIVE reliability enhancement kube delivers and the huge amount of effort currently going into modern tool development surrounding the kube ecosystem.

Real talk, you don’t have the luxury of being an idealist right out of university. Your goal is to get a job. When you’re in that job you will likely not have the luxury of being an idealist either.

When you have enough experience making practical, reasoned decisions, then you can stand on principals.

For context, I have been in this business for nearly 20 years. The people I have personally worked with who have resisted things on philosophical grounds ALWAYS get left behind. I’ve seen it with systemd, the cloud, and now I’m seeing it again with kubernetes. You cannot escape the collective inertia of an entire industry.

Obviously there are still thresholds… I would never work for someone like Raytheon. You have to draw lines somewhere but saying you aren’t going to work for a company that does user behavior tracking is short sighted and impractical.

An RFC that essentially boiled down to saying, in excruciating detail, that I am qualified for the job I was hired for and that I can be trusted not to break the website.

I remember reading about COBOL devs being able to earn pretty solid incomes. I thought, “Let’s check this out.” I found a site that did common things in different languages and compared them. Reverse string in ruby. 1 line. Reverse string in COBOL. 40-50 lines. “Ehh… Maybe I don’t want to learn this after all.”

I have really enjoyed the small projects I have written in rust but, being in the SRE space, it would be irresponsible and selfish to use anything other than bash, python, or go. It feels like the overwhelming majority of tools I use these days have been written in go.

I had this just the other day actually. I am in SRE and the overwhelming majority of the code I write is terraform, instructions for a Dockerfile or CI pipeline, or just some random ass bash to compile information… I don’t actually do that much coding at all and what I do end up doing is pretty rudimentary.

EVERY job interview I go on though wants to do some leetcode style code puzzle. The one I got the other day I just said to the guy, “I honestly don’t know how to do this. The code I write isn’t fancy or clever. It’s mostly just to get things done.” We worked through it together though and I understood the logic by the end but they were mostly holding my hand. What I was doing was throwing out ideas and trying to work out pros/cons with the interviewer. That was enough apparently because he green-lit me for the next round…

These type of interview questions really annoy me because they are not representative of the job in any way. In addition to work, I also have a life that does not involve computers. After putting in a 40 hour week on engineering stuff, grinding leetcode over a weekend is a hard sell.

Meh… Planet of the Alien was better.

Would love to see some base salaries posted along with the responses. If you’re getting paid shit base maybe this is how they make up for it?

I’m in SRE. No on call benefits at all. Base salary is 175k USD plus 20% annual bonus.

The idea doesn’t change if it’s rest or a code library. The version definition would just go in you requirements.txt or go.mod or whatever instead of a url endpoint.

SemVer seems logical. If most of your changes are breaking, I don’t think it really matters if you are releasing often or occasionally though… If it’s often, the users will get fatigued with upgrades. If it’s occasionally, they’ll be overwhelmed and push it off.

If most of your changes are breaking, you should just disclose that the software is in an alpha/beta state and that it can’t be depended on to remain consistent until you have a defined policy about what gets released and when. It will be up to the users to decide if they are comfortable with those terms.

Yeah for this situation, versioned APIs are the answer. If, for example, you look at the kubernetes ecosystem, the entire thing is based on APIs and every resource starts by specifying an api version on the very first line.

apiVersion: v1
kind: Namespace 
metadata: 
    name: example-namespace

This is how they can make upstream changes and not break existing environments in the process.

I think the typical approach is in the opposite direction… Write a comment about what the code should do then have the AI write the code, adjusting for any mistakes it makes.

Branching per environment gets to be a nightmare really quickly. I am trying to avoid that.

I am not worried about vendor lock in.

Same. I haven’t used a Mac seriously since my 2004ish G5 power mac… I’ve been on Linux pretty much exclusively for 20 years. My current job gave me a new apple silicon Macbook though and it’s almost unbelievable how good of a machine that is. I think 90% of that comes down to the chip but still… The software is still mostly just fine but the chip is in a class of its own.