From New Grad SWE to Platform Engineer: Career Paths and Tech Stack Choices in the AI Era

A New Graduate's Real Dilemma

Recently, a developer who had just earned a Bachelor's degree in Computer Science and was about to pursue a Master's in AI posted on Reddit seeking advice. His goal was clear: to become a Platform Engineer on an AI/ML team. But he ran into a practical problem—in the UK, entry-level Platform Engineer roles for new graduates are extremely scarce.

He had 14 months of backend SWE internship experience (primarily using C#), with roughly a 14-month window before his official start date. His plan was to first join a company as a graduate software engineer (Grad SWE), then transfer internally to a junior Platform Engineer role. On the other hand, he was also considering whether to fully pivot to a Python tech stack during this gap period.

This case is highly representative and reflects a common dilemma faced by many tech newcomers in the AI wave: they want to break into the cutting-edge ML/infrastructure space while also maintaining job stability and salary levels. Let's analyze this from an industry perspective.

reddit source

Why Are Platform Engineer Roles So Hard for New Grads to Land?

Platform Engineering is fundamentally a composite role that requires accumulated experience. As an independent engineering discipline, it originated from the deepening evolution of the DevOps movement in the mid-2010s. With the proliferation of microservices architecture and cloud-native technologies, large engineering organizations found that development teams were spending significant effort on infrastructure automation and toolchain maintenance—giving rise to platform engineering. Its core philosophy is to build an "Internal Developer Platform" (IDP), enabling business development teams to access standardized infrastructure capabilities in a self-service manner, allowing them to focus on business logic.

It's worth understanding in depth that the concept of an IDP didn't appear out of nowhere—it's an inevitable product of the deepening of DevOps culture. Spotify's open-source Backstage platform is the most representative IDP implementation, integrating scattered infrastructure tools into a consistent developer experience through a unified service catalog, scaffolding templates, and a technical documentation portal. The core design philosophy of Backstage is "pluggability"—any team can build custom plugins on its framework, unifying tools like Grafana monitoring dashboards, PagerDuty alerts, and GitHub Actions pipelines into a single entry point. Gartner predicts that by 2026, 80% of large software engineering organizations will establish dedicated platform engineering teams, and reducing "Cognitive Load"—i.e., minimizing developers' mental burden on non-business engineering problems—has become a core metric for measuring IDP effectiveness. This aligns closely with the Team Topologies methodology: the framework divides engineering teams into "Stream-Aligned Teams" and "Platform Teams," with the former focused on delivering business value and the latter responsible for eliminating the former's technical friction. This is fundamentally different from pure coding work—it requires engineers to simultaneously possess multidimensional capabilities in system architecture, CI/CD pipelines, container orchestration (such as Kubernetes), cloud infrastructure, and cross-team collaboration.

It's worth noting that within AI/ML teams, an even more specialized branch has emerged—MLOps (ML Platform Engineering). This direction heated up rapidly after 2020 as the demand for large model training and inference deployment exploded. Compared with traditional platform engineering, ML platform engineering must additionally handle ML-specific engineering challenges such as model version management, feature engineering pipelines, GPU resource scheduling, experiment tracking (such as MLflow, Weights & Biases), and model monitoring and drift detection.

The MLOps tooling ecosystem is already quite rich and clearly layered, and understanding this layered structure is crucial for engineers aiming for the ML platform direction. At the experiment tracking layer are MLflow and Weights & Biases, which help teams record hyperparameters, metrics, and model versions, solving the problem of "which configuration was this model trained with"—an issue that easily spirals out of control in large-scale experiments. At the feature store layer are Feast and Tecton, which specifically address the core challenge of feature consistency between training and inference stages—i.e., "whatever features were used during training must also be computable in real time during online inference." This problem is especially critical in scenarios like financial risk control and recommendation systems. At the model serving layer are Seldon Core and BentoML, responsible for exposing trained models via standardized REST or gRPC APIs and handling engineering issues like hot model updates and A/B test traffic splitting. At the orchestration layer are Kubeflow Pipelines and Apache Airflow, which manage end-to-end ML workflows, chaining data acquisition, feature engineering, model training, evaluation, and deployment into repeatable directed acyclic graphs (DAGs). Ray, as a distributed computing framework, spans multiple layers—it can be used for large-scale hyperparameter search (Ray Tune), distributed model training (Ray Train), and online inference (Ray Serve). These tools exist precisely to address the complexity of deploying ML workloads at scale on Kubernetes clusters, further raising the skill bar for ML platform engineers.

The Experience Barrier for the Role

Companies are generally reluctant to let new graduates directly manage production infrastructure—failures in platform engineering often ripple across the entire development team and even live business, carrying high risk. Therefore, recruiters generally favor candidates with 3 to 5 years of experience. This also explains why entry-level Platform Engineer roles are so scarce: this isn't a phenomenon unique to the UK, but a general rule across the global industry.

The UK job market context is also worth noting. The UK is one of Europe's most important centers for AI research and industry. London hosts top AI companies like DeepMind and Waymo UK, while also boasting a vibrant fintech ecosystem, with sustained strong demand for ML platform engineers. However, the UK market has its structural characteristics: compared to Silicon Valley in the US, starting salaries for graduate SWEs are slightly lower, but joining large banks with strong ML operations (Barclays, HSBC), consulting firms (Palantir UK), or tech unicorns is a realistic path to gaining AI infrastructure experience in the UK.

Is the "Roundabout" Route Viable?

The poster's strategy of "first working as a Grad SWE, then transferring internally" is a highly pragmatic path validated by many practitioners. The vast majority of platform engineers transition from backend development or operations roles. By accumulating experience in an SWE role, newcomers can:

Gain a deep understanding of how real business systems operate
Get exposure to operations aspects like deployment and monitoring in daily work
Build internal connections that lay the groundwork for a role change

The key is that once inside the company, you should proactively seek out infrastructure-related tasks rather than passively wait for opportunities to come to you.

C# or Python? The Logic Behind Tech Stack Trade-offs

The poster's other core dilemma is: should he abandon the 14 months of C# experience he has accumulated and fully pivot to Python?

Reasoning Backward from the Goal

If the ultimate goal is platform engineering on an AI/ML team, Python is almost unavoidable. The ML ecosystem (PyTorch, TensorFlow, Ray, etc.), the data engineering toolchain, and a large amount of DevOps automation scripting are all dominated by Python. Strategically, investing time to systematically learn Python is reasonable and necessary.

But There's No Need for an "Either/Or" Approach

However, equating "pivoting to Python" with "abandoning C#" is a common misconception. Understanding this requires recognizing the difference in how the two languages are positioned within enterprise ecosystems. C# is the core language of Microsoft's .NET ecosystem, dominating in fields like finance, healthcare, and enterprise-grade ERP that demand strong typing and high stability. Its static type system, mature asynchronous programming model (async/await), and powerful IDE support give it significant advantages in large team collaboration. Python, on the other hand, has become the universal language of AI with its extremely low barrier to entry and rich scientific computing ecosystem. The two are not competitors—C#'s strongly-typed mindset can actually help developers write more rigorous, more engineering-minded Python code, which is precisely why the "dual-stack" strategy has been widely validated as effective in practice.

A noteworthy trend supports this judgment: in recent years the Python community has been vigorously promoting type hints and static type checking tools (such as mypy and Pyright), which is essentially moving toward C#'s engineering rigor. Developers with a C# background can often more naturally accept and leverage these tools, writing more robust Python codebases in team collaboration. It's worth mentioning that Python 3.12 and subsequent versions have continued to strengthen the expressiveness of the type system, and Pyright (developed by Microsoft and also the underlying engine of Pylance) has raised the precision of type inference to a level approaching that of C# language servers. For C# developers accustomed to Visual Studio's IntelliSense, this means they can get nearly the same development experience when writing Python in VS Code.

For platform engineers, languages are just tools; the real core competitiveness lies in engineering capability and systems thinking. The understanding of type systems, asynchronous programming paradigms, and API design accumulated through C# backend experience can be fully transferred to other language environments.

A wiser strategy would be:

Keep C# as an existing strength and continue to solidify backend fundamentals
Incrementally learn Python, focusing on automation scripting, data processing, and ML engineering scenarios
Simultaneously systematically build core platform engineering skills: Docker, Kubernetes, Terraform, mainstream cloud platforms (AWS/Azure/GCP), and CI/CD

Practical Advice for Tech Newcomers

Make the Most of These 14 Months

This preparation period is extremely valuable. Here's the recommended order of priorities:

Data Structures and Algorithms (DSA): This is the hard barrier for passing graduate written tests and technical interviews, and must be mastered solidly.
Project Portfolio: Build one or two projects that demonstrate platform/infrastructure thinking. Here I especially recommend incorporating Terraform into hands-on practice. Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp, whose core philosophy is to treat infrastructure configuration as software code, bringing it into version control, code review, and automated testing workflows. Unlike imperative tools such as Ansible, Terraform adopts a declarative paradigm: engineers describe the "desired state" rather than the "steps to take," and the tool is responsible for computing the difference between the current state and the target state (the "Plan" phase) and then executing minimal changes (the "Apply" phase). This idempotent design makes large-scale infrastructure management predictable and auditable. Notably, in 2023 HashiCorp changed Terraform's open-source license from MPL-2.0 to BSL-1.1, after which the community forked the OpenTofu project and joined the Linux Foundation. This open-source licensing dispute reflects the commercialization tensions in the IaC ecosystem and makes OpenTofu an important option for enterprises evaluating Terraform alternatives. Both Terraform and OpenTofu are important foundations of the "GitOps" workflow—i.e., treating infrastructure changes just like code changes, approved via pull requests and merged after validation by automated pipelines, achieving versioned governance of infrastructure. Building a complete environment within a cloud free tier using Terraform (VPC + EKS + monitoring and alerting), or building an end-to-end CI/CD pipeline with GitHub Actions, are both highly compelling portfolio projects, because such projects directly demonstrate a candidate's grasp of IaC concepts—which is precisely the core daily work of an ML platform engineer.
Python Fundamentals + Cloud Certifications: Entry-level AWS or Azure certifications can significantly boost resume competitiveness and offer excellent value for the effort. AWS Certified Cloud Practitioner or Azure Fundamentals (AZ-900) can serve as a starting point, followed by advancement to AWS Solutions Architect Associate or Azure Administrator (AZ-104). The latter is especially well recognized in the UK financial services industry, since Azure is the mainstream cloud platform choice for institutions like Barclays and HSBC.

Don't Over-Stress About the "Starting Role"

The first job at the start of your career won't determine your destination. The poster mentioned that he "loves backend SWE, and also loves DevOps, infrastructure, and ML"—this broad cross-domain interest is precisely one of the most important traits of an excellent platform engineer. Joining a company with real AI/ML operations first is far more meaningful than obsessing over whether the job title is precisely accurate.

On Expectations of "Stability and Salary"

The poster candidly hoped to "head toward the direction with the strongest stability and salary." From an industry-trend perspective, platform engineering and ML infrastructure are indeed salary high grounds, and as AI is deployed at scale, demand for related roles continues to grow. According to data from Levels.fyi and Glassdoor, the median salary for ML platform engineers in the UK is roughly between £65,000 and £100,000, and joining top AI labs like FAANG and DeepMind can reach even higher levels, usually with equity incentives attached. But one must be clear-eyed: the high returns of these roles are precisely because they demand both depth of experience and breadth of skills, with no shortcuts available.

Conclusion

This new graduate's overall plan is clear and pragmatic: use SWE as a springboard, transfer internally to platform engineering, and proactively build up Python and AI skills. The only mindset that needs adjusting is this—don't view a tech stack switch as a black-and-white choice, and don't fall into anxiety because your first role isn't perfect. In today's world, where demand for AI infrastructure continues to explode, composite talents who have both solid engineering fundamentals and a willingness to expand toward the platform direction have very bright prospects.