Three job titles. Three completely different days. Pick the day, not the title.
Maya has two offers on the table. One says Software Engineer at a product company. The other says Forward Deployed Engineer at an AI platform company. A recruiter friend tells her a third option exists — Solutions Engineer — and that it is “basically the same as FDE, but with less travel.”
All three job descriptions mention Python, APIs, and customers. All three pay well. And yet Maya knows, correctly, that these are three different lives. She just cannot tell from the postings which life is hers.
This post fixes that. Not with title definitions — with days, trade-offs, and a decision you can test before you sign anything.
If you are still fuzzy on what an FDE even is, start with What Is a Forward Deployed Engineer? Role, Skills & How to Become One — this post assumes that baseline and goes one level deeper: how the FDE compares to its two closest neighbors.
1. The same problem, three different jobs
The fastest way to feel the difference is to watch all three roles handle one incident — the same incident, not three different ones. A logistics customer reports that their delivery dashboard shows impossible ETAs: some trucks apparently arriving before they left.
After investigation, the shared root cause turns out to be simple: the customer exports local timestamps without timezone information. Their dispatch system records “3:00 PM” with no zone attached, and the dashboard renders it as if it were UTC. One cause — and three different kinds of contribution:
| Role | What they contribute | What “done” looks like |
|---|---|---|
| Software Engineer | Improves timestamp handling in the product itself — parsing, storing with zone, and a safe backfill — so the next customer never hits this. | The fix ships in the next release, to everyone. |
| Solutions Engineer | Identifies a supported configuration or integration workaround within what the product already does, so this customer is unblocked now. | The dashboard is right today, using the product as it exists. |
| Forward Deployed Engineer | Works with the customer to normalize their historical and incoming data, validates the fix against real operations, and feeds the timestamp-handling gap back to the product team. | A working fix in the customer’s environment this week, plus a product improvement queued upstream. |
In real incidents these three often work the same ticket from different angles — the SWE fixing the product, the SE unblocking the customer, the FDE repairing the data and closing the loop. The comparison in this post is about primary responsibility, not exclusive territory. That distinction matters, because the boundaries blur constantly:
| Role | Primary responsibility |
|---|---|
| Software Engineer | Build and maintain software products or systems |
| Solutions Engineer | Help customers evaluate, adopt, and use a technical solution |
| Forward Deployed Engineer | Deliver engineering outcomes in a customer’s environment, often under customer-specific constraints |
Where the boundaries blur
- Solutions Engineers can write substantial integration code, prototypes, and custom demonstrations — “just configuration” undersells many SE roles.
- Software Engineers may work directly with customers, especially in infrastructure and enterprise software.
- FDEs may primarily configure and integrate an existing platform rather than build custom features — the mix depends heavily on the company and the customer.
- Travel varies considerably. Some FDE positions are mostly remote, while some Solutions Engineering roles involve frequent travel. Never assume — ask (see section 6).
2. A day in each life
Job descriptions rarely show the full workday. Days do. Here is the honest shape of a typical week in each role — tendencies, not rules. Individual teams vary, and if a role’s week looks nothing like this, that is a signal worth investigating, not a rounding error.
| Software Engineer | Solutions Engineer | Forward Deployed Engineer | |
|---|---|---|---|
| Calendar | Mostly your team’s rituals: standup, planning, review. Deep work blocks are often protected. | Customer calls dominate. Your calendar belongs to other people’s schedules. | Split between customer sessions and build time. Customer urgency can re-plan your day. |
| Code you write | Product code, reviewed, tested, shipped to everyone. | Varies — demos, sample integrations, configuration, the occasional script, and in some roles substantial prototypes. | Integration and glue code, prototypes, data fixes — shipped to one customer first, sometimes to the product later. Some FDE roles lean more toward configuration than code. |
| Who judges your work | Your team and your manager, against the roadmap. | The customer and the sales team, against a deal or a renewal. | The customer, against a working outcome — and your product team, against what you feed back. |
| Travel | Rare, usually for offsites. | Moderate on average — demos, onsite workshops, conferences — but some SE roles travel heavily. | Often the most of the three, but some FDE roles are mostly remote. Onsite presence is common, not guaranteed. |
| Ambiguity | Bounded — specs exist, even when they are bad. | Medium to high — customer needs are rarely fully specified, though the product bounds the solution space. | High — the problem is often unclear, the data is often wrong, and nobody has written the spec. |
| What compounds | Depth in a codebase and a technical domain. | Breadth across customers and deal patterns. | Judgment: diagnosing messy real-world systems fast, and translating between customers and product teams. |
One Tuesday, three engineering careers
Tables describe roles. Schedules let you imagine a life. Below is one illustrative Tuesday for each role, following the same timezone incident from section 1. These are illustrative schedules, not universal job descriptions — but if you read one and think “I want that Tuesday,” believe that reaction.
| Time | Software Engineer | Solutions Engineer | Forward Deployed Engineer |
|---|---|---|---|
| 9:00 AM | Team standup; picks up the timestamp-handling ticket | Discovery call with a prospect’s operations team | Join customer dispatch standup |
| 10:00 AM | Reproduces the issue; writes a failing test | Builds a demo using the prospect’s sample data | Investigate inconsistent timezone data |
| 1:00 PM | Implements timezone-aware parsing and a migration plan | Configures the import workaround for the timezone issue on a customer account | Implement and test normalization fix |
| 3:00 PM | Code review with a teammate; discusses backfill risk | Internal handoff: documents the workaround for support | — |
| 3:30 PM | — | — | Validate results with customer operations |
| 4:30 PM | Merges behind a feature flag; writes rollout notes | Prepares a proposal walkthrough for tomorrow’s deal review | — |
| 5:00 PM | — | — | Writes up the timestamp gap for the product team; plans tomorrow’s rollout check |
Notice the shape of each day, not just the tasks. The SWE’s day is built around depth and review. The SE’s day is built around other people’s schedules and decisions. The FDE’s day is built around one customer’s reality, from standup to validation to the write-up that turns a customer fix into a product lesson.
Myth: “FDE is just SWE with travel” or “SE with more code.” Reality: the travel and the code are side effects. The core difference is who owns the outcome. An SWE tends to own a piece of the product. An SE tends to own a customer’s success with the product. An FDE tends to own a customer’s outcome, and borrows whatever — code, data repair, persuasion — is needed to get there.
3. Skills: what transfers, what does not
Good news first: the technical floor is shared. Python, APIs, SQL, debugging, and the ability to read someone else’s system are table stakes in all three. If you are choosing between them, the decision is rarely “can I do the technical work.” It is “which non-technical work do I want to live inside.”
| Skill | SWE | SE | FDE |
|---|---|---|---|
| System design at scale | Core — your main craft. | Useful, rarely the job. | Useful, applied under customer constraints. |
| Customer communication | Occasional — demos, incident calls. | Core — you live on calls. | Core — you translate customer pain into engineering plans daily. |
| Diagnosing messy data | Sometimes, when a bug demands it. | Often, within the product’s data model. | Constantly — the data is the job. |
| Selling and persuasion | Rarely required. | Core — you are part of winning and keeping deals. | Real, but different — you persuade customers to change their process, not to buy. |
| Comfort with ambiguity | Moderate. | Medium to high. | High — it is the default condition. |
The transfer map matters because careers are long and titles are short. The paths between these roles stay open because they share a technical floor. An SWE moving to FDE brings depth and learns customer judgment. An SE moving to FDE brings customer fluency and deepens engineering. An FDE moving to SWE or product management carries judgment about what customers actually do with software. The move that is hardest is the one nobody warns you about: going from a role where someone else defines “done” to one where you must define it yourself. That is the real SWE → FDE adjustment, and it has little to do with coding ability.
4. Pay and career shape — honestly
Let us be careful here, because this is where career posts usually invent numbers. We are not going to quote salary figures: they vary so much by company, level, and location that any single number would mislead you more than it helps. Check current market data for your market before you decide. What is stable across markets is the shape of each path:
- SWE: the widest, most legible ladder. Levels, bands, and promotion criteria are usually written down. The path to senior and staff is the best-documented in tech.
- SE: base pay plus variable compensation tied to deals is common — which means your income moves with the sales cycle, and your best years can beat the other two paths while your worst years lag them.
- FDE: at companies that hire both FDEs and SWEs, FDE compensation is often benchmarked near SWE bands — but benchmarking varies, and the offer letter is the only number that counts. The ladder itself is younger and less standardized: titles, levels, and what “senior FDE” means vary more between companies.
The career-shape question to ask is not “which pays most this year.” It is “which kind of leverage do I want in five years”: depth in a system (SWE), breadth across customers and deals (SE), or judgment across messy real-world deployments (FDE). Money follows leverage, but leverage takes years to build, so pick the kind you will enjoy building.
Do not decide on vibes alone
- “I like talking to people” is not enough to pick SE or FDE — both involve hard conversations, not just friendly ones.
- “I like building things” is not enough to pick SWE — FDEs build constantly, just under customer deadlines instead of roadmap deadlines.
- “I want impact” fits all three job descriptions and therefore decides nothing. Ask instead: whose problem do I want to wake up thinking about — a product’s, a deal’s, or a customer’s operation?
5. The decision guide (not a test)
Career flowcharts that end in a single verdict overpromise. Travel should not disqualify you from FDE — some FDE roles are remote — and disliking ambiguity should not automatically send you to SE, where customer work can be deeply ambiguous too. So use this guide as a preference check, then verify the actual job before deciding.
First, what work do you want to own most?
That second step — verifying the actual job — is where most bad decisions get prevented. Two roles with the same title can differ more than two roles with different titles. Section 6 gives you the questions to ask.
6. The details that decide between two good offers
Once you have a preference, these are the details that separate a good offer from a good-sounding one. Ask them in interviews; the quality of the answer tells you as much as the answer itself.
Pre-sales vs. post-sales Solutions Engineering
“Solutions Engineer” covers at least two different jobs. Pre-sales SE focuses on winning deals: discovery, demos, evaluations, and technical proof. Post-sales SE (sometimes called implementation or customer engineering) focuses on onboarding, integration, and adoption after the deal closes. Some roles blend both. Before you accept an SE offer, ask which one the requisition actually is — a pre-sales role with a quota feels nothing like a post-sales role with an onboarding queue, and job postings often blur the two.
FDE coding expectations
FDE roles sit on a spectrum. At one end: production-grade development — services you own, reviewed and shipped like product code. At the other: integration and configuration — scripts, data pipelines, and product setup inside a customer’s environment. Neither end is better, but they are different jobs, and postings describe both as “build solutions.” Ask what the last few people in the role actually shipped, and how much of it was reviewed production code versus integration work.
Travel and work-life balance
Do not assume FDE travels most, and do not assume any role travels little. Ask for the actual number: nights away per month, typical trip length, and whether travel is planned or sprung on you by incidents. Ask the same about on-call: rotation frequency, what pages actually look like, and whether after-hours customer escalations are part of the job or an exception. A role’s lifestyle is defined by its worst month, not its average one.
Compensation, component by component
Compare offers component by component, not by headline number. Ask about base salary, equity, annual bonus, and — for SE roles — commission structure and what percentage of the team actually hits target. For FDE roles, ask whether on-call and travel carry additional compensation or are treated as part of the base. Two offers with the same headline can differ substantially once commission risk and equity vesting are accounted for. Again: no figures here, because the only figures that matter are the ones in your offer letters.
Career progression
Ask where people in the role go next — inside that company, not in general. Typical paths from these roles include senior engineering, architecture, product management, technical leadership, and customer engineering leadership. The telling question is not “is there a ladder” but “who climbed it here, and into what role.” A ladder nobody has climbed is a poster, not a path.
Interview preparation: what each role tends to test
| Role | Example interview tasks | What they reveal |
|---|---|---|
| Software Engineer | Coding exercises, system design, debugging a broken service | Depth, design judgment, and how you reason under constraints |
| Solutions Engineer | A demo or presentation, a discovery role-play, technical Q&A on the product | Communication, customer empathy, and how you handle questions you cannot answer |
| Forward Deployed Engineer | A take-home with messy data, debugging an unfamiliar system, a customer-scenario discussion | How you handle ambiguity, diagnose without a spec, and translate a customer problem into a plan |
These are tendencies, not guarantees — interview loops vary by company. But they double as a self-test: if one row’s tasks energize you and another’s drain you, that is data about fit, not just about preparation.
7. Test before you commit
A preference guide is a hypothesis. Here is how to test it cheaply, before you accept an offer or quit a job:
- Shadow for a day. Ask someone in the role if you can sit in on two customer calls. One call tells you more than ten blog posts, including this one.
- Read the evidence, not the pitch. A portfolio tells you what a role’s work actually looks like — see Portfolio #1: CityOps, Packaged and Portfolio #2: Project Acme (Fresh Build) for what FDE evidence looks like, and Present Your Evidence for how to show yours.
- Do the work sample. Take-home assignments reveal the role’s real day. The Take-Home Playbook walks through how to approach them — and if you hate the assignment, believe that feeling.
- Fix the resume first. If you are leaning FDE, The FDE Resume Teardown shows what hiring managers in this role actually look for — and it doubles as a checklist of whether the role fits you.
Later, not now
- Negotiation tactics for each role — first decide which role, then optimize the offer.
- Company-by-company comparisons — Palantir-style FDE is not the same job as startup-style FDE, and that deserves its own post once you have picked a lane.
8. The principle
Every lesson on this site carries one principle. This one’s is simple:
Pick the day-to-day, not the title. Titles are marketing. Days are your life. If you can describe a Tuesday in the role and want that Tuesday, you have your answer — whatever the offer letter calls it.
Field check
- Write down your last three work weeks. Which days energized you — deep-build days, customer-call days, or firefighting days? Your honest answer points at a column in the tables above.
- Take the preference guide in section 5 and answer it out loud, to another person. The question you hesitate on is the question to investigate, not to skip.
- Find one person in each role you are considering and ask them: “What does your worst week look like?” If their worst week still sounds acceptable, the role survives contact with reality.
- Before you apply anywhere, re-read the role’s job description and cross out every adjective. What is left — the verbs — is the job. Do you want those verbs?
Can I switch later if I pick wrong?
Yes — and this is the least scary part of the decision. SWE, SE, and FDE share enough of a technical floor that lateral moves between them are normal, especially early in a career. The cost of switching is not starting over; it is the months it takes to build the new role’s judgment. The one adjustment that surprises people is not technical: it is going from a role where someone else defines “done” to one where you define it yourself. Expect that learning curve whichever direction you move, and re-decide every couple of years with better information.
Is FDE just a stepping stone to something else?
It can be, but it does not have to be. Some FDEs move into product management, founding, or senior engineering — the judgment the role builds transfers well. Others stay for years, because they like owning customer outcomes and the variety that comes with it. Treat “stepping stone” as a story other people tell about the role, not a property of the role itself. The better question is whether the work itself — messy customers, unclear problems, visible outcomes — is work you want to keep doing, regardless of where it leads.
What about ML engineer, DevRel, or product engineer?
They are real neighbors too, and they rhyme with these three: ML engineer leans toward the SWE column with model depth, DevRel leans toward the SE column with community instead of deals, and product engineer sits between SWE and FDE. If one of those pulls you harder than any column here, follow that pull — the same test works for them as well: describe a Tuesday, shadow a day, and ask someone in the role what their worst week looks like. The framework in this post is about choosing work, not about these three titles specifically.
Comments
Post a Comment