Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path →
The engineer on
the other side of the signature
Roughly a third of the postings using forward-deployed-family titles are pre-sales-shaped rather than delivery-shaped.1 That is not a lesser role — it is a different one, with a different rhythm, a different comp structure and a different set of skills. The mistake is not choosing it. The mistake is accepting it without knowing, then discovering in month two that your quarter is measured in deals rather than in deployments.
What the job is
The technical half of a sales team: you prove the product can do what the customer needs, in front of the customer, before anyone has signed anything — and you are the person the account executive brings in when the conversation turns real.
Titles vary — solutions engineer, sales engineer, solutions architect, technical account manager, forward deployed engineer at some companies. The reliable identifier is not the title. It is whether your work happens before or after the contract is signed, and whether any part of your compensation is tied to whether it gets signed.
| Stage | What you do | What is actually being tested |
|---|---|---|
| Qualification | Work out whether this customer’s problem is one the product can genuinely solve | Saying “no, this is not a fit” early. Rare, and the thing good SEs are valued for. |
| Discovery | Sessions with their technical people: systems, data, constraints, blockers | Whether you find the deal-blocker in week one or week eight. |
| Demo | Show the product solving their problem, in their vocabulary | A performance skill nobody taught you in an engineering career. |
| Proof of concept | Build a bounded thing on their data with a defined success criterion | Scoping. A POC without a written success criterion never ends. |
| Security review | The questionnaire, the CISO call, the architecture diagram | Whether the deal survives a team nobody warned you about. Practise it. |
| Handover | Give delivery an honest account of what was promised | Integrity. The alternative is a deployment team inheriting a demo hack as a commitment. |
The compensation structure changes the job
This is the difference people underestimate most, and it is entirely knowable before you accept.
Solutions engineering usually carries OTE — on-target earnings — splitting pay into base plus a variable component tied to team quota. A typical split is 70/30 or 80/20 base to variable. That structure is not a detail; it shapes which customers you spend time on, how the quarter feels, and what happens to your week in the last three weeks of it.
What OTE gives you
- Clear alignment: the thing you are measured on is the thing the company needs.
- Upside in a good year that a flat salary does not have.
- Unambiguous feedback — you know whether the quarter worked.
- A genuinely fast route into product, partnerships or management.
What it costs
- Your income partly depends on other people’s performance and on deals you do not control.
- Quarter-end urgency arrives whether or not the work is ready.
- Depth is hard: many customers, shallow engagements, little time to go deep on anything.
- Technical atrophy is faster here than in delivery roles, and it compounds quietly.
1. What is the base/variable split, and is the variable capped? 2. Is quota individual or team, and what was attainment last year across the team — not the top rep? 3. Is any of it paid on POC completion rather than on closed revenue? 4. How many active opportunities does an SE carry at once? A number above roughly eight means every engagement is shallow, and the job is closer to a demo function than an engineering one.
AI made the role harder in a specific way
Selling deterministic software means demonstrating features that behave the same way every time. Selling an AI system means demonstrating something probabilistic, on the customer’s messy data, to an audience that has read alarming headlines and has usually already been disappointed once. Roughly 95% of enterprise AI pilots reportedly produced no measurable P&L impact,17 and your prospect may well own one of them.
The demo can fail live, and that is a design problem
Rehearse the failure. A demo that hits a bad case and recovers gracefully — “here is what happens when it is unsure, and here is where that goes for review” — often sells better than a flawless one, because sophisticated buyers do not believe flawless.
“How accurate is it?” is the question you must answer well
The wrong answer is a number. The right answer establishes the ceiling: how often do two of your experts agree with each other on this task? Then propose measuring it together. That single move reframes the entire evaluation, and it is the method in evals for client work.
The security review is now an AI security review
Prompt injection, data residency, model-provider sub-processors, audit evidence for automated decisions. Their framework predates all of it, so you will be asked to explain the questions as well as answer them. Identity and the review itself are where deals actually stall.
The POC has to have a written end condition
“Success is 40 of the 60 weekly exceptions resolved without a human, measured on a frozen set of 200 cases, agreed by Bella” ends. “Let’s see how it goes” runs for two quarters and converts nothing.
Say what the product cannot do, unprompted, early. In a market where every vendor is claiming everything, being the one who names a limitation is disproportionately persuasive — and it is also the only version of the job that lets you sleep. It costs you a small number of deals that were never going to renew anyway.
Choosing between this and delivery
| AI Solutions Engineer | Forward Deployed Engineer | |
|---|---|---|
| Lives | Before the signature | After it |
| Measured on | Pipeline and closed revenue | Adoption, outcomes, and what shipped back into the product |
| Customers at once | Many, shallow | Few, deep |
| Code written | Demos, POCs, integrations that may be thrown away | Production systems someone depends on at 3am |
| Best when you | Like the room, the pitch, and variety | Like the build, the ownership, and going deep |
| Leads naturally to | Sales leadership, product marketing, partnerships, product | Staff engineering, product engineering, founding |
The full side-by-side is in FDE vs solutions engineer. What matters most is that both are legitimate, well-paid careers with different centres of gravity — and that the title on the posting frequently will not tell you which one you are being offered.
“What percentage of last quarter was spent pre-sale versus post-sale?” and “Is any part of my compensation tied to bookings?” Both answers are fine. Not knowing them before you accept is not. The commercial layer handbook covers what the answers imply for your scope, your deadlines and your week.
The loop is a demo and a discovery call
Solutions-engineering loops usually contain a live demo of the company’s own product, a mock discovery call, and a technical screen that is easier than an FDE loop’s. The demo is the round people underprepare.
The picture: six stages, then the signature
Worked example: what a 70/30 OTE actually pays
Take an illustrative $200K OTE, with the variable part paid in a straight line on team attainment and no accelerator. Real plans differ: some pay nothing below a floor, some pay extra above 100%. The method is the same.
| Team attainment | 70/30 ($140K + $60K) | 80/20 ($160K + $40K) | What it tells you |
|---|---|---|---|
| 50% | $140K + $30K = $170K | $160K + $20K = $180K | A bad year costs the 70/30 seller $30K |
| 80% | $140K + $48K = $188K | $160K + $32K = $192K | If 80% is the team’s normal, $188K is the real number, not $200K |
| 100% | $200K | $200K | The headline only holds when the team hits plan |
| 120%, uncapped | $140K + $72K = $212K | $160K + $48K = $208K | Upside exists only if the variable is uncapped |
| 120%, capped at 100% | $200K | $200K | A cap removes the upside and keeps the downside |
From 50% to 120% the 70/30 plan swings by $42K and the 80/20 plan by $28K. That is why the second question on the page (what the whole team attained last year) matters more than the OTE figure. Last year’s attainment is your expected pay. The OTE is what you get if everything goes to plan.
Common mistakes
- Demoing on your data, not theirs
A demo on a clean sample set proves the product handles clean samples. Ask in discovery for a handful of their real, messy records and build the demo around those. If the product breaks on them, it is better to find out in week one than in the POC.
- Meeting the security reviewer in week eight
Ask in the first discovery call who signs off on security, and request their questionnaire that day. A deal that “just needs security review” in its last month is a deal with a deadline nobody has agreed to.
- Letting the POC grow
Each “could it also…” added after kickoff quietly changes the end condition. Log every addition as phase two, in writing, and keep the frozen case set frozen. A POC with a moving goal can never pass.
- Saying yes to roadmap on the call
“We can do that” on a call ends up as a line in the contract. Say plainly which parts ship today and which are roadmap, and put the difference in the handover notes. Delivery has to build whatever you implied.
- Treating every opportunity as winnable
Time spent on a deal that was never a fit is taken from one that was. Qualify out early and in writing, with the reason. The account executive can then plan the quarter on deals that can actually close.
Where this shows up: the loop and the first quarter
- The mock discovery call
You are scored on your questions. Ask how the work is done today, who touches it, what a failure costs and who signs off. Do not pitch in the first ten minutes. Pitching early is the most common way candidates fail this round.
- The demo round
Pick one workflow in the interviewer’s vocabulary, show the path where it is unsure, and finish on time. Interviewers watch whether you check what the audience cares about before you show more features.
- The handover document
A useful one fits on a page. It says what was promised, what was shown but not built, the success criterion and its result, open security items, and who on the customer side owns what. Delivery teams judge solutions engineers by this page.
- Moving to delivery later
Discovery, scoping and the security review all carry over to an FDE role. What you have to rebuild is owning production: on-call, incidents and code that someone depends on at 3am. Say so in the interview, before they ask.
Check yourself
A prospect asks for a POC “to see what it can do”. What do you do before building anything?
Write the end condition and get it agreed. Name the metric, the frozen case set, the threshold and the person who signs it off, as in the page’s “40 of the 60 weekly exceptions, on 200 cases, agreed by Bella”. Without it the POC has no way to end, so it cannot convert.
An offer is $210K OTE at 70/30, and the team reached 60% of quota last year. What should you expect to earn?
Base $147K plus 60% of the $63K variable, which is $37.8K: about $184.8K, assuming a linear plan. That is $25.2K under the headline. Ask whether there is a floor below which nothing pays, because then 60% could mean more or less than that.
Your POC resolved 38 of 60 against a written goal of 40 of 60. Pass or fail?
Fail, by the criterion you agreed. Say so plainly and do not quietly move the goal. Then look at the 22 misses. If most belong to one fixable class, propose a short extension in writing, measured on the same frozen set. If they are spread out, the honest answer may be that it is not a fit yet.
The account executive wants you to demo next quarter’s feature as if it were live. What do you do?
Show it, but label it as roadmap, out loud. A demo implies a commitment. If the customer signs believing it exists, delivery inherits a promise they cannot keep, and the renewal pays for it. Naming the limit is also the credibility move the page describes.
Quick answers
What does an AI solutions engineer do?
They are the technical half of a sales team: qualifying whether a customer’s problem is genuinely a fit, running technical discovery, demonstrating the product on the customer’s own problem, building a bounded proof of concept with a written success criterion, surviving the security review, and handing over an honest account of what was promised. The work happens before the contract is signed rather than after it.
How is an AI solutions engineer different from a forward deployed engineer?
Which side of the signature they live on. A solutions engineer works pre-sale, carries many shallow engagements, is measured on pipeline and closed revenue, and often has compensation tied to quota. A forward deployed engineer works post-sale, carries few deep engagements, is measured on adoption and outcomes, and builds production systems someone depends on. Roughly a third of postings using FDE-family titles are actually the pre-sales shape.
How is a solutions engineer paid?
Usually on OTE — on-target earnings — splitting pay into base plus a variable component tied to quota, commonly at a 70/30 or 80/20 ratio. Before accepting, establish the split and whether the variable is capped, whether quota is individual or team, what attainment was across the whole team last year rather than for the top performer, whether anything is paid on proof-of-concept completion rather than closed revenue, and how many opportunities an SE carries at once.
How do you answer “how accurate is it?” in an AI sales conversation?
Not with a number. Establish the ceiling first: ask how often two of the customer’s own experts agree with each other on the same task, then propose measuring it together on a frozen set of their real cases. Promising an accuracy figure above the rate at which two humans agree guarantees a dispute later, and reframing the question this way is the single strongest move available in an AI pre-sales conversation.
How do I tell whether a job posting is pre-sales or delivery?
Ask two questions: what percentage of last quarter was spent pre-sale versus post-sale, and whether any part of the compensation is tied to bookings. Any mention of quota, OTE or a bookings-linked bonus means the role is pre-sales-shaped whatever the title says. Both answers are legitimate — the failure is accepting the role without knowing which one it is.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- Bloomberry — “I analyzed 1,000 forward deployed engineer jobs” (Nov 2025) — posting growth, builder/pre-sales/internal split. bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/
- First Round Review — “So you want to hire a forward deployed engineer” — the staff-engineer bar. review.firstround.com/so-you-want-to-hire-a-forward-deployed-engineer/
- PostHog — “WTF is a forward deployed engineer?” — first-party account of the role at a product company, including travel reality. posthog.com/blog/forward-deployed-engineer
- MIT NANDA “State of AI in Business” — 95% of pilots with no measurable P&L impact — report dated July 2025, available as a PDF; the figure here is cited via later press coverage (TechCrunch, 30 Jul 2026), which is what this link points to. techcrunch.com/2026/07/30/forward-deployed-engineers-are-the-ai-industrys-latest-talent-obsession/
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
- The Agent Evaluations HandbookA self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.Read →