From SRE to FDE: you already do half the job description. The other half decides whether you get hired

An SRE reading Pragmatike’s advert for a Principal Forward Deployed Engineer on Built In Boston will find most of it familiar. The role calls for troubleshooting complex technical issues across the application and infrastructure layers, and for improving deployment processes, documentation, observability and reliability.

The next line is where many stop short: act as a technical adviser and trusted technical partner to customers. That line marks the real boundary between the two jobs, and it is often where hiring decisions are made.

The timing is good. The Pragmatic Engineer reports very strong demand for FDEs at Google, OpenAI and Anthropic. For people in DevOps and SRE, the route to FDE is shorter than it looks, provided you know which parts of your experience carry over and which you need to build from scratch.

The first half of the job description is an SRE’s normal week

Start with an inventory. Paraform describes the FDE as a hybrid of software engineering and direct customer deployment, with five core skill groups: a backend language, cloud infrastructure, data engineering, applied AI and customer communication. Tick the boxes you use every week.

Many SREs will tick cloud straight away and tick data halfway. Repeat the exercise against the foundation AITraining2U describes for FDEs in 2026: Python, APIs, data structures, Git, cloud and basic DevOps, plus enough ML to reason about models.

The word “basic” next to DevOps is where you already exceed the bar. The boxes most likely to stay empty are APIs, data structures and ML, and those make up your to-do list.

One thing missing from the inventory is worth more than any of the items on it: the on-call habit. Paraform finds that engineers who come from hackathons, early-stage startups or on-call rotations tend to adapt fastest, and the role does not require prior consulting experience.

The reason is simple. On-call forces you to diagnose an unfamiliar system with incomplete information while someone is waiting on you.

Why infrastructure skills only get you in the door

The inventory has a limit. Paraform says plainly that in its candidate placements, technical skill is the floor, not the ranking criterion. Your SRE strengths get you into the interview room, but the candidates next to you have cleared the same floor.

So what sets you apart? The second layer of skills in AITraining2U’s description points to the answer: defining the right problem, product thinking, communication and collaboration.

This is also the part SRE work rarely makes you practise, because your customers are usually internal colleagues and incidents arrive already defined by an alert.

A script is not production code

The first gap is on the technical side. Cloud Authority defines the FDE first as a software engineer working alongside the customer and writing production code in the customer’s environment. It treats a strong software engineering foundation as mandatory, and many job ads ask for three to five years or more of coding experience.

If most of the code you write is Terraform, pipeline YAML and operational scripts, ask yourself: have you ever written a service that other people call through an API, change alongside you and share responsibility for?

If the answer is no, expect questions on APIs, data structures and Git from the foundation layer, and on how you test and maintain a service when other people are changing it too.

The fastest fix is to take an internal tool you already run and rewrite it as a proper Python service, with a clear API, tests and code review.

Then add a small applied-AI component, such as a step that summarises logs with a language model, to practise the “enough ML to reason about models” the foundation layer requires.

Before fixing the incident, ask what the real problem is

Picture a customer complaining that their nightly report job keeps failing. The SRE reflex is to add an alert, add retries, build a dashboard and write a postmortem. All four are sensible, but none of them answers the question the customer actually needs answered.

An FDE asks first: who reads this report, at what time, and what decision do they make based on it?

Perhaps the department head only needs three numbers at 8am, and an on-demand query could replace the fragile job entirely.

The technical fix then becomes smaller, and the customer’s trust grows.

The good news is that the postmortem habit transfers. Tracing a root cause in a postmortem and asking “why does the customer need this?” rest on the same discipline of thought. The difference is that you have to ask those questions directly to the customer, in their language, before you touch the system.

Patch for one customer, or build for all of them?

The third gap is one of perspective. In a talk at AI Engineer, Kepler set the expectation that FDEs should generalise the solutions they build for individual customers into product capabilities.

Picture the opposite: ten customers, ten bespoke patches, each needing someone to remember how it works. Any SRE recognises that scenario at once, because it is toil.

Here SREs start with an advantage: the instinct to reduce toil. When the same manual task comes up a third time, an SRE wants to automate it. Applied to FDE work, when a third customer needs the same data connector, you should extract it into a shared module and document it so the product team can take it over.

The table below sets each line of the FDE job description against what an SRE already has, the remaining gap and the evidence to put on your CV.

FDE job requirement	What an SRE already has	Gap to close	Evidence for your CV
Troubleshooting across application and infrastructure layers	Diagnosis under pressure on call	Explaining causes to non-technical people	One incident told through its impact on users
Deployment, observability, reliability	Daily work	Almost none	Reliability improvements you produced directly, with numbers
Strong software engineering foundation	Scripts, IaC, automation	Services with APIs, tests, review	A public Python service repo
Enough ML to reason about models	Running systems that serve models, if you have done so	Understanding model behaviour and limits	A small deployed AI feature
Technical adviser to customers	Supporting internal teams	Defining the right problem, product thinking	A time you changed a solution’s direction by asking the right question
Generalising solutions into product	The instinct to reduce toil	Designing for many customers to share	An internal tool used by several teams

Your CV should speak the FDE’s language

When filtering job ads, look for lines such as “troubleshoot across application and infrastructure layers” or “improve observability and reliability”. Those match what you already do every week, so those are the ads to apply to first.

Then rewrite your CV against SRE habit. Instead of “reduced MTTR”, say who was affected, how you diagnosed the problem across layers and what users got as a result. Every bullet should show both the technical floor and the part that sets you apart.

SREs are used to taking responsibility for other people’s systems at 3am. To become an FDE, you keep that sense of ownership; the difference is that it now extends to the customer’s problem rather than stopping at system uptime.