r/platformengineering

I'm currently working as a backend software engineer with ~2 years of experience. My primary language is Go, though I'm also comfortable with the Java ecosystem and enjoy working with it.

Recently, I had the opportunity to interview for an SDE-2 role at a large tech company on their cloud infrastructure team. As part of the interview preparation, I had to learn Kubernetes and dive into infrastructure concepts. Surprisingly, I found myself enjoying that side of engineering much more than I expected.

Now I'm considering whether I should transition into Platform Engineering.

To clarify, I'm not looking to move into traditional DevOps or SRE roles where the focus is primarily on operations, on-call, and production support. I'd still like to spend most of my time building software (ideally in Go/Java), but on developer platforms, internal tooling, Kubernetes, cloud infrastructure, and automation.

A few reasons I'm considering the switch:

• I genuinely enjoy infrastructure and distributed systems.
• Platform engineering seems to involve a lot of backend engineering along with infrastructure.
• The talent pool appears smaller than general backend development (though I could be completely wrong).
• It feels like a specialization that may remain valuable as AI tooling improves.
• Compensation at top companies seems comparable to backend software engineering.

At the same time, I'm worried about accidentally ending up in a role that's closer to DevOps/SRE, with frequent on-call rotations and a worse work-life balance.

For those of you working as platform engineers:

• What does your day-to-day work actually look like?
• How much of your time is spent writing code versus operational work?
• Is platform engineering a good long-term career path compared to backend software engineering?
• If you were in my position (2 YOE backend with Go), would you make the switch?

I'd really appreciate hearing about your experiences and any advice you have.

I am currently building a central Kubernetes Platform where teams can provision clusters to run their workloads on. I am quite exposed to the Kubernetes ecosystem and also contribute to k8s myself. Apart from that I deal with observability topics. However we own the whole platform as one team and everybody does a bit of everything.
I now have an offer from a great brand. The team provision and own dev tooling companywide, like CI/CD pipelines, security scanning and OPA policy automation. They run this on serverless functions. So I would not deal with kubernetes / linux and scaling concerns anymore. One huge advantage is a 40% salary bump and the company is a nice brand on the CV, I could leverage for my further trajectory.

However I wonder if I would be able to move back to what I am currently doing, as I see myself long term in an infra role. Moreover, independent of salary, what do you believe as a more valuable "skill"? Developer platform vs infra / runtime platform work? I feel that many top-tier tech companies are looking for people that have done what I am doing now and not what the new role offers.

I’m considering a 2-year opportunity on a platform engineering team and trying to understand whether the work would be valuable for long-term career growth.

The role is helping application/project teams onboard to cloud, supporting cloud account/environment setup, helping with installation and configuration of software on cloud, creating reusable images or setup processes, and helping transition project work into an operational service model.

My concern is that I would be leaving a stable permanent role for this 2-year opportunity, so I want to make sure the experience would actually build marketable platform engineering skills rather than just being coordination/process work.

For people working in platform engineering:
- Does this sound like real platform engineering experience?
- What parts of this role would be most valuable for future DevOps/platform/cloud roles?
- What red flags should I watch for to avoid ending up in mostly coordination/process work?
- If I take this role, what skills should I focus on building during the first 6–12 months?

I’m early in my career and trying to weigh stability against stronger technical growth.

Let’s be honest, the tech we use today is amazing, but it can also be complex.

It’s only natural that teams want to build platforms that hide this complexity to improve productivity, avoid mistakes, and reduce cognitive load. But they may be misled to believe that the more complexity they hide, the better their platform is. Instead, they end up creating dangerous illusions!

This talk reflects on two decades of building complex distributed systems, highlighting where abstractions helped and where illusions led to major disappointments.

Hi everyone,

AI has become incredibly useful for software development, coding assistants, code reviews, and debugging. However, I don't see nearly as much discussion about applying AI to infrastructure and platform engineering.

I work mainly with Linux, Kubernetes (AKS, EKS, and GKE), observability tools like Grafana and SigNoz, and cloud infrastructure in general. I'm interested in finding practical ways to use AI beyond simply generating scripts or YAML files.

