# FDE at Handshake: read three job postings and prepare evidence for every line

> One posting states plainly that the role is not consulting, and that sentence decides what you need to bring into the interview room.

Original: https://fdetimes.net/en/guides/handshake-fde-job-postings-evidence/

You open Handshake AI Enterprise's Forward Deployed Engineer posting, and among the familiar lines sits a sentence that is easy to skim past: this is not an implementation or consulting role. If you want to move into FDE work, don't skim past it. It shows quite clearly what kind of engineer Handshake is looking for.

Handshake is worth studying because the company has posted FDE roles at several levels, each written in fairly specific terms, although the Staff posting has since closed. Its AI business grew out of the network of academic experts that leading AI labs badly need.

FDEs there therefore meet two kinds of customer: partner AI labs in the mid-level posting, and enterprise customers in the Enterprise AI posting.

Read these postings carefully and you have a clear brief to prepare against, whether or not you apply to Handshake.

The most effective way to study them is to treat each requirement as an interview question you will face, then prepare a piece of evidence from something that actually ran in order to answer it.

## Three postings, three rungs of the same job

The early mid-level FDE posting has engineers working with partner AI labs and internal teams, owning the work from idea to deployment.

According to the summary on the careers page, it asks for 2–4 years of experience, ReactJS/TypeScript, and a solid understanding of relational databases such as PostgreSQL along with data modelling. It also asks for rapid prototyping, testing and fixing based on direct feedback, and then writing playbooks so the next deployment can be repeated.

The Enterprise AI posting shifts the focus to agents. Engineers embed with enterprise customers in a small deployment team, design and run evals to measure agent performance, then improve step by step until the results genuinely move up.

The posting says plainly that it wants people who have shipped AI applications to production, not just fine-tuned models or built prototypes, and who understand agent architecture and how to measure and improve AI systematically.

The Staff posting, published on 9 February 2026 in San Francisco and now closed, adds two more layers. Candidates must have led ambiguous, high-stakes projects from zero with very little direction. Experience working directly with the customer's VP or C-level executives is listed as a plus.

## How does "not consulting" change the day-to-day work?

A consultant can write a proposal and leave another team to build it. An implementation engineer can install a product from an existing script.

That is why communication is not a side skill here. The mid-level posting explicitly requires strong communication and collaboration with both technical and non-technical people. When you sit inside a customer's team, a prototype demo that fails because you explained it badly costs as much as a bug.

Picture the first week at an enterprise customer: they want an agent that answers internal questions. A consultant would come back with an architecture document. The FDE Handshake describes would come back with a prototype, an eval suite showing what percentage of answers the agent gets right, and a plan to push that number up.

**Key point:** An FDE job posting is a brief: every line needs evidence from something that actually ran.

## Example: one project, four pieces of evidence

Suppose you once built a chatbot that answers questions about internal documents at your current company. On a CV, that line usually reads "Built a RAG chatbot using an LLM". It answers none of the questions in Handshake's postings, because it says nothing about whether the chatbot actually ran or how good it was.

Break the same project down requirement by requirement. The table below is one way to map it, and the figures are illustrative only, for you to replace with your own.

| Line in the posting | The real question | Evidence to prepare |
|---|---|---|
| Ship AI to production, not just prototypes | Are there real users? | Number of users, time in operation, one incident you handled |
| Design and run evals, iterate until results improve | What do you measure with? | A benchmark question set, pass rate before and after each change |
| PostgreSQL and data modelling | How is the data organised? | The schema you designed and why you chose it |
| Playbooks for repeatable deployment | Can someone else rebuild it? | A one-page document with a final check step |

The eval part deserves the most investment, because it turns a claim into a number. Imagine you write 40 questions with correct answers, run the chatbot and it passes 22. You change how the documents are chunked, run it again and get 27; you add a source-filtering step and reach 31.

That sequence of 22, 27, 31 is exactly the "hill-climb" the Enterprise posting refers to. The new CV line might read: "Shipped an internal chatbot to production; built a 40-question eval suite and raised the pass rate from 22/40 to 31/40 over two rounds of improvement." The interviewer will ask about those two rounds, and you already have the story.

## In what order should you prepare?

Start from the rung you are on. If you have 2–4 years of experience, the foundations of the mid-level posting come first: be able to write a clean React/TypeScript application connected to PostgreSQL, and explain why the schema has the shape it does.

Next come evals, the AI-specific skill the Enterprise posting puts in both the job description and the requirements. Take any agent or chatbot you have built, write a benchmark question set, run it, record the number, change one thing, run it again. Repeat a few rounds and you have a real measurement story instead of a claim that you "understand evals".

Then write a playbook. The mid-level posting treats documenting solutions for repeatable deployment as part of the job, not extra work. A good playbook sets out the prerequisites, the build steps, how to check that it is running correctly, and where things tend to break.

Finally, if you are aiming higher, gather the times you took on a problem nobody had defined and carried it through to a result. The Staff posting does not ask whether you are good at following a spec; it asks whether you have written the spec yourself amid ambiguity, and whom you have won over among the customer's leadership.

## The mistakes that sink an application

The most common mistake is presenting a prototype as if it were production. Handshake states clearly that it is not looking for people who have only fine-tuned or built trial versions, so a portfolio full of notebook demos gives the wrong answer to precisely the most important question.

The second mistake is introducing yourself as a consultant. Phrases such as "solution consulting" or "acting as a bridge" sound good, but they run straight into the line "not a consulting role". Tell your story with a builder's verbs: wrote, shipped, measured, fixed.

The third mistake is talking about evals without numbers. "Experience evaluating LLMs" proves nothing; a series of pass rates across rounds does. And don't neglect communication: have an example ready of explaining a technical decision to a non-technical person, because the posting puts it on a par with PostgreSQL.

## This week's exercise

Pick an AI project you have built, however small. Write 30 questions with answers, run it once, record the pass rate, change exactly one thing and run it again. By the end of the week you will have two numbers and a reason that explains the gap between them.

Every FDE candidate says they are careful and customer-focused. Those two measured numbers are what set you apart from them.

**Try this week:**

- Copy an FDE job posting into a spreadsheet, one requirement per row, and next to each fill in a specific piece of evidence from your own work, or write 'none yet'.
- Write a 30-question eval suite for an agent or chatbot you have built, run it once and record the pass rate.
- Write a one-page playbook so someone else can rebuild that project without having to ask you.

## Sources

- [Forward Deployed Engineer – Handshake (Notable Capital job board)](https://jobs.notablecap.com/companies/joinhandshake-com/jobs/67330436-forward-deployed-engineer)

- [Forward Deployed Engineer, Handshake AI Enterprise (EdTech Jobs)](https://edtechjobs.io/jobs/91220bf3-79bb-4ecc-b69d-75941b6f5eef-forward-deployed-engineer-handshake-ai-enterprise)

- [Staff Forward Deployed Engineer – Handshake (Simplify)](https://simplify.jobs/p/f638d723-abe7-4508-8669-9846a77f1792/Staff-Forward-Deployed-Engineer)

- [Inside Handshake: Garrett Lord (Lenny's Newsletter)](https://www.lennysnewsletter.com/p/inside-handshake-garrett-lord)