u/TellersTech

Funnily enough I stayed with Riverside for the opposite reason.

They are one of the few online video and audio editors that has MCP integration. So I can have Claude do a rough pass initially (adding images, transitions, simple cuts, adding intro and outro music, etc). It has cut my production time per episode drastically.

That said I do not use their Magic Audio or other built in AI tools very much because I do not like the processing they add. The only Riverside AI tool I use fairly often is the automatic scene creator for interviews. I still modify after the fact, but it gives a good starting point.

I suppose that’s the entire lesson. Using AI as a tool to get you started, but not letting it detract from your voice.

I use AI pretty heavily in devops now. Terraform, k8s, troubleshooting, code, research, pretty much all of it

I wouldnt really go learn "AI" as a seperate thing though. Just start using it in the work your already doing

For me the rule is basically... if I cant explain what it gave me, or tell when its wrong, I probably shouldnt be shipping it

AI gets me from 0 to 70% really fast. The last 30% is still knowing the actual tech well enough to catch the dumb stuff

Thats kinda where I think the skill is going anyway. Less memorizing syntax, more being able to tell when the AI is confidently full of shit

For the first one I’d start with logs... not exec into the container right away. In k8s thats usually kubectl logs, maybe --previous, then describe and see what actually happened

CPU is the same kinda thing honestly.... check metrics first, see if its sustained, throttling, memory pressure, bad traffic, whatever. Then go deeper into the app if infra looks normal

Running as root is mostly a blast radius thing... it doesnt magically mean root on the host, but if theres a bad mount, extra caps, container escape, docker socket mounted, etc, you just made things way worse

Honestly I’d care more in an interview about how someone thinks through these than whether they can give the perfect textbook answer

I wouldnt say its cooked, but entry level cloud is definitely rough right now.

I also wouldnt only search for “Cloud Support Associate.” A lot of companies call basically the same work Cloud Support Engineer, Technical Support, Sysadmin, NOC, junior DevOps, etc.

And certs alone probably wont carry you. Get really good at Linux, networking, DNS, IAM, logs, and troubleshooting. Build stuff and be able to explain how you’d debug it when it breaks.

So no, I dont think you’re wasting your time. I’d just widen the target a lot IMO.

I’d go Python + Cloud Run.

n8n is great for getting something working fast, but I wouldnt want a bunch of important business workflows living in a visual editor a year from now. Versioning, testing, code review, and debugging all get way easier when its just code.

I also wouldnt overbuild it. Cloud Run + Cloud Tasks + Postgres gets you most of what you need. Give every workflow a run ID, make each step idempotent, save state/output/errors in Postgres, and let Cloud Tasks handle retries/backoff.

For observability I’d start with structured GCP logs + OpenTelemetry and add Grafana later if you actually need it.

The one thing I’d avoid is trying to rebuild n8n yourself. Dont build a huge dashboard. Make a tiny admin page later that shows runs, failures, and a retry button.

If the workflows eventually become long-running, human-in-the-loop, or have tons of branching/state, then I’d start looking at Temporal. But for what you described, Cloud Run is probably where I’d start.

Honestly, you’re probably closer than you think, but I wouldn’t limit yourself to jobs with “DevOps” in the title.

That first job is usually the hardest one to get, and a lot of DevOps/platform roles aren’t really entry-level even when companies advertise them that way. I’d also look at Linux admin, cloud support, junior sysadmin, infrastructure, NOC, support engineering, and similar roles. Once you have actual production experience, moving toward DevOps/platform gets a lot easier.

And definitely use the Kubernetes setup you already have. Don’t just put “Kubernetes homelab” on the resume though. Put it on GitHub, document the architecture, what you’re running on it, how you deploy things, monitoring, backups, upgrades, what has broken, and how you fixed it. The troubleshooting stories are probably more valuable than the fact that you got Kubernetes running in the first place.

I also wouldn’t let the degree stop you from applying. Plenty of people in infrastructure got into the field without a bachelor’s. Since you’re already 75% through the associate’s though, I’d probably finish it if you reasonably can. You’re close enough that having the completed credential is worth it.

Mostly, start applying now. Don’t wait until you feel “qualified enough.” Your goal at this point is getting that first bit of paid production experience, even if the first role isn’t exactly where you ultimately want to end up.

Your project list is already pretty solid, so I probably wouldn’t spend a ton of time just adding more tools.

I’d take one of the projects you already have and push it further. Break it on purpose. Figure out what happens when a deploy fails, how you’d roll back, where secrets live, what you’d monitor, how you’d troubleshoot an issue, what happens if a node dies, stuff like that.

Then put that work somewhere public. GitHub, a blog post, a short video, whatever.

A lot of junior resumes end up looking really similar because everyone has AWS, Docker, Terraform, Kubernetes, Jenkins, etc. What helps more is showing that you can actually reason through a system and explain why you built it the way you did.

That gives people something real to evaluate instead of just another list of tools.

Honestly, I think it’s probably a combination of a rough market and something in your application/resume strategy.

The market definitely isn’t great, but I’m still seeing experienced engineers in my network get interviews and get hired. Junior engineers and people trying to break into the industry seem to have it the worst, but senior people absolutely aren’t immune either.

The thing that jumps out to me is that if you’ve been applying since January and are almost never even getting to a recruiter screen, I wouldn’t take that as evidence that you’re a bad engineer. They haven’t actually gotten far enough into the process to know whether you’re a good engineer. It means your resume/application isn’t consistently getting you through the first filter.

I’d also reconsider searching primarily by tools. Kubernetes/Terraform/AWS are so common now that you may be casting a really weird mix of roles. I’d search Staff/Senior DevOps, Platform Engineer, SRE, Cloud Infrastructure, etc. and then filter based on the actual stack and responsibilities.

And yes, absolutely reach out to former coworkers. It feels transactional because we convince ourselves it is, but referrals are incredibly normal. I wouldn’t do the fake “Hey, how have you been?” followed by a referral request five minutes later either. Just be straightforward:

“Hey, I saw your company is hiring for X and I’m starting to look around. It seems pretty aligned with what I’ve been doing. Do you know anything about the team or role? If you think I’d be a fit, would you be comfortable referring me? No worries at all if not.”

That’s not gross. You worked with these people. They actually know whether you’re good.

I’d probably have another experienced engineer or hiring manager review the resume too, not another paid resume service. A resume can be perfectly formatted and ATS-friendly while still doing a bad job showing engineering impact.

So no, based on what you wrote, I definitely wouldn’t conclude “I’m a bad engineer.” But I would treat the lack of recruiter screens as a signal that something before the interview stage needs adjustment.

The bar moves.

If we’re all suddenly 10x developers and we’re solving problems that create real value people will pay for, I don’t think that necessarily means the same amount of software gets built with 1/10th the engineers. We may just build 10x more software.

What changes is what makes someone stand out. Writing code becomes less of the differentiator. Knowing which problems are worth solving, making good architectural decisions, catching when the AI is confidently wrong, understanding the business, communicating well, and actually owning the outcome become more valuable.

AI can make everyone faster. It doesn’t automatically give everyone better judgment.

Outside of the internship or junior-role path someone else mentioned, there are a bunch of ways to build experience.

Contribute to open source or volunteer somewhere.

Build something real, not just follow a tutorial. Document what you built, why you made certain decisions, what broke, and how you fixed it.

Go to meetups, get involved in communities, and find people to collaborate with.

You can also come in through adjacent roles like sysadmin, cloud support, infrastructure, or operations and move toward DevOps from there.

The first opportunity is usually the hardest part. The goal is to give someone evidence that you can actually do the work before they take a chance on you.

Are you intentionally avoiding automation?

I totally get wanting hands-on control over the editing and anything creative that actually affects the show. But for the repetitive publishing stuff like uploads, copy/paste, scheduling, and cross-posting, automation seems like it could save a decent amount of time without giving up any creative control.

Curious if you’ve tried automating any of that and decided against it, or if the manual process just works well enough for you.

Yeah pretty much, although I wouldnt re-run the plan in the apply workflow.

I’d generate/save the plan with read-only creds, review it, then the gated apply uses that exact saved plan with the prod/write creds.

Otherwise you could end up approving one plan and applying another.

/u/eman0821 yeah I just meant stuff like provisioning/deprovisioning through SSO/groups, RBAC, SCIM, Terraform, etc.

For existing enterprise apps though, app owner/admin probably decides the access, IAM/IT handles the identity side, and platform/devops might help automate it depending on the org.

Still very much an “it depends” thing lol.

I’d never just rerun the apply blindly. Refresh state, check what actually got created/changed, then generate a new plan and review it like any other change.

Terraform is usually pretty good at converging, but “usually” is doing alot of work there 😂

Yeah this is one of those “it depends” answers lol.

Usually the app/team owner decides who should have access, IAM/IT handles the identity/policy side, and platform/devops helps automate/enforce it.

In smaller orgs though one team might own basically all of it.

Ive seen both. Backstage is probably the cleanest when teams actually keep the catalog/ownership data current. CODEOWNERS + repo topics/metadata gets you pretty far too

Biggest thing IMO is making ownership part of the workflow instead of a spreadsheet somebody forgets about 😂 Otherwise you eventually end up right back at GitHub search

Yeah pretty much a separate hunt each time 😂
GitHub code search makes it less painful… but with base images I’m usually searching the image name/tag across Dockerfiles, helm values, workflows, etc.

At a certain scale though, thats really a sign you need better dependency inventory/ownership rather than increasingly creative grep commands 😅