Preparing your learning space...
25% through FDE Career Preparation tutorials
This tutorial walks the first phase of the FDE journey: understanding the role and the skill set it needs, then turning that into proof — a portfolio and a resume that get you noticed. By the end you'll know what an FDE is, what skills to build, what to build to demonstrate them, and how to present it all on paper.
An FDE is a hands-on engineer who works directly with customers, usually on-site or in their environment, to solve that customer's specific problems using the company's platform. You are part engineer, part consultant, and part product feedback loop. The job changes based on the customer: today you might be debugging a data pipeline, tomorrow you might be building a proof-of-concept feature, and next week you might be persuading a skeptical stakeholder with a clean demo.
You are the person who hears a customer say "we need X" and turns it into "here is how X works on our platform." More importantly, you feed what you learn back into the core product so future customers benefit from the fix too.
| Traditional Engineer | Forward Deployed Engineer | |
|---|---|---|
| Who the customer is | Inner team / product spec | A real external customer |
| Where you work | Your own codebase | The customer's environment |
| Definition of "done" | Code merged & shipped | Customer problem actually resolved |
| Primary skill | Deep technical precision | Speed to value + communication |
| Feedback loop | Product roadmap | Live, immediate |
The difference in a sentence: a traditional engineer optimizes the product; an FDE optimizes the outcome the customer gets from the product.
Most FDEs come from one of two places, but the trajectory looks similar:
Growth stages:
Because FDEs see customer pain directly, they also frequently graduate into product management, solutions architecture, and founding roles. The role is a strong career springboard, not a dead end.
This is the checklist interviewers and hiring managers actually evaluate. It groups into three buckets; you need to be genuinely strong in all three, not just the coding one.
Let's look at the minimum you need to be credible as a hands-on engineer in a customer environment.
SQL is non-negotiable. Most FDE work means moving or understanding data. Get comfortable with joins, aggregations, and window functions:
-- Typical FDE query: summarize a customer's usage per account
SELECT
account_id,
COUNT(*) AS events,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount,
date_trunc('month', created_at) AS month
FROM transactions
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY account_id, date_trunc('month', created_at)
ORDER BY month DESC;
This reads data the customer cares about — total events, total_amount, and a monthly breakdown — all in one pass. Notice the WHERE filter and the GROUP BY: you slice only the last 90 days and bucket by month so the customer can see trends that matter to their business.
API integration is the other daily skill. Most customer problems are "our system should talk to your system." You'll read an SDK, wire up an endpoint, and handle the webhook callback:
# Minimal webhook handler that ingests a customer event
import json
from flask import Flask, request
app = Flask(__name__)
@app.route("/webhook/events", methods=["POST"])
def ingest_event():
event = request.get_json()
# Both write the raw event and acknowledge quickly
print(json.dumps({"received": event["id"], "type": event["type"]}))
return "", 200
if __name__ == "__main__":
app.run(port=8080)
The key habit here is acknowledging the webhook immediately (return 200) before doing slow work, because providers retry on timeout. This is exactly the kind of gotcha an FDE learns on their second customer and applies everywhere after.
These are what separate an FDE from a remote contractor. You can code all day, but the job is won or lost on conversation.
Discovery is the craft of asking questions that reveal the underlying problem:
Bad: "What do you want us to build?" Good: "What happens today, step by step, when a customer places an order?" Good: "Where in that flow do things break or take too long?" Good: "Who feels the pain most — which team, and how does it hurt their day?" Good: "What would 'fixed' look like for you, and how would you know it worked?"
The first question hands you a wish list. The follow-ups force a concrete workflow, identify the true stakeholder, and give you measurable success criteria.
Demos are your pitch deck and your proof of work combined. A good demo tells a story the customer recognizes:
Never skip step 4. A demo that ends at "look, it works!" is forgettable. One that ends at "your team just saved 20 hours a week and stopped losing orders" is the reason deals renew.
The sharpest differentiator for an FDE is a domain. Two candidates with equal coding skill — but one has spent two years in healthcare EMRs — are not equal. The domain expert asks better questions, spots constraints early, and wins customer trust faster.
You don't need to start with a domain. Start with what you know and go deep:
Project scoping matters because customers will happily ask for everything. Learn to say no well: propose the smallest version that creates value, ship it, then expand.
Customer: "We want the entire reporting dashboard, all 12 widgets, by Friday." FDE scope: "I can deliver the 3 widgets your execs open daily by Friday, wired to live data. The rest can follow weekly — which 3 would remove the most pain first?"
You preserved the deadline, delivered real value, and kept control of what "done" meant. That is business maturity, and it is exactly what interviewing managers are looking for.
If you are already an engineer, the lowest-friction path is usually internal transfer: many companies (notably AI and infrastructure vendors) hire FDEs from their own engineering or SE ranks. Build a relationship with an account team, take a customer support rotation, and raise your hand for the next customer-focused role open.
If you are external, your leverage is proof of customer-facing technical work:
Either way, be ready for the unique interview format: fewer isolated algorithm puzzles and more "a customer has this messy problem — how do you approach it?" That shift is covered in depth in the interview tutorials that follow in this series.
A standard developer portfolio says "here's a thing I coded." An FDE portfolio says "here's a messy business problem a customer had, and here's how I turned it into a working outcome." That difference changes everything about how you present your work.
FDEs are hired on trust and judgment more than on framework mastery. Your portfolio is your best chance to show those qualities before you ever speak to a human. It converts your intangible skills — scoping, communication, speed-to-value — into something concrete an interviewer can scroll through.
| Quality | Something that shows it |
|---|---|
| You can do the work | Working code, deployed and runnable, not just a screenshot |
| You can scope a problem | Show the messy real-world problem before your tidy solution |
| You can explain a win | An outcome tied to a business metric, not just "it runs" |
If your portfolio only proves the first point, you're indistinguishable from a hundred other devs. All three together — build, scope, explain — are the FDE signal.
If you only have time for two, pick replica + integration. They map most directly to the job.
The showcase is the polished website recruiters glance at — clean design, your name, a headline, three project cards, a contact button. Its only job is to get a human to click into a project.
The technical portfolio is the substance behind each card — the repository, the README, the runnable code, the writeup. This is what actually convinces a senior interviewer that you can operate.
Build the showcase to point into the technical portfolio. The showcase is the cover; the technical portfolio is the book.
Every portfolio project should follow the same skeleton internally — a case study, because that's essentially what it is:
1. Problem (the "before") - The messy, real-world customer situation with friction and constraints. - Why it mattered to the business. 2. Approach (your scoping) - Constraints you discovered, tradeoffs you made, options you rejected and why. - This section is where FDE judgment shows. 3. Build (the solution) - Link to the repo, how to run it, what the key decisions were. 4. Outcome (the "after") - What changed, measured in a business metric. - What you'd do differently next time. Honest reflection.
Most candidates skip section 2 and 4, which is exactly why a well-rounded project stands out.
Put the most FDE-signal project first, and front-load the outcome story in each card's one-line description:
✓ "Reconciling 1,200 daily orders between a legacy POS and Stripe — automatic, no nightly manual export." ✗ "E-commerce order reconciliation project"
The first version states the problem, the scale, and the outcome in one breath. The second is a title only a developer would understand.
git clones and runs cleanly, with a README that says how. Screenshots and static HTML of a fake app damage credibility.An empty-but-pretty portfolio actively hurts you with strong interviewers. Substance over shine, every time.
The most common resume mistake is describing what you did instead of what changed because you did it.
✗ "Responsible for maintaining the reporting API and writing SQL queries." ✓ "Rebuilt the reporting API so a customer's finance team cut nightly report generation from 4 hours to 12 minutes, removing a daily manual export."
Both describe related work. The second shows a customer, a measured improvement, and a number. That's the whole game: every bullet should imply "and because of this, X improved."
If a bullet could be written by the person who merely watched the work, rewrite it. You must own the outcome.
Keep it to one page until you have 10+ years, then two is acceptable.
1. Name + contact (email, phone, location, GitHub/LinkedIn) 2. Summary (2–3 lines, no "objective" paragraph) 3. Technical Skills (compact, one or two lines) 4. Experience (reverse-chronological, strongest bullets first) 5. Projects (your portfolio) 6. Education + certifications (brief)
The summary earns the click; experience buys the interview; projects and skills support the story. Front-load the FDE-relevant material, because a recruiter spends roughly 30 seconds deciding whether to keep reading.
Lead with a line that names the role you want and the proof you bring.
✗ "Goal-oriented engineer with a passion for solving problems and collaborating with teams in a fast-paced environment." ✓ "Engineer who works shoulder-to-shoulder with customers to turn integration and data problems into shipped outcomes; strong in Python, SQL, and API work, with a finance-data focus."
The good version names the role (customer-facing engineering), the skills (Python, SQL, API), and a domain (finance) in one breath.
Use a formula: action verb + what you did + how + measured result.
[Verb] [what] [how/context] → [measured outcome]
| Letter | What it captures in a bullet |
|---|---|
| Situation | The customer problem or messy context |
| Task / stakes | What was at risk if it wasn't solved |
| Action | What you specifically did |
| Result | The measured outcome |
S/T: "Customer onboarding failed on 40% of signups and blocked a $80k renewal." A: "Diagnosed a webhook timeout, rebuilt retry logic, and added a fallback queue." R: "Cut onboarding failures to 2%, saving the account and unblocking renewal."
Not every bullet needs all four, but the best ones compress at least Action + Result, with Situation implied.
If all your past roles are pure internal engineering, add a subtle line connecting them to customer value — e.g., "feature reduced support tickets by 30% for the external-facing API."
Languages: Python, TypeScript/JavaScript, SQL, Go APIs & Data: REST, GraphQL, webhooks, pandas, Apache Airflow Cloud & Deploy: AWS (EC2, S3, Lambda), Docker, GitHub Actions Domain focus: Finance / payments data
Group them by category so a scanning eye can land fast. Drop anything you can't own in an interview; a skill you can't explain torpedoes credibility the moment it's probed.
Shipped a customer order-reconciliation pipeline that auto-matches 1,200 daily orders between a legacy POS and Stripe, removing a nightly manual export and cutting errors by 90%. Stood up a webhook ingestion service with idempotency + retry backoff, lifting customer event reliability from 91% to 99.7% during a peak sales week. Diagnosed a customer data-integrity issue, traced it to a timezone bug in their ETL, and delivered a one-week fix that unblocked their month-end close. Demoed a BI dashboard to the customer's CFO team; the live proof-of-value contributed to a $80k contract renewal. Wrote the external integration runbook that let the customer operate the system without vendor hand-holding, cutting support escalation tickets in half.
Before (generic):
Backend Engineer, Acme Corp • Responsible for building APIs and fixing bugs. • Maintained the reporting service and SQL queries. • Worked with product and QA teams.
After (FDE-signal):
Customer Engineer, Acme Corp • Rebuilt the reporting API so a customer's finance team cut nightly report generation from 4 hours to 12 minutes, ending a daily manual export. • Launched a webhook ingestion service with idempotency and retry backoff, lifting customer event reliability from 91% to 99.7%. • Diagnosed and fixed a timezone bug in a customer's ETL that had blocked their month-end close; delivered within one week. • Demoed an analytics dashboard to the customer's CFO team, contributing to an $80k renewal. • Authored the external integration runbook, halving support escalations.
Same person, entirely different impression. The "after" version would earn an interview at most account-based companies.
This tutorial walks the first phase of the FDE journey: understanding the role and the skill set it needs, then turning that into proof — a portfolio and a resume that get you noticed. By the end you'll know what an FDE is, what skills to build, what to build to demonstrate them, and how to present it all on paper.
An FDE is a hands-on engineer who works directly with customers, usually on-site or in their environment, to solve that customer's specific problems using the company's platform. You are part engineer, part consultant, and part product feedback loop. The job changes based on the customer: today you might be debugging a data pipeline, tomorrow you might be building a proof-of-concept feature, and next week you might be persuading a skeptical stakeholder with a clean demo.
You are the person who hears a customer say "we need X" and turns it into "here is how X works on our platform." More importantly, you feed what you learn back into the core product so future customers benefit from the fix too.
| Traditional Engineer | Forward Deployed Engineer | |
|---|---|---|
| Who the customer is | Inner team / product spec | A real external customer |
| Where you work | Your own codebase | The customer's environment |
| Definition of "done" | Code merged & shipped | Customer problem actually resolved |
| Primary skill | Deep technical precision | Speed to value + communication |
| Feedback loop | Product roadmap | Live, immediate |
The difference in a sentence: a traditional engineer optimizes the product; an FDE optimizes the outcome the customer gets from the product.
Most FDEs come from one of two places, but the trajectory looks similar:
Growth stages:
Because FDEs see customer pain directly, they also frequently graduate into product management, solutions architecture, and founding roles. The role is a strong career springboard, not a dead end.
This is the checklist interviewers and hiring managers actually evaluate. It groups into three buckets; you need to be genuinely strong in all three, not just the coding one.
Let's look at the minimum you need to be credible as a hands-on engineer in a customer environment.
SQL is non-negotiable. Most FDE work means moving or understanding data. Get comfortable with joins, aggregations, and window functions:
-- Typical FDE query: summarize a customer's usage per account
SELECT
account_id,
COUNT(*) AS events,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount,
date_trunc('month', created_at) AS month
FROM transactions
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY account_id, date_trunc('month', created_at)
ORDER BY month DESC;
This reads data the customer cares about — total events, total_amount, and a monthly breakdown — all in one pass. Notice the WHERE filter and the GROUP BY: you slice only the last 90 days and bucket by month so the customer can see trends that matter to their business.
API integration is the other daily skill. Most customer problems are "our system should talk to your system." You'll read an SDK, wire up an endpoint, and handle the webhook callback:
# Minimal webhook handler that ingests a customer event
import json
from flask import Flask, request
app = Flask(__name__)
@app.route("/webhook/events", methods=["POST"])
def ingest_event():
event = request.get_json()
# Both write the raw event and acknowledge quickly
print(json.dumps({"received": event["id"], "type": event["type"]}))
return "", 200
if __name__ == "__main__":
app.run(port=8080)
The key habit here is acknowledging the webhook immediately (return 200) before doing slow work, because providers retry on timeout. This is exactly the kind of gotcha an FDE learns on their second customer and applies everywhere after.
These are what separate an FDE from a remote contractor. You can code all day, but the job is won or lost on conversation.
Discovery is the craft of asking questions that reveal the underlying problem:
Bad: "What do you want us to build?" Good: "What happens today, step by step, when a customer places an order?" Good: "Where in that flow do things break or take too long?" Good: "Who feels the pain most — which team, and how does it hurt their day?" Good: "What would 'fixed' look like for you, and how would you know it worked?"
The first question hands you a wish list. The follow-ups force a concrete workflow, identify the true stakeholder, and give you measurable success criteria.
Demos are your pitch deck and your proof of work combined. A good demo tells a story the customer recognizes:
Never skip step 4. A demo that ends at "look, it works!" is forgettable. One that ends at "your team just saved 20 hours a week and stopped losing orders" is the reason deals renew.
The sharpest differentiator for an FDE is a domain. Two candidates with equal coding skill — but one has spent two years in healthcare EMRs — are not equal. The domain expert asks better questions, spots constraints early, and wins customer trust faster.
You don't need to start with a domain. Start with what you know and go deep:
Project scoping matters because customers will happily ask for everything. Learn to say no well: propose the smallest version that creates value, ship it, then expand.
Customer: "We want the entire reporting dashboard, all 12 widgets, by Friday." FDE scope: "I can deliver the 3 widgets your execs open daily by Friday, wired to live data. The rest can follow weekly — which 3 would remove the most pain first?"
You preserved the deadline, delivered real value, and kept control of what "done" meant. That is business maturity, and it is exactly what interviewing managers are looking for.
If you are already an engineer, the lowest-friction path is usually internal transfer: many companies (notably AI and infrastructure vendors) hire FDEs from their own engineering or SE ranks. Build a relationship with an account team, take a customer support rotation, and raise your hand for the next customer-focused role open.
If you are external, your leverage is proof of customer-facing technical work:
Either way, be ready for the unique interview format: fewer isolated algorithm puzzles and more "a customer has this messy problem — how do you approach it?" That shift is covered in depth in the interview tutorials that follow in this series.
A standard developer portfolio says "here's a thing I coded." An FDE portfolio says "here's a messy business problem a customer had, and here's how I turned it into a working outcome." That difference changes everything about how you present your work.
FDEs are hired on trust and judgment more than on framework mastery. Your portfolio is your best chance to show those qualities before you ever speak to a human. It converts your intangible skills — scoping, communication, speed-to-value — into something concrete an interviewer can scroll through.
| Quality | Something that shows it |
|---|---|
| You can do the work | Working code, deployed and runnable, not just a screenshot |
| You can scope a problem | Show the messy real-world problem before your tidy solution |
| You can explain a win | An outcome tied to a business metric, not just "it runs" |
If your portfolio only proves the first point, you're indistinguishable from a hundred other devs. All three together — build, scope, explain — are the FDE signal.
If you only have time for two, pick replica + integration. They map most directly to the job.
The showcase is the polished website recruiters glance at — clean design, your name, a headline, three project cards, a contact button. Its only job is to get a human to click into a project.
The technical portfolio is the substance behind each card — the repository, the README, the runnable code, the writeup. This is what actually convinces a senior interviewer that you can operate.
Build the showcase to point into the technical portfolio. The showcase is the cover; the technical portfolio is the book.
Every portfolio project should follow the same skeleton internally — a case study, because that's essentially what it is:
1. Problem (the "before") - The messy, real-world customer situation with friction and constraints. - Why it mattered to the business. 2. Approach (your scoping) - Constraints you discovered, tradeoffs you made, options you rejected and why. - This section is where FDE judgment shows. 3. Build (the solution) - Link to the repo, how to run it, what the key decisions were. 4. Outcome (the "after") - What changed, measured in a business metric. - What you'd do differently next time. Honest reflection.
Most candidates skip section 2 and 4, which is exactly why a well-rounded project stands out.
Put the most FDE-signal project first, and front-load the outcome story in each card's one-line description:
✓ "Reconciling 1,200 daily orders between a legacy POS and Stripe — automatic, no nightly manual export." ✗ "E-commerce order reconciliation project"
The first version states the problem, the scale, and the outcome in one breath. The second is a title only a developer would understand.
git clones and runs cleanly, with a README that says how. Screenshots and static HTML of a fake app damage credibility.An empty-but-pretty portfolio actively hurts you with strong interviewers. Substance over shine, every time.
The most common resume mistake is describing what you did instead of what changed because you did it.
✗ "Responsible for maintaining the reporting API and writing SQL queries." ✓ "Rebuilt the reporting API so a customer's finance team cut nightly report generation from 4 hours to 12 minutes, removing a daily manual export."
Both describe related work. The second shows a customer, a measured improvement, and a number. That's the whole game: every bullet should imply "and because of this, X improved."
If a bullet could be written by the person who merely watched the work, rewrite it. You must own the outcome.
Keep it to one page until you have 10+ years, then two is acceptable.
1. Name + contact (email, phone, location, GitHub/LinkedIn) 2. Summary (2–3 lines, no "objective" paragraph) 3. Technical Skills (compact, one or two lines) 4. Experience (reverse-chronological, strongest bullets first) 5. Projects (your portfolio) 6. Education + certifications (brief)
The summary earns the click; experience buys the interview; projects and skills support the story. Front-load the FDE-relevant material, because a recruiter spends roughly 30 seconds deciding whether to keep reading.
Lead with a line that names the role you want and the proof you bring.
✗ "Goal-oriented engineer with a passion for solving problems and collaborating with teams in a fast-paced environment." ✓ "Engineer who works shoulder-to-shoulder with customers to turn integration and data problems into shipped outcomes; strong in Python, SQL, and API work, with a finance-data focus."
The good version names the role (customer-facing engineering), the skills (Python, SQL, API), and a domain (finance) in one breath.
Use a formula: action verb + what you did + how + measured result.
[Verb] [what] [how/context] → [measured outcome]
| Letter | What it captures in a bullet |
|---|---|
| Situation | The customer problem or messy context |
| Task / stakes | What was at risk if it wasn't solved |
| Action | What you specifically did |
| Result | The measured outcome |
S/T: "Customer onboarding failed on 40% of signups and blocked a $80k renewal." A: "Diagnosed a webhook timeout, rebuilt retry logic, and added a fallback queue." R: "Cut onboarding failures to 2%, saving the account and unblocking renewal."
Not every bullet needs all four, but the best ones compress at least Action + Result, with Situation implied.
If all your past roles are pure internal engineering, add a subtle line connecting them to customer value — e.g., "feature reduced support tickets by 30% for the external-facing API."
Languages: Python, TypeScript/JavaScript, SQL, Go APIs & Data: REST, GraphQL, webhooks, pandas, Apache Airflow Cloud & Deploy: AWS (EC2, S3, Lambda), Docker, GitHub Actions Domain focus: Finance / payments data
Group them by category so a scanning eye can land fast. Drop anything you can't own in an interview; a skill you can't explain torpedoes credibility the moment it's probed.
Shipped a customer order-reconciliation pipeline that auto-matches 1,200 daily orders between a legacy POS and Stripe, removing a nightly manual export and cutting errors by 90%. Stood up a webhook ingestion service with idempotency + retry backoff, lifting customer event reliability from 91% to 99.7% during a peak sales week. Diagnosed a customer data-integrity issue, traced it to a timezone bug in their ETL, and delivered a one-week fix that unblocked their month-end close. Demoed a BI dashboard to the customer's CFO team; the live proof-of-value contributed to a $80k contract renewal. Wrote the external integration runbook that let the customer operate the system without vendor hand-holding, cutting support escalation tickets in half.
Before (generic):
Backend Engineer, Acme Corp • Responsible for building APIs and fixing bugs. • Maintained the reporting service and SQL queries. • Worked with product and QA teams.
After (FDE-signal):
Customer Engineer, Acme Corp • Rebuilt the reporting API so a customer's finance team cut nightly report generation from 4 hours to 12 minutes, ending a daily manual export. • Launched a webhook ingestion service with idempotency and retry backoff, lifting customer event reliability from 91% to 99.7%. • Diagnosed and fixed a timezone bug in a customer's ETL that had blocked their month-end close; delivered within one week. • Demoed an analytics dashboard to the customer's CFO team, contributing to an $80k renewal. • Authored the external integration runbook, halving support escalations.
Same person, entirely different impression. The "after" version would earn an interview at most account-based companies.
Save your progress and earn XP for completing tutorials.
4 questions · Pass with 70%+
1What most clearly separates a strong FDE resume bullet from a weak one?
2Which portfolio project best mirrors real FDE work?
3Why must an FDE portfolio's code be actually runnable?
4What is the most damaging resume mistake according to the tutorial?
Technology
Forward Deployed Engineer
Lesson group
FDE Career Preparation
Progress
25% complete