Forward Deployed Engineer: Practice the Job with Claude Code

Forward deployed engineer sounds like a new job title invented for AI. It is older than that, and the core of it has very little to do with models. The job is sitting next to someone whose work is messy, understanding it better than they can explain it, and shipping something that actually runs inside their day. You can practice every part of that this week with Claude Code and one willing person.

What the job really is

The title comes from Palantir, where engineers were sent to live inside customer teams instead of building from a distance. The idea spread because AI made the same problem visible everywhere. Companies can buy access to a strong model in an afternoon. Getting it to do useful work inside a finance team, a warehouse or a support queue takes months, and most of that time goes into understanding how the work really happens.

So an FDE is half engineer, half investigator. The demo usually works. The FDE is the person responsible for the distance between that demo and a Tuesday afternoon in the real team, with real data, real permissions and people who have done the task the same way for ten years.

If you want the long version, three pieces are worth your time: First Round's interviews with people who hire FDEs, The Pragmatic Engineer's breakdown of the role, and Nabeel Qureshi's Reflections on Palantir.

The honest part about getting in

This is an engineering role. Listings ask for real coding ability, very often Python, and experience shipping software people depend on. Nobody should tell you otherwise.

What makes it different is the other half. The people who do well are good at asking questions, noticing the workaround nobody mentions, and staying calm in a room full of people who are skeptical of the new tool. Plenty of strong engineers are weak at that. Plenty of designers, consultants and operations people are very good at it and just need the building side.

After 16 years in design, this is the part I recognize. Users rarely describe the real problem. They describe symptoms. The FDE skill is getting from the symptom to the actual process, then building for the process.

The practice loop

You do not need a job to practice the job. You need one person with an annoying process and a few evenings. A friend who runs a small shop, a coworker who spends every Monday on the same report, a parent who manages a club's bookings in a spreadsheet.

1. Interview. Spend 20 minutes watching them do the task, not hearing them describe it. Write down every copy and paste, every tab switch, every "then I check this other thing."
2. Pick one pain you can measure. Hours per week, errors per month, requests that slip. If you cannot measure it, pick something else.
3. Plan with Claude. Open Claude Code in an empty folder, press Shift+Tab until plan mode is on, and paste your notes.
4. Build the smallest version. A rough tool they use on Monday is worth more than a beautiful one you are still designing. Put it in their hands within a week.
5. Measure again. Ask them to use it for a week, then compare against the number from step two.
6. Write the readout. One page. Then do it again for someone else.

This is the prompt I would paste in plan mode after the interview:

I just shadowed someone doing a task they dislike. My raw notes are below.

1. Rewrite the process as numbered steps, the way it actually happens.
   Mark where time is lost and where mistakes creep in.
2. List anything in my notes that is ambiguous and ask me about it
   before you assume.
3. Propose the smallest tool we could ship in one week that removes
   the worst step. Say what data or accounts it needs, what stays
   manual on purpose, and how we would measure the result.
4. Do not write code yet.

NOTES:
[paste your notes]

Answer its questions, push back on anything too ambitious, and only then approve the plan. When it builds, ask it to prove the tool works with a test or a sample run before you show anyone. The official Claude Code best practices page explains why this matters: Claude stops when the work looks done, so give it a check it can run.

Things that make practice feel like the real job

• Use their data, not yours. Ask for a real export with sensitive fields removed. Fake data hides the edge cases that break things.
• Decide what stays human. A good deployment is clear about what the tool will never do on its own, like sending an email to a customer or deleting a record.
• Keep a decision log. A short text file of what you chose and why. Interviewers ask about tradeoffs far more than about syntax.
• Go back after two weeks. See if they still use it. If not, find out why. That conversation teaches more than the build.

The one page readout

This is the artifact you put on GitHub next to the code. A hiring manager should understand the whole story in two minutes.

# [Process]: deployment readout

## Who and what
Owner, team size, how often the process runs.

## Before
The real steps, including the workarounds.
Baseline number: [hours per week / errors per month].

## What I built
What it does in one paragraph. Stack.
What stays manual and why.

## After
Same metric, measured the same way, after [N] days of real use.
One sentence from the owner, in their words.

## Next
Two improvements, and what would need hardening
before a larger team could rely on it.

Three of these, each for a different person and a different kind of work, say more about you than any certificate.

Where to learn the technical half

Anthropic's free Claude Academy covers most of what the building side needs. I would go in this order:

• Claude Code 101 for the explore, plan, build workflow.
• Claude Code in Action for hooks, MCP and GitHub.
• Introduction to Model Context Protocol, because connecting a model to a company's systems is most of the job.
• Claude with the Anthropic API when you are ready to build without Claude Code in the middle.

For prompts that hold up with real users, Anthropic's courses repository on GitHub has an interactive prompt engineering tutorial and a course on evaluations.

Start by finding your first person. Send one message today asking someone which part of their week they would pay to never do again, and book 20 minutes to watch them do it. Everything else in this guide follows from that conversation.