# FDE vs solutions engineer: the difference is who gets up at 2am > Both sit with customers and both write code, but only one still answers for the system long after the contract is signed. Original: https://fdetimes.net/en/guides/fde-vs-solutions-engineer/ In the same week you get two interview invitations. One ad is for a "Solutions Engineer", the other for a "Forward Deployed Engineer". Both mention customers, both ask for coding skills, both promise work that is "highly technical". You read them several times and still cannot tell whether these are two different jobs or one job with two names. Gergely Orosz of The Pragmatic Engineer noted in May 2026 that Google, OpenAI and Anthropic were hiring FDEs in very large numbers. He also argued that the latest version of the role looks like consulting. High demand brings a risk. You may pick the wrong job, then realise a year later that you are excellent at demos but have never been responsible for a system when it failed. This article gives you a simple test to separate the two roles, and shows how to apply it when reading job ads and writing your CV. ## The real line falls after ship day A comparison of the two roles on Scaler offers the most memorable test. If the system goes down at 2am, three months after deployment, the person who restores it is the FDE, not the SE. Every other difference flows from who owns the system. An SE works within the sales cycle, and the job is to prove the product *can* work for the customer. An FDE is sent straight into the customer's problem to make sure the product *actually* works in production. So an SE tends to prioritise showing the customer many features, while an FDE prioritises production-grade robustness. What each side ultimately delivers differs too. An analysis on Aced.io compares FDEs with solutions architects (SAs). SAs and SEs are closely related roles, both in pre-sales, so the comparison applies to both. According to Aced.io, an SA mainly builds proofs of concept, while the FDE is the one who has built and is maintaining the system. Demo code can be thrown away after the presentation; an FDE's code has to survive months of real data. **Key point:** To tell the two roles apart, ask who will fix the system when it breaks. ## Is timing a reliable signal? The second signal is timing. According to Aced.io, solutions architects join in the late stage of the sales process and stay until deployment. FDEs arrive once the contract is signed, to make the product deliver real value to the customer. Yet the timeline is not always clean. Palantir, the company that laid the foundations of the role, describes FDEs as engineers who sit right alongside the customer and own the project end to end, starting with the first conversation with the customer. In other words, at some companies the FDE is there before the contract is signed. So do not classify a job only by when you join. Two more durable signals are the org chart and the pay structure. FDEs belong to core engineering, while SEs usually sit in sales or pre-sales. FDEs typically carry no sales quota, whereas a solutions architect's package often includes a variable component influenced by sales. People work the way they are paid, so that line in an offer tells you more than the job title. ## One project, two people, three months Consider a hypothetical scenario. A logistics company wants to use an LLM to read supplier invoices and push the data into its accounting system. During the sale, the SE builds a demo that runs on a few dozen clean sample invoices. It extracts the right fields, has a polished interface and shows that the product can do a few other things as well. The question the SE has to answer is "can it be done?", and the answer convinces the buyer. The contract is signed. Now the FDE faces a very different question: "Will it run every day?" The FDE connects the pipeline to the real accounting system, and deals with skewed scans, missing fields and API rate limits. They also add logging, retries and an eval suite scored on the customer's real data rather than on the demo samples. Three months later a large supplier changes its invoice template and the pipeline starts failing en masse. The alert goes to the FDE, because they built the system and maintain it. Fixing the bug does not end the FDE's job. Anthropic's FDE job ad spells out a responsibility rarely seen in SE job descriptions: identifying recurring deployment patterns, codifying them and sharing what was learned with the Product and Engineering teams. In the scenario above, that is when the FDE writes up how to detect early that a supplier has changed its invoice template, so the next customer does not hit the same incident. ## Five questions to ask of a job ad Next time you open a job ad, read it the way an FDE reads a customer's technical documentation: look for real behaviour rather than trusting the name. Because SAs and SEs both sit in pre-sales, the five questions below work for either title. 1. Does the role report to engineering or to sales? 2. Do you join before or after the contract is signed, and do you stay after go-live? 3. Does the code you write reach production, or stop at a POC? 4. After shipping, who is on call when something breaks? This is the most important question. 5. Does pay include a variable component tied to sales? If the ad does not answer them, ask directly in the first interview. Travel is a signal too. Anthropic's FDE ad requires frequent travel, around 25-50% of the time, to build directly with customers on site. That figure shows the role demands long stretches alongside the customer, not a drop-in for a demo. ## Common misconceptions The most common misconception is that an FDE is just an SE who writes more code. The difference is not the amount of code. It is who is responsible for that code after ship day. The second is judging a job by its title. A role called FDE that reports to sales and carries a quota is, in substance, still pre-sales. A role with a different name that puts you on call for production is much closer to an FDE. The third sits in your CV. If you apply for FDE roles and every line of experience says "built demos" or "delivered POCs", recruiters will not see the signal they need. Write about the systems you took to production, how long you maintained them, the incidents you handled and a process you distilled and brought back to your team. The last is treating the FDE role as plain consulting. Orosz observes that the latest version of the role looks like consulting. But a consultant can walk away when the project ends, while FDEs at places like Anthropic have to carry lessons from customers back to the product team. Job titles can change with every hiring season. If you want to be an FDE, collect stories in which you were the person who got the call when the system broke. **Try this week:** - Open two job ads, one for a Solutions Engineer and one for a Forward Deployed Engineer, and find the answers to this article's five questions in each - Rewrite one line of your CV from 'built demos for customers' into a sentence that states what you took to production, how long you maintained it and which incident you handled - Pick a production incident you have handled and write half a page describing the reusable pattern you would send back to the product team ## Sources - [Forward Deployed Engineer vs Solutions Engineer: What's the Difference?](https://www.scaler.com/topics/forward-deployed-engineer-vs-solution-engineer/) - [Forward Deployed Engineer vs Solutions Architect: Key Differences (2026)](https://www.aced.io/blog/forward-deployed-engineer-vs-solutions-architect-key-differences-2026) - [Forward Deployed Software Engineer (Palantir job posting)](https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850) - [Forward Deployed Engineer (Anthropic, via Accel job board)](https://jobs.accel.com/companies/anthropic/jobs/93102649-forward-deployed-engineer) - [The Pulse: Forward deployed engineering heats up again](https://newsletter.pragmaticengineer.com/p/the-pulse-forward-deployed-engineering)