I'm looking for real-world use cases such as:

• Incident detection and root cause analysis
• Kubernetes troubleshooting
• Performance optimization and capacity planning
• Log and metrics analysis
• Infrastructure automation
• Cost optimization
• Security and compliance
• Anything else you've successfully implemented

If you're already using AI in your infrastructure or SRE/Platform engineering workflows, I'd love to hear what you're doing. What tools have actually improved your day-to-day work, and what hasn't lived up to the hype?

Thanks!

Been a platform engineer for almost a year, and started on-call rotation 6 months ago. Had 5 yoe in embedded prior to this.

We currently have 20 engineers across USA and India teams, but this still requires 12 hr on-call shifts for standard environments, and 24 hr shifts for sovereign.

After my first few rotations, Manager asked what would be helpful. I said creating another Europe team based out of the UK (one of the 5 eyes) to enable true 9-5 follow-the-sun on-call rotations. They agreed that it would be a good idea and started the process to start the team.

It's been 3 months now, and when I asked for an update, the manager said they couldn't get approval due to funding constraints. However, we have over 10,000 employees, and 100s are already based out of the UK, so we definitely have the funds and legal requirements to hire another team there.

I suspect they didn't approve of hiring more engineers because my current team refuses to let things fail even when over-extended. This isn't sustainable though, because I wake up to see coworkers in chats until 1am multiple times a week trying to fix things.

I've heard the team's been operating like this for about 8 years now, so driving a cultural change probably won't be possible given how new I am.

Is there anything else I should try to do in this position, or is it time to start looking for a new job?

Platform teams get pushed toward the shiny layer — self-service, AI agents, automation — but the unglamorous foundation is what determines whether any of it holds. Scaling a pipeline taught me the leverage is all in the abstractions:

• Golden paths only work if they're reproducible. No UI changes anywhere — GitHub, AWS console, Grafana. Everything as code, dashboards as JSON in the repo. If you can't rebuild an environment exactly, your "platform" is a set of conventions people drift away from.
• Decouple the runtime early. We built around Helm/Kubernetes, then a database needed dedicated VMs and Helm couldn't follow — it only speaks K8s. One Ansible + Packer playbook that bakes both a container image and a VM AMI removed the lock-in. Terraform/Pulumi as the runtime abstraction matters more the bigger you get.
• Abstract telemetry too. OpenTelemetry so apps emit to a standard interface, not to whatever backend you happen to run today. Swapping backends shouldn't touch app code.

My take: a platform that enforces a standard, monitors it, scales it, and lets parts be swapped out is exactly what makes agents viable. Build the engine first — once it's stable, an agentic layer that monitors and maintains it becomes the natural next step instead of a liability. Full write-up with the tradeoff tables exists, but I'm curious — where's your abstraction layer thinnest right now?

For engineers who have been on-call:

• What was the most frustrating part of your last outage?
• What consumed the most time during investigation?
• Which tools were involved?

I'm collecting insights and would love to learn from real experiences.

Hey Folks, would love some advice from the community,

I'm currently a .NET developer who also handles Azure, CI/CD pipelines, containers, and some Kubernetes work for my team not for company. I've been in the same company for about 4 years and haven't interviewed since.

I'm now targeting Platform Engineer / DevOps / SRE-type roles. I wouldn't consider myself a beginner, but I'm not a senior-level engineer either. I've already covered most of the fundamentals (Linux, networking, containers, Kubernetes basics, CI/CD, monitoring, etc.).

What I'm trying to understand is how AWS is typically assessed in interviews today.

Are interviewers more focused on:

• Architecture and trade-offs?
• System design and operational decisions?
• Cost, scalability, reliability, and security considerations?

Or do they expect detailed implementation knowledge of AWS services such as:

• ECS/EKS
• IAM, STS, Roles, Policies
• VPC and networking design
• Route53
• Auto Scaling

For those who have interviewed recently for mid-level DevOps, Platform Engineer, or SRE roles, what did the AWS portion of the interview actually look like?

Any examples of real interview questions would be appreciated.