Five roles that get mistaken for each other
Five job titles circulate around the same work, and they are not synonyms. A forward deployed engineer, an AI engineer, a solutions engineer, a software engineer and a solutions architect can all appear in the same hiring process at the same company for what looks like the same opening. What separates them is not technology and not seniority. It is five things: how much of the week is spent with the people who will use the thing, how deep the engineering goes, how well the role must understand the customer’s own trade, how much of the job is actually writing software, and whether the role is judged on what it delivered or on what the delivery changed. Those five axes sort the roles cleanly, and they sort job postings more reliably than the headings on them, which are not standardised across companies.
| FDE | AI engineer | Solutions engineer | Software engineer | Solutions architect | |
|---|---|---|---|---|---|
| Time with the customer | High | Low | High | Low | Medium |
| Technical depth | High | High | Medium | High | High |
| Business depth | High | Medium | High | Low | Medium |
| Hands on code | High | High | Medium | High | Low |
| Owns the outcome | High | Medium | Low | Medium | Low |
The four comparisons, and what each one is really about
FDE vs ai engineer
Both write code against models, so people assume the difference is seniority. It is not: it is who owns the evaluation set and where its cases came from.
FDE vs solutions engineer
Both live with customers, so the two get merged into "customer-facing engineering". One is measured before the signature and one after it.
FDE vs software engineer
The comparison people skip, and the one that decides whether the job will suit them. Product rewards generality, deployment rewards specificity.
FDE vs solutions architect
The two titles are used interchangeably more than any other pair here. The tell is who is still there when the integration fails.
Why the axes and not the tasks
The obvious way to compare jobs is by listing what each one does. It does not work here, because the task lists overlap almost completely. All five roles talk to customers, all five touch code, all five are involved in getting software into an organisation. A task list produces five paragraphs that say nearly the same thing, which is precisely the confusion these pages exist to clear up.
The axes work better because they capture the trade-offs rather than the activities. Two roles can both spend Tuesday writing an integration and still be different jobs, because one of them will be asked whether that integration generalises and the other will be asked whether the customer is using it. That question, repeated every week for a year, is what makes the roles diverge.
How to use the table when reading a posting
Take the posting and try to score it on the five rows yourself before looking at the title. Most postings score cleanly, and the ones that do not are informative in their own right.
A posting that scores high on customer time and low on hands-on code is a customer success or pre-sales role, whatever the heading says, and the engineering content will disappoint an engineer who took it expecting to build. A posting that scores high on everything is either a small company where one person genuinely does all of it, which can be an excellent role, or a job description written by someone hedging. Asking which of the two it is, directly, is a reasonable first-call question and the answer tends to be honest.
The row that people skip and should not is the last one. Whether a role is judged on delivery or on outcome determines what your performance review is about, and it is the difference between a year that felt productive and a year that counted. Roles judged on outcomes are harder and give you more leverage. Roles judged on delivery are more predictable and less exposed to things you cannot control, such as a customer reorganising halfway through.
The two mistakes people make with this table
The first is treating a column as a description of a person. The axes describe where a role sits on average across the market, not what any individual does. A forward deployed engineer at a company with a mature product may spend far less time on integration than the column suggests, because the product has absorbed the work. An AI engineer at a five-person company may spend half the week with customers. The table is a way of reading the market, not a way of reading your own week.
The second is reading a low score as a criticism. "Low" on hands-on code does not mean the role is less technical in any sense that matters to a career; it means the leverage of the role comes from somewhere other than the keyboard. Solutions architects score low on that row and are frequently the most technically experienced people on a project. A reader who interprets the shading as a ranking will draw exactly the wrong conclusion about which role to aim for.
What we do not compare, and why
We do not put salary in these tables. The public figures for these titles disagree with one another by a factor of four, because aggregators average postings that share a heading and nothing else. Publishing a single number per role would rank well and would mislead everybody, so we will publish compensation when we maintain our own posting-level data and can show how it was collected. Our methodology page states what that will require.
We also do not rank the roles. There is no best one. The comparison exists so that somebody choosing can choose on the axis that matters to them, which is usually not the axis that matters to the person giving them advice.
