FDE at Notion: read the job posting line by line, then build one project that proves it

You open Notion’s Forward Deployed Engineer posting and find one long paragraph: agents, integrations, automation, data pipelines, migration, feedback loops. On a quick read it sounds like a “do everything” role. Read it carefully and it turns out to be three separate jobs, each needing a different kind of evidence.

Separating those three jobs matters more than it might seem. A list of technologies on a CV struggles to answer all three. What belongs in your application is evidence that you have taken over a messy system and put it into production without losing data.

Three jobs under one title

Notion describes itself as an AI workspace where teams and agents think together. The FDE is the person who takes that product into a customer’s real systems.

The posting for the DACH market describes the FDE, within the Go-To-Market organisation, as someone who leads complex technical customer projects from start to finish. The AMER posting places the role in the Services team and stresses hands-on technical implementation.

The first job is building. The posting asks you to design, build and operate custom agents, integrations, automations and data pipelines that connect Notion to customers’ systems. The word “operate” is the detail to notice: writing something and handing it over is not enough; you are also responsible for it while it runs.

The second job is large-scale migration, covering discovery, scoping and data modelling. The third is the one most easily overlooked in preparation: designing and running a feedback loop with Product, CX and Engineering, turning the difficulties met in real deployments into work those teams can act on.

Where is the real bar?

The required section is fairly practical. You need proficiency in at least one of Java, JavaScript, Node.js, SQL or Python. Hands-on experience with APIs and data integration recurs across the regional postings. Debugging is spelled out: finding the root cause across several layers, from code to APIs to permissions.

On seniority, the AMER posting asks for 5+ years in a customer-facing, forward deployed or comparable hands-on technical role; the DACH posting asks for 4+ years.

Some regions add language requirements: the posting for Korea calls for native-level Korean and working-level English, including spoken communication.

Notion is also hiring an FDE Manager in EMEA to coach a team of FDEs, with a requirement of 8+ years.

The “nice-to-have” section shows where the company is heading. The AMER posting lists ETL/ELT, data transformation, schema mapping and validation scripts, along with MCP, LLM applications, prompt engineering and RAG. The Korea posting adds experience deploying autonomous AI agents in coding workflows or complex business processes.

Line in the job posting	Evidence to have in your application
Migration: discovery, scoping, data modelling	A source-to-target schema mapping document, noting fields that are lost or must be transformed
Validation scripts, schema mapping	A script that compares source and target, with an error report by type
Debugging across code, APIs, permissions	An incident write-up: symptoms, hypotheses ruled out, root cause
Feedback loop with Product, CX, Engineering	A product proposal written from real errors hit during a migration
AI agents, MCP, RAG	A small agent that reads the migrated data and answers questions, with a log of when it got things wrong

Example: a small migration, verified record by record

Imagine you set yourself a problem: a 30-person team manages documents and tasks in an old wiki plus a spreadsheet, and needs to move to a new workspace. This is a scaled-down version of exactly the kind of work in the posting, and you can do it on your own machine.

Discovery means listing the sources: the wiki has pages, subpages, creators and edit dates; the spreadsheet has a status column with inconsistent hand-typed values such as “Done”, “done” and the Vietnamese “Xong”. Data modelling means deciding the target: status becomes a select field with three fixed values, parent-child relationships are preserved, and creators are mapped by email.

The part that earns credit is verification. Suppose the source has 1,200 records. The migration script reports “success”, but that is only the script’s own word. You need an independent script that compares both ends:

import csv
from collections import Counter

ALLOWED_STATUS = {"Not started", "In progress", "Done"}

def load(path, key="source_id"):
    with open(path, newline="", encoding="utf-8") as f:
        return {row[key]: row for row in csv.DictReader(f)}

def validate(source_path, target_path):
    src, dst = load(source_path), load(target_path)
    errors = Counter()
    for sid, row in src.items():
        t = dst.get(sid)
        if t is None:
            errors["missing_in_target"] += 1
            continue
        if t["status"] not in ALLOWED_STATUS:
            errors["unmapped_status"] += 1
        if row["parent_id"] and t["parent_id"] != row["parent_id"]:
            errors["broken_hierarchy"] += 1
        if not t["owner_email"]:
            errors["owner_not_mapped"] += 1
    extra = len(set(dst) - set(src))
    print(f"source={len(src)} target={len(dst)} extra={extra}")
    for kind, n in errors.most_common():
        print(f"{kind}: {n}")

validate("source_export.csv", "target_export.csv")

Suppose the result is 1,200 in the source, 1,188 in the target, 12 missing records and 25 unmapped statuses. Those numbers are only the beginning.

Debugging the 12 missing records, you might find they sit in a folder the integration token has no permission to read: exactly the kind of “permissions” failure the posting mentions. The 25 status errors come from hand-typed values the mapping table did not account for.

Then you write a short note for “the product team”: if the import tool warned early about pages without access, the person doing the deployment would not have to count them by hand. That is a feedback loop in miniature.

In what order should you do it?

Start by choosing a real data source, however small: an issue tracker, a personal wiki, a project-management spreadsheet. Write the mapping document before writing code, because that is the discovery, scoping and data modelling the posting names. Only then write the migration script in your strongest language; Python and Node.js are both on the list.

Next come the validation script and an error report by type, with a root cause for each type. If you want to touch the nice-to-have section, add a small agent that answers questions on the migrated data, and record the questions it gets wrong and why. Finally, write a one-page product-feedback note.

On your CV, each line should have four parts: the source system, the target system, the volume, and how you verified the result. “Migrated 1,200 records from a wiki to a new workspace; a validation script found and resolved 37 errors of 2 types” says far more than “Proficient in Python, REST APIs”.

The mistakes that sink applications

The first mistake to avoid is proving only the building part. A polished agent demo with no migration or data verification covers just a third of the role. The second is telling debugging stories as luck (“eventually it worked”) instead of setting out the hypotheses ruled out at each layer: code, API, permissions.

The third is ignoring the customer-facing seniority requirement. If you are a pure backend software engineer, look back for times you worked directly with internal users or integration partners, and write them up clearly.

The last is not reading the posting for the specific region you are applying to. The Korea posting, for example, states plainly that it requires native-level Korean and working English.

How many lines does your application cover?

This week’s self-check: copy the five lines from the left-hand column of the table above onto a page. Next to each, paste a link or name a specific project an interviewer could open right away: a mapping document, a validation script, an incident write-up, a product proposal, a small agent.

Any empty line is the first thing to work on. If several are empty, pick the validation script, because a good comparison script leaves you with ready material for the incident write-up and the product proposal.

A 1,200-record migration on a laptop is not the same as an enterprise project. But it shows an interviewer that you think like someone who will be held responsible when a customer’s data goes missing, and that is the real question behind every line of this posting.