Forward Deployed Engineer hiring kit

Every step to hire the engineer who makes your product work on a customer's own data and systems, and leaves it running safely after they go.

About this kit — the 5Ws

A forward deployed engineer works inside a customer's world rather than your codebase. They take a general product and turn it into a working deployment on that customer's data, systems and rules, own the result on site, and carry what they learn back to the product team. The craft is scoping a problem the customer can only describe vaguely, wiring into systems nobody documented, debugging where you can't see everything, and telling a non-engineer plainly what will and won't work. When the product includes AI, it also means proving the model behaves on the customer's real data before anyone promises it will.

Calibrated for:: Calibrated for mid-level to senior engineers who have shipped production software and have already worked directly with customers or internal users; it is not set up for a first engineering job.
Timeline:: Set an approval-to-offer target at intake, allowing for panel availability, candidate adjustments, references and any lawful checks.

Who: Hiring managers, heads of deployment or customer engineering, and recruiters staffing the engineers who go out to customers after a deal is signed and make the product work in their environment.
What: This kit sets out the evidence a strong forward deployed engineer produces, a work sample built on a messy customer integration, interview rounds on scoping, field debugging and customer judgement, and a way to time how the search itself went.
When: Pick it up when signed customers are waiting on deployments your core engineers can't staff, and carry it from the business case through to logging how long each step of the search took.
Where: Technology companies whose product has to be fitted to each customer's own data and systems before it delivers value.
Why: A CV can show impressive employers and a long list of integrations. It can't show whether someone will tell a customer the truth about a deadline, or ship the smallest thing that works instead of the most elegant one. The work sample and structured questions put that judgement on the table, and scoring every candidate the same way keeps the comparison about the job.

The competency model · 7

Use these competencies to compare job-related evidence. Review any apparent gap in a must-have before deciding.

Scoping ambiguous customer problemsMust-have · 20
Turns a complaint like 'the numbers look wrong' into a reproducible problem with a written definition of done, and asks the two or three questions that change the plan before writing code.
Integration with unfamiliar systemsMust-have · 20
Gets productive quickly in a stack they didn't choose: reads undocumented interfaces, handles dirty or inconsistent data, and builds the smallest working path from the customer's systems to the product.
Debugging in environments you don't controlMust-have · 15
Narrows a failure down across the seam between the product and the customer's systems with limited access and logs, forming and testing one hypothesis at a time instead of changing several things at once.
Customer communication and expectation settingMust-have · 15
Explains trade-offs to operations, finance or compliance staff without jargon, says 'not yet' or 'no' with a reason and an alternative, and keeps written updates that separate what is known from what is still a guess.
Field-to-product judgementCan learn · 10
Can say why a given fix belongs in a one-off customer script, a configuration option or the core product, and writes field feedback the product team can act on rather than a list of complaints.
Safe, maintainable hand-overCan learn · 10
Leaves a deployment the customer's own team can run: credentials scoped and rotated, failures that surface instead of disappearing, and a hand-over note a stranger could follow.
Evaluating AI on the customer's real dataCan learn · 10
Before go-live, checks how the model performs on a labelled sample of the customer's own records rather than the demo set, and reports the result in terms the customer can plan around.

What's required and what's optional

Your hiring journey for Forward Deployed Engineer. Select a stage to jump to it.

Required for every hire
Optional — use when it adds evidence
AI boost — a big drafting win
Colour = phase

Phase 1
Plan
1. 01Plan the roleRequired
2. 02Agree successRequiredAI boost
Phase 2
Attract
1. 03Write the jobRequiredAI boost
2. 04Find candidatesOptionalAI boost
Phase 3
Select
Phase 4
Decide
Phase 5
Onboard & learn
1. 12Help them settle inRequired
2. 13Measure time to hireRequiredAI boost

AI drafts, people decide: Use AI to draft, rewrite and summarise your own material — never to rank, score, screen out or decide on candidates, and never with a candidate's personal data.

Plan

Attract

Select

Decide

Onboard & learn

Solid = required · dashed = optional · arrow keys move between steps

Stage 1 of 13Required

0 of 3 done

Plan the role

Workforce planning and requisition approval

Who runs it: Hiring manager + finance / HR business partner
Done when: An approved requisition with a written business case, budget and a named decision-maker.

Key tool

Answer these before the role is approved

1Which signed customers are waiting on a deployment right now, and what is holding each one up?
2Who does this work today, and what are they not doing because of it?
3How many deployments a year do you expect, and how alike are they?

AI as an advantage4D framework

Delegate: Hand AI the first draft of the business case and the build / borrow / buy comparison. The decision, the budget and the sign-off stay with people.

Show the prompt and the checks

Describe: You are helping a hiring manager write a business case for a Forward Deployed Engineer role. Context: I will paste the problem the hire solves, the work it involves, the capacity we already have and the time we have. Produce: (1) a one-sentence problem statement in business terms; (2) a build / borrow / buy comparison with the strongest argument for each; (3) the questions a finance partner would ask; and (4) a short recommendation with the evidence it rests on. Use British English and plain language. Do not invent figures — leave [brackets] where I need to supply numbers. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check every number and claim against your own notes and strike anything the draft assumed. Make sure 'buy' is argued from ongoing work, not from a job title.
Diligence: The hiring manager owns the final case and the budget request. No candidate information belongs here; AI drafts the case, people decide whether to open the role.

Don't miss: Creating the role to rescue one troubled account. If the work ends when that customer goes live, a contractor or a temporary secondment may fit better than a permanent hire.

Framework

Build · Borrow · Buy

Before opening a role, decide whether to build the capability in your current team, borrow it (contractor, agency, partner), or buy it (a permanent hire).

Write the problem the hire solves in one sentence, in business terms — not the job title.
Test Build: could an existing person grow into this within the time you have?
Test Borrow: is the need time-boxed, or does it end once a system is shipped?
Choose Buy only when the work is ongoing, core to the product and nobody inside can absorb it.
Record the decision, the budget and the one person who signs off the final hire.

Why it works: Writing the build, borrow or buy decision down exposes a vague or temporary need before it becomes a permanent requisition — and gives every later stage an anchor to check against.

• Name the person who signs off the hire, usually whoever is answerable for customers reaching go-live.

Is this a dedicated role?

Decide whether the work is sustained and substantial enough for a dedicated owner by writing down the workload, the risk, the capacity you already have and the outcomes you expect.

Answer these before the role is approved

1.Which signed customers are waiting on a deployment right now, and what is holding each one up?
Listen for: Named accounts and a specific blocker: integration work nobody has time for, data that needs cleaning, a customer team that needs someone in the room.
Red flag: 'Customers would be happier with more hands-on help' with no account or blocker named.
2.Who does this work today, and what are they not doing because of it?
Listen for: Core engineers pulled off the roadmap, support staff stretched past their remit, or deployments simply waiting.
3.How many deployments a year do you expect, and how alike are they?
Listen for: Enough similar deployments to keep someone busy and to learn from, or an honest admission that each one is different, which raises the bar on judgement.
4.Could a product engineer who already knows the system spend part of their time with customers instead?
Listen for: A named person and a realistic split, or a clear reason the travel and customer load doesn't fit an existing job.
5.What does a delayed go-live cost you?
Listen for: Something concrete: revenue recognised later, a renewal at risk, a reference customer you can't yet point to.

Build, borrow or buy?

Build: rotate a product engineer into customer deployments for a defined period, with a mentor who has done the work and a clear return date.
Borrow: use an implementation partner or contractor for a well-understood deployment, with a written hand-over so the lessons reach your product team.
Buy: hire a permanent forward deployed engineer once deployments keep arriving and each needs someone who can code and run the customer relationship.

Watch out for

Blurring this role with presales. A common pattern is that a solutions engineer helps a prospect decide to buy, while a forward deployed engineer arrives after the contract and is judged on whether the deployment works; titles and ownership vary between companies, so write down which you mean.

Stage 2 of 13Required

0 of 2 done

Agree success

Intake meeting and competency model

Who runs it: Recruiter + hiring manager
Done when: A signed-off competency model: 5–7 competencies, each marked must-have or trainable, with weights.

Key tool

Ask the hiring manager

1Which of the systems or areas this person will own worries you most, and why?
2When something there went wrong recently, how did you find out?
3In 12 months, what will be shipped, fixed or running for you to call this hire a success? Agree two or three measurable outcomes.
4Who will they work with most closely?
5What could a strong candidate learn in their first three months? Those capabilities are 'trainable' — never use them to filter applications.

AI as an advantageAI boost4D framework

Delegate: Hand AI your raw intake notes to turn into a draft competency model. Choosing the must-haves and the weights stays with the hiring manager and recruiter.

Show the prompt and the checks

Describe: You are helping a recruiter and a hiring manager build a competency model for a Forward Deployed Engineer role. Context: I will paste the notes from our intake meeting, including the 12-month outcomes and what the hiring manager worries about most. Produce a table of 5–7 observable competencies with, for each: a one-line definition; whether it is a must-have or trainable, with the reason; what evidence of it looks like in real work; and a suggested weight so the weights total 100. Use British English and inclusive wording, avoid years-of-experience or named employers as evidence, and keep every competency job-related. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that each competency is observable and job-related, that nothing describes a type of person rather than the work, and that trainable items haven't been marked must-have.
Diligence: The hiring manager signs off the final model and weights before anyone meets a candidate. No candidate data goes into the prompt; AI drafts, people decide.

Don't miss: Requiring prior experience of your exact customer stack. The customers will change; the habit of learning an unfamiliar system quickly is what carries over.

Framework

Competency model (must-have vs trainable)

A short list of the observable capabilities the job needs, split into what the hire must bring on day one and what you will teach.

Start from the 12-month outcomes, then ask which capabilities produce them.
Keep 5–7 competencies. With more, interviewers struggle to score each one separately.
Mark each must-have or trainable. Only must-haves can count against a candidate.
Give each a weight so they sum to 100, agreed before anyone meets a candidate.
Write what evidence of each looks like, so interviewers know what they are listening for.

Why it works: Agreeing the criteria before meeting candidates stops the bar moving from one candidate to the next, and makes it harder for 'I'll know it when I see it' to decide the hire.

Core intake questions (ask for every role)

Book 45 minutes with the hiring manager before anything is advertised, and write the answers down.
Which of the systems or areas this person will own worries you most, and why?
When something there went wrong recently, how did you find out?
In 12 months, what will be shipped, fixed or running for you to call this hire a success? Agree two or three measurable outcomes.
Who will they work with most closely?
What could a strong candidate learn in their first three months? Those capabilities are 'trainable' — never use them to filter applications.
Who is on the interview panel, and is their time held for the next four to six weeks?

Questions specific to this role

1.Roughly how is the week split between writing code, talking to customers and travelling?
Listen for: A realistic split. It sets the competency weights and tells you whether you are hiring an engineer who talks to customers or a consultant who codes.
2.What does the hand-over look like when a deployment ends, and who looks after it afterwards?
Listen for: A named owner after go-live, whether the customer's team or your support function. If nobody owns it, the hire will be pulled back into old deployments indefinitely.
3.When a customer needs something the product doesn't do, who decides whether it becomes a product change?
Listen for: A route from the field to the product roadmap, with a named person. Without one, field feedback has nowhere to go.
4.For AI features, how do you check today that the model works on a customer's own data before go-live?
Listen for: Whether a check exists or the new hire will build it; that decides the weight on the AI evaluation competency.

What success looks like in 12 months

Several customer deployments live and in use, each with a written hand-over the customer's team can follow.
A shorter path from signed contract to go-live on the next comparable deployment, measured against the last one.
At least one recurring customer workaround turned into a product change, with the field evidence that justified it.
Customers going live on an AI feature have seen its results on their own records before launch, not only on demo data.

Watch out for

Treating 'good with customers' as a personality trait to judge in a chat instead of a competency with evidence and a score.

Stage 3 of 13Required

0 of 3 done

Write the job

Job description and pay band

Who runs it: Hiring manager (content) + recruiter (publishing)
Done when: A published job description that states outcomes, the must-haves, how AI tools are used and the pay information the law requires.

Key tool

Forward Deployed Engineer

We're looking for a forward deployed engineer to take [product] into customers' own environments and make it work there. You'll scope what each customer actually needs, connect the product to their systems and data, see the deployment through to go-live, and bring what you learn back to our product team. You'll work with customer operations and IT teams, and with our [product/engineering] group.

What you'll do

•Work with each customer to turn a loosely described need into a written scope and a definition of done.
•Connect [product] to the customer's systems and data, writing the integration code, transformations and checks it needs.
•Diagnose problems that span our product and the customer's environment, often with limited access.
•Keep customer stakeholders informed in plain language, including when the answer is 'not yet' or 'not like that'.
•Check that AI features perform acceptably on the customer's real data before go-live, and explain the results honestly.
•Hand each deployment over in a state the customer's team can run, with a clear note and sensible security.
•Report patterns from the field to the product team, and help decide which requests become product changes.

What you need

•You have shipped production software in at least one language, and can write tested code quickly in a codebase you didn't create.
•You have integrated a product with another organisation's systems or data and taken it through to real use.
•You can show a time you explained a technical trade-off or a delay to someone who wasn't an engineer.
•You are comfortable with [travel level] and with working on site when a deployment needs it.

Nice to have

•Experience with [customer platforms, e.g. data warehouses, ERP or document systems].
•Experience deploying or evaluating features built on language models.
•A background in support engineering, implementation, consulting or running a small technical business.
•Familiarity with security and data-handling expectations in regulated customers.

How we use AI tools

•Where company policy permits, use approved AI tools to get moving in unfamiliar code, and check their suggestions against the customer's actual system before relying on them.
•You'll be expected to tell a customer when a model is the wrong answer to their problem and a simpler rule would serve them better.
•You may use AI tools in the work sample; tell us which ones and where you checked or changed what they gave you.

Pay

Salary range: [currency, minimum–maximum], plus [equity/bonus/benefits]. The range reflects [location/working pattern]. We place every offer within it using the same pre-set, job-related, gender-neutral factors — level and breadth of production engineering experience, depth of hands-on customer deployment or integration experience, travel and on-site commitment, number and complexity of customer deployments carried at once — never previous salary or negotiating style.

AI as an advantageAI boost4D framework

Delegate: Hand AI the first draft of the job description from your signed-off competency model. The must-haves, the pay range and the final wording stay with people.

Show the prompt and the checks

Describe: You are helping write an outcome-based job description for a Forward Deployed Engineer role. Context: I will paste the competency model (must-have and trainable, with evidence), the 12-month outcomes, how the team uses AI tools, the location and working pattern, and the pay range. Produce: a summary paragraph that leads with the problem and what the hire will own; 'What you'll do' as outcomes, not tasks; 'What you need' containing only the must-haves; 'Nice to have' for the trainable items; 'How we use AI tools'; and a pay section that states the range. Use British English and inclusive, gender-neutral wording, avoid hype, and replace any 'X years' with the capability it stands for. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that 'What you need' contains only the must-haves, that no degree, employer or years requirement crept in, and that the pay range and location are exactly what was approved.
Diligence: The hiring manager owns the content and the recruiter owns publishing, including the pay information the law requires for each location. AI drafts the advert; people decide what it says.

Don't miss: Writing the advert like a sales role. Candidates who want to engineer will skip it, and those who apply may not want to code.

Stage 4 of 13Optional

0 of 3 done

Find candidates

Sourcing strategy

Who runs it: Recruiter / sourcer
Done when: A shortlist-ready pipeline from at least three channels, with outreach tracked.

Use when:: Inbound applications won't give you enough qualified candidates.
Skip when:: Your shortlist already comes from inbound applications or referrals.

Key tool

Search query

("forward deployed" OR "forward deployment" OR "implementation engineer" OR "integration engineer" OR "customer engineer" OR "solutions engineer") AND ("integration" OR "deployment" OR "go-live" OR "onsite" OR "on-site") AND (Python OR TypeScript OR Java OR SQL) NOT ("intern" OR "student")

First outreach message

AI as an advantageAI boost4D framework

Delegate: Hand AI the search queries and the first draft of the outreach template. Choosing channels, personalising to a candidate's public work and sending stay with the recruiter.

Show the prompt and the checks

Describe: You are helping a recruiter source candidates for a Forward Deployed Engineer role. Context: I will paste the must-have competencies, the kind of work we want evidence of, the channels we are using and the pay range. Produce: (1) one search query per channel, using OR for alternatives, AND for things that must all appear and NOT to exclude, with a one-line note on what each query looks for; and (2) a first-outreach template of under 120 words that opens with a [placeholder for something the candidate built], states the problem we are hiring to solve and the pay range, and ends with a low-pressure question. Use British English and inclusive wording. Do not refer to any specific person. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the queries search for evidence of the work rather than job titles alone, and that the template claims nothing about the role or the pay you can't back up.
Diligence: The recruiter personalises every message to something the candidate actually built, and sends it. No names or profile data go into the prompt; AI drafts, people decide whom to contact.

Don't miss: Searching only for the exact job title. Few companies use it, so most strong candidates hold a different one.

Framework

Channel mix + evidence-first outreach

Spread sourcing across channels where the work is visible, and open outreach with the problem, not the perks.

Pick channels where candidates show their work, not only where they list job titles.
Write one search query per channel. OR joins alternatives, AND joins things that must all appear, NOT excludes. Keep the version that works best.
Personalise the first line to something the candidate actually built or wrote.
Lead with the problem and the pay range. Save the perks for later.
Track reply rates by channel each week and drop the channel that isn't working.

Why it works: Searching for evidence of the work can surface candidates whose current title differs from the vacancy, or whose CV undersells what they have done.

Sourcing basics

Adapt the search query for each platform — the same words behave differently on each site.
Candidates with adjacent titles may have relevant evidence. Search for the work and outcomes the role needs, not the current title.
Channel activity is a lead, not evidence. Review linked work and examples against the written competencies.

Where to look

Implementation, integration and support engineering teams at software vendors

These engineers already fit products to customers' systems; ask which deployments they took to go-live themselves.

Technical consultancies and systems integrators

People who shipped for clients bring the customer half of the job; check that they wrote and ran code rather than only advising.

Referrals from your customer success and support teams

They know which engineers at partners or former employers earned a customer's trust during a difficult rollout.

Professional profiles mentioning go-lives, customer integrations or on-site delivery

The title is uncommon, so search for what the person did: customer integrations, go-lives and on-site delivery.

Public write-ups, talks and open-source connectors

A connector or a post about a hard integration shows how the person deals with systems that do not behave as documented.

Boolean search string

("forward deployed" OR "forward deployment" OR "implementation engineer" OR "integration engineer" OR "customer engineer" OR "solutions engineer") AND ("integration" OR "deployment" OR "go-live" OR "onsite" OR "on-site") AND (Python OR TypeScript OR Java OR SQL) NOT ("intern" OR "student")

First outreach message

Hi [name], I read about [specific integration, deployment or write-up] and it's close to the work we need. At [company], customers sign up for [product] and then wait while someone makes it work with their own systems and data. We're hiring the engineer who does that, with [travel expectation] and paying [range]. Would you be open to 20 minutes on what a typical deployment looks like here?

Stage 5 of 13Required

0 of 3 done

Check applications

Application screening

Who runs it: Recruiter
Done when: Every application reviewed against the same written knockouts within five working days.

Key tool

Reject only if one of these is missing

•Can meet the role's work-authorisation requirements by the start date, with sponsorship where the employer offers it. Don't ask for documents at this stage.
•Has written and shipped production code, not only configured tools or run projects.
•Describes at least one integration or deployment for a customer or internal user that reached real use.

AI as an advantage4D framework

Delegate: Hand AI the job of turning your written knockouts into a consistent checklist with reason codes. Reviewing each application stays with the recruiter.

Show the prompt and the checks

Describe: You are helping a recruiter prepare an application-screening checklist for a Forward Deployed Engineer role. Context: I will paste the must-have competencies and our written knockout criteria. Produce: (1) each knockout as a yes/no question answerable from an application alone; (2) a short list of reason codes for a 'no'; and (3) a note of any criterion that looks like a proxy — a degree, employer brand or employment gap — rather than a job-related requirement, with a suggested rewrite. Use British English. Do not evaluate any applicant and do not ask for applicant details. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that each question is binary and job-related, and that every flagged proxy has been removed or justified in writing.
Diligence: A person reviews every application against the checklist and records the reason. Never paste CVs or applicant details into an AI tool, and never let a tool screen anyone out — in New York City and the EU that can bring automated-decision rules into play.

Don't miss: Scoring down candidates from smaller companies because the customers they deployed for are not household names.

Framework

Knockout criteria

A small set of yes/no requirements, written in advance, applied to every applicant the same way.

Derive knockouts only from must-have competencies and genuine legal requirements.
Keep them binary and answerable from the application itself.
Apply them in the same order to every application and log the reason for each rejection.
Do not use proxies such as university, employer brand or employment gaps as knockouts.
Anything ambiguous gets a second review or moves forward to the skills stage.

Why it works: Early screening rejects people before richer evidence exists, so its criteria need the most care. Written criteria make decisions reviewable — but each one must also be job-related, applied consistently and checked for unjustified adverse impact.

Screening rules

Do not use degrees, employment gaps or certifications as filters unless they are demonstrably job-related and justified for this role.
Judge the claims in a CV, not how polished it is — a well-written CV may or may not have had AI help, and either way it is the evidence that matters.

Knockout criteria

Can meet the role's work-authorisation requirements by the start date, with sponsorship where the employer offers it. Don't ask for documents at this stage.
Has written and shipped production code, not only configured tools or run projects.
Describes at least one integration or deployment for a customer or internal user that reached real use.

Green flags

Names a deployment that went wrong and what they changed to get it live.
Mentions talking directly with the people who used what they built, not only with other engineers.
Mentions documentation, a runbook or a hand-over they left behind.

Red flags

Every example is a greenfield build on their own terms; nothing shows working inside someone else's constraints.
Customer-facing experience that was entirely demos or presales, with no ownership of a live result.
Describes customers mainly as obstacles in the stories they tell about past projects.

Watch out for

Reading a long list of integrated platforms as proof of depth. Ask which one fought back and how they got it working.

Compliance checkpointNew York CityEU

For a New York City employment decision, work out whether a tool is an 'automated employment decision tool' (AEDT) under Local Law 144 — one that uses covered techniques to substantially assist or replace a discretionary decision. Before using a covered tool, make sure an independent bias audit was completed no more than a year earlier, publish the required summary, and give covered candidates or employees the required notice at least ten business days before use. In the EU, the AI Act (Annex III) lists AI used to recruit, filter applications or evaluate candidates as high-risk, subject to the Article 6(3) exception; the related obligations apply from 2 December 2027 under the amended timetable. A manual screen does not exempt an AI tool used elsewhere in the process.

Sources: NYC DCWP — Automated employment decision tools · EU AI Act — consolidated Regulation (EU) 2024/1689 · checked 2026-09-25

Stage 6 of 13Optional

0 of 3 done

Recruiter call

Recruiter screen

Who runs it: Recruiter
Done when: A 20–30 minute call that confirms logistics, motivation and one or two must-have signals.

Use when:: You are hiring at volume, or pay and logistics need confirming early.
Skip when:: You have only a handful of applicants — fold the pay and logistics questions into application screening instead.

Key tool

Ask every candidate, in this order

1Tell me about a deployment or integration you personally got working for a customer or an internal team. What was the hardest part?
2Have you ever had to tell a customer that something wouldn't be ready, or wouldn't work as they hoped? What did you say?
3How do you feel about the travel and on-site work this role involves?
4Our range for this role is [range]. Does that work for you?

AI as an advantage4D framework

Delegate: Hand AI the first draft of the screening-call script and its evidence anchors. Running the call and taking the notes stay with the recruiter.

Show the prompt and the checks

Describe: You are helping a recruiter write a 20–30 minute structured screening call for a Forward Deployed Engineer role. Context: I will paste the must-have competencies, the logistics we need to confirm (location, working pattern, notice period) and the pay range. Produce: an opening that explains the process, the timeline and the pay range; 4–6 questions in a fixed order, each with one line on what a strong answer contains; and a closing that asks whether the published range works. Use British English and inclusive wording. Do not include questions about salary history, age, family, health or any other protected characteristic. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that every question is job-related and lawful, that the pay question asks whether the range works rather than for history, and that the anchors describe evidence, not impressions.
Diligence: The recruiter asks the same questions of everyone and writes the notes. No candidate details go into the prompt; AI drafts the script, people run the call and decide.

Don't miss: Treating a polished talker as a strong engineer, or a quiet engineer as weak with customers. The recruiter screen checks motivation, logistics and whether they can describe their own work; later rounds test the rest.

Framework

Structured screening call

The same short set of questions for every candidate, with notes taken against what a strong answer contains.

Open by explaining the process, timeline and pay range. No surprises later.
Confirm logistics: location, working pattern, notice period and whether the range works for them.
Ask the same 4–6 questions in the same order, and note evidence, not impressions.
Leave time for the candidate's questions. Don't score their questions unless they test a written, job-related competency.
Decide within 48 hours and tell the candidate either way.

Why it works: Using the same questions and written evidence anchors makes answers easier to compare, and a short, predictable call respects the candidate's time.

Screening call basics

Set the decision timetable before sourcing and tell candidates when to expect each update.
Ask every candidate what draws them to this particular role, and listen for interest in the work described rather than the title.
Confirm notice period and whether they are in other processes, so you can plan the timetable.
End every call by asking whether the published pay range works — never ask for salary history.

Recruiter screen questions

1.Tell me about a deployment or integration you personally got working for a customer or an internal team. What was the hardest part?
Listen for: A specific system, their own role in it, and a hard part that was about the environment or the people, not only the code.
Red flag: Speaks only for 'we' and can't say which piece was theirs.
2.Have you ever had to tell a customer that something wouldn't be ready, or wouldn't work as they hoped? What did you say?
Listen for: A real moment, an honest message and an alternative offered.
Red flag: Says it has never happened, or describes hiding the problem until it went away.
3.How do you feel about the travel and on-site work this role involves?
Listen for: A clear, practical answer so both sides know where they stand early. Record any constraint as stated, without judging it.
4.Our range for this role is [range]. Does that work for you?
Listen for: A clear answer on whether the published range works. Don't ask for salary history — this process sets pay from the published band and pre-set, job-related factors.

Compliance checkpointUS (state and city)EU

Don't ask for salary history. In the EU, national laws implementing Article 5(2) of Directive (EU) 2023/970 must prohibit the question. US rules vary, but jurisdictions including California and New York prohibit employers from seeking salary history. Ask whether the published range works instead.

Sources: EU Pay Transparency Directive 2023/970, Article 5 · California Labor Commissioner — salary history · New York State DOL — salary history ban · checked 2026-09-25

Stage 7 of 13Required

0 of 3 done

Work sample

Skills assessment / work sample

Who runs it: Hiring manager (design) + recruiter (logistics)
Done when: Every shortlisted candidate completes the same job-shaped task, marked against criteria written in advance.

Key tool

Get a stalled invoice integration live for a distributor

A wholesale distributor has bought a product that reads supplier invoices with a language model and posts them into their accounting system. The pilot has stalled. You receive a short email thread between their finance controller, who wants it live by month end, their operations lead, who says 'the totals look wrong', and their IT contact, who will only allow access through a read-and-post API. You also get an export of a few hundred extracted invoices with quality problems (duplicates, mixed date formats, supplier codes that don't match their records), a labelled sample of twenty invoices with the correct values, and a half-working Python connector that posts to a local stand-in for their accounting API and silently drops some records. Work out what is actually wrong, build the smallest path that gets clean invoices posted and sends the rest somewhere a person can review them, check how the extraction does on the labelled sample, and write to the customer.

Planned for up to three hours (adjustments available on request). At the agreed stopping time, write a short note on what you would examine next, and what you deliberately left out.

AI as an advantage4D framework

Delegate: Hand AI the first draft of the work-sample brief and its marking sheet. Choosing the task, setting the timebox and marking stay with the hiring manager.

Show the prompt and the checks

Describe: You are helping a hiring manager design a work sample for a Forward Deployed Engineer role. Context: I will paste the competency model, a real problem the team solved recently with anything confidential removed, the timebox, and our AI-tool policy for candidates. Produce: a candidate-facing brief (what to do, what to hand in, the time cap, how to request an adjustment, which AI tools are allowed and how to report their use); and a marking sheet with 4–6 criteria tied to named competencies, each with what a 1, a 3 and a 5 look like. Use British English and plain, inclusive wording. Do not design anything that needs more than the stated time. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the task fits the timebox, that every criterion maps to a competency, and that the brief gives all candidates the same starting materials.
Diligence: The hiring manager owns the task and the criteria, and people mark every submission. Do not paste candidate submissions into an AI tool for scoring; AI drafts the brief, people mark and decide.

H-EvaluateH-Evaluate can generate a job-specific assessment from your job description, so you don't have to build the task by hand.How H-Evaluate helps →

Don't miss: Marking only the code. A candidate who fixes every record but promises the customer something they can't deliver has failed the part of the job that loses accounts.

Framework

Work-sample test

A small, realistic slice of the job, marked against criteria written in advance. Give candidates equivalent materials and arrange reasonable adjustments where required.

Take a real problem the team solved recently and shrink it to fit the timebox.
Write the marking criteria first, tied to the competency model.
Timebox honestly — for take-home work, a few hours at most — and say so in the brief.
State the AI-tool policy in writing. Where the job permits these tools, use equivalent conditions in the assessment and evaluate how candidates verify their output.
Mark without CV details where you can, and have two people mark borderline submissions.

Why it works: A well-designed work sample gives direct evidence of job-relevant skill rather than a proxy for it, and gives candidates a realistic preview of the work.

Assessment rules for every candidate

State the planned time cap and how to request an adjustment. At the agreed stopping time, ask candidates to note what they would examine next and what they left out — never reward unpaid overtime.
Give every candidate the same starting materials, and use a second marker for borderline submissions.
Say in writing which AI tools are allowed and ask candidates to tell you how they used them.
Invite every candidate to ask for adjustments, and answer each request promptly.
Pay for anything the task costs the candidate to run, such as model or cloud usage.

The work sample

Get a stalled invoice integration live for a distributor

Timebox: Planned for up to three hours (adjustments available on request). At the agreed stopping time, write a short note on what you would examine next, and what you deliberately left out.

What the candidate hands in

A reply to the email thread, of no more than a page, saying what you expect to be live by month end and on what assumptions, what cannot be promised yet, and the questions you need answered.
The repaired connector, with records that can't be posted safely held back with a reason rather than dropped.
A short check of extraction accuracy on the labelled sample, with the errors grouped by type and a plain-language summary the customer could plan around.
A hand-over note for the customer's IT contact covering how to run it, what to watch and what to do when something fails.
One item for our product team, saying whether it should be a one-off fix for this customer or a change to the product, and why.

Marking criteria (write these first)

The real causes of 'the totals look wrong' are found and separated, rather than treated as one bug.
Failures are traced across the connector and the accounting system's interface by forming and testing hypotheses, not by guessing which side is at fault.
The connector change is the smallest that works, and no record is lost without a trace.
The extraction check uses the labelled sample, and the summary neither overstates nor buries the error rate.
The customer reply is accurate, readable by a non-engineer, and promises only what the work supports.
The hand-over note would let someone else run and troubleshoot the integration without calling the candidate.
The product feedback makes a clear one-off-or-product call with a reason, rather than a list of wishes.

Adjustments: Candidates can ask for more time, or do a shorter version live with an interviewer. Model usage is covered by a spend-limited key in the starter repository, and pre-computed extraction results are included for anyone who prefers not to call the model.

Watch out for

Giving a perfectly clean dataset. The point of the task is how they deal with data that does not match what the product expects.

Compliance checkpointUSGreat BritainEU

In the US, covered employers must provide a reasonable accommodation to a qualified applicant with a disability unless it would cause undue hardship (ADA). In Great Britain, the Equality Act 2010 requires reasonable adjustments in recruitment. In the EU, the duty comes from national equality law. Don't ask for more medical information than the law allows.

Sources: EEOC — prohibited practices · Equality Act 2010 · checked 2026-09-25

Stage 8 of 13Required

0 of 3 done

Structured interviews

Structured interview loop

Who runs it: Interview panel (named in advance)
Done when: Every competency has a lead interviewer and at least one second source of evidence, with the same questions for every candidate.

Key tool

Interview questions by pillar

Free in this kit: Domain questions for every round. The other three pillars and the AI-fluency check are measured by H-Evaluate.

Free in this kit

Senior forward deployed or integration engineer who marked the work sample · Scoping ambiguous customer problems · Integration with unfamiliar systems · Safe, maintainable hand-over

1.Before you touched the connector, what did you decide the customer actually needed by month end? What in the email thread led you there, and what did you consider and drop?
Scoping ambiguous customer problems
Good answerRestates the need in their own words, points to the specific lines in the thread that shaped it, names at least one scope they considered and why they dropped it, and says what evidence would change their mind.
Weak answerWent straight to fixing code and can't explain what 'done' meant for this customer.
2.Walk me through the smallest working path you built from the export to the accounting system. Which data problems did you fix in code, which did you hold back for a person, and why that split?
Integration with unfamiliar systems
Good answerExplains a deliberate split between automatic fixes and human review, ties each choice to the risk of posting a wrong invoice, and mentions an alternative they rejected.
Weak answerFixed every problem in code including guesses at supplier codes, or can't say why some records were treated differently.
3.Six weeks after you leave, the connector starts failing at night. What in your hand-over lets the customer's IT contact work out what happened without you?
Safe, maintainable hand-over
Good answerPoints to specific things already in place: failures that surface with a reason, a held-records queue, credentials the customer controls, and a short runbook with the first checks to make.
Weak answerAssumes someone will call them, or the note describes how the code works but not what to do when it breaks.

Optional follow-ups (2)

4.The customer's IT contact now says the API you used will be replaced next quarter. What would you change in your design today, if anything?
Integration with unfamiliar systems
Good answerKeeps the change small, isolating the part that talks to the accounting system so it can be swapped, and checks what the replacement will offer before building for it.
Weak answerProposes rebuilding for the new system on a guess, or ignores the change.
5.If the finance controller had replied asking for every invoice to be live by month end regardless, what would you have done differently in your scope?
Scoping ambiguous customer problems
Good answerHolds the line on posting unsafe records, offers a concrete alternative such as a review queue cleared by their team, and puts the trade-off in writing.
Weak answerAgrees and loosens the checks, or refuses without offering any way forward.

AI as an advantageAI boost4D framework

Delegate: Hand AI the drafting of probe questions and strong / weak anchors for one competency. Asking, listening and scoring stay with the interviewer.

Show the prompt and the checks

Describe: You are helping an interviewer prepare a structured technical interview for a Forward Deployed Engineer role. Context: I will paste one competency, its evidence description and the core question we ask every candidate. Produce: four probes in this fixed order — what would you do, why that choice, what else did you consider, how would you know it worked — tailored to the question; a one-line description of a strong answer and of a weak answer; and two follow-ups to use only if time allows. Use British English and inclusive wording. Keep everything about the work, nothing about the person. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the probes test the named competency rather than trivia, that the anchors describe observable evidence, and that no question touches a protected characteristic.
Diligence: Interviewers ask the same core questions of every candidate and score alone against the rubric. Interview notes and candidate names never go into an AI tool; AI drafts the questions, people interview and decide.

H-EvaluateH-Evaluate can add evidence on Cognitive, Situational judgement, Behavioural and AI fluency for your panel to review alongside these interviews.How H-Evaluate helps →

Don't miss: Rewarding the most confident answer in the customer-room round. Look for accuracy about what is known, not polish.

Framework

Structured technical interview

Every candidate gets the same job-specific questions, each interviewer leads on specific competencies, and every answer is probed with the same four follow-ups: what would you do, why, what else did you consider, and how would you know it worked.

Give each competency a lead interviewer, plus a second source of evidence — the work sample, another round or an independent marker. Avoid asking the same thing twice, but never let one person's view be the only evidence for a critical competency.
Ask the three core questions for your round, in order, for every candidate. Use an optional follow-up only if there is time.
Probe each answer: why that choice, what else they considered, and how they would know it worked — until you hear the candidate's own technical decision.
Take notes on evidence during the interview. Don't rate until it's over.
Fill in your interviewer sheet and submit it before you talk to any other interviewer.

Why it works: Structured interviews make answers comparable: every candidate faces the same job-related questions and is scored against the same anchors.

Interview rules

Use the same core questions in the same order for every candidate.
In the work-sample review, understand the candidate's decisions against the rubric — don't turn it into a debate about your preferred solution.
Avoid trivia disconnected from a real job decision. Use a realistic debugging, design or evaluation problem instead.

Watch out for

Letting the debugging round become a test of whether the candidate knows your product's internals, which no outside candidate can.

Compliance checkpointUSUKEU

Don't ask about protected characteristics — such as age, disability, pregnancy or family plans, religion, race or nationality — unless applicable law permits the question for a specific, necessary, job-related purpose, and HR or counsel has confirmed that basis beforehand. Ask only whether the candidate can meet the role's work-authorisation requirements. If a candidate volunteers protected information, don't probe; record only what is lawfully needed, keep it separate and restrict access.

Sources: EEOC — prohibited practices · Equality Act 2010 · checked 2026-09-25

Where to find more interview questions

Use web question banks for inspiration only: ask every candidate the same job-related questions, check each one against this kit's competencies, and never ask about protected characteristics. Don't reuse this kit's work sample from a public bank — candidates can find questions that circulate online, so a widely posted question tests preparation more than skill.

Show 7 sites

US OPM — Structured interviews(opens in a new tab)
US federal guidance on building structured interviews, with a guide, training material and sample questions with rating scales.
FreeFor interviewers
Acas — Interviewing job applicants(opens in a new tab)
UK public guidance on preparing fair interviews, asking applicants the same questions and avoiding discriminatory ones.
FreeFor interviewers
Workable — Interview questions library(opens in a new tab)
Sample interview questions for employers, listed by job role, including machine learning, data and engineering roles.
FreeFor interviewers
Indeed for Employers — Interview questions(opens in a new tab)
Sample interview questions for employers by job title and skill, with notes on what to look for in answers.
FreeFor interviewers
Tech Interview Handbook(opens in a new tab)
Open-source software-engineering interview preparation: coding, system design and behavioural questions.
FreeFor candidates and interviewers
Chip Huyen — Machine Learning Interviews Book(opens in a new tab)
Free online book with knowledge questions on maths, computer science and machine learning, grouped by difficulty.
FreeFor candidates and interviewers
Blind — Interview questions channel(opens in a new tab)
Anonymous posts by tech workers about questions they report being asked. Unverified; some content needs sign-in.
Free, some content needs sign-inCandidate reports, unverified

Links checked 2026-10-05. External sites; we don't control their content.

Stage 9 of 13Required

0 of 2 done

Compare evidence

Scoring, calibration and debrief

Who runs it: Hiring manager (chairs) + panel
Done when: A documented hire / no-hire decision traceable to scored evidence against the competency model.

Key tool

Interactive scorecard

Score one candidate against the rubric. Everything stays in your browser. Download it as a spreadsheet for your records.

Scoping ambiguous customer problems Must-have

Weight

What do 1, 3 and 5 look like?

1: Starts building on the first reading of the request; can't say what done looks like.
3: Writes a reasonable scope when prompted and asks some useful questions, but misses a constraint that would change the plan.
5: Finds the real need behind the request, writes it down with a definition of done, and asks the questions that change the plan before any code.

Integration with unfamiliar systems Must-have

Weight

What do 1, 3 and 5 look like?

1: Needs clean, documented systems to make progress; stalls on messy data.
3: Gets a working integration with some guidance; handles the obvious data problems.
5: Gets productive quickly in unfamiliar systems, builds the smallest path that works, and treats bad data deliberately rather than silently.

Debugging in environments you don't control Must-have

Weight

What do 1, 3 and 5 look like?

1: Changes things until the error disappears; can't explain why the fix worked.
3: Narrows the problem with help; tests hypotheses but sometimes several at once.
5: Works through one hypothesis at a time with limited access, asks for exactly the evidence needed, and records what was ruled out.

Customer communication and expectation setting Must-have

Weight

What do 1, 3 and 5 look like?

1: Relies on jargon, or tells the customer what they want to hear.
3: Clear when explaining good news; less steady when the answer is no or not yet.
5: Gives accurate, plain messages in good and bad news alike, offers alternatives, and keeps written updates that separate fact from guess.

Field-to-product judgement Can learn

Weight

What do 1, 3 and 5 look like?

1: Treats every customer request as a one-off, or tries to change the product for every request.
3: Sees repeated requests when they are pointed out and passes them on informally.
5: Spots patterns across customers unprompted and writes feedback with evidence and a proposed scope the product team can act on.

Safe, maintainable hand-over Can learn

Weight

What do 1, 3 and 5 look like?

1: Leaves a deployment only they understand, with shared or personal credentials.
3: Writes a hand-over note and scopes access when reminded.
5: Designs for the customer's team from the start: failures surface with reasons, access is scoped, and the runbook covers what to do when it breaks.

Evaluating AI on the customer's real data Can learn

Weight

What do 1, 3 and 5 look like?

1: Trusts demo results; has no way to tell whether the model works for this customer.
3: Checks the model on customer data when asked, but reports the results loosely.
5: Builds a labelled sample from the customer's own records before go-live, groups the errors by cause and reports them in terms the customer can plan around.

Weighted score– / 5

AI as an advantage4D framework

Delegate: Hand AI the drafting of a blank debrief worksheet and agenda from the competency rubric alone. People add the evidence locally; the scores and the decision stay with the panel.

Show the prompt and the checks

Describe: You are helping a hiring manager prepare a debrief for a Forward Deployed Engineer role. Context: I will paste the competency rubric only — the competencies, their weights and their 1, 3 and 5 anchors. Produce: (1) a blank debrief worksheet with one row per competency and empty columns for each interviewer's independent score, the evidence they cite, the spread of scores and an 'evidence gap?' box; (2) a 45-minute agenda: confirm every scorecard is in and reveal all scores at once, discuss the widest spreads using evidence only, review any must-have scored 1, then look at the weighted total and decide (hire, no hire or one targeted follow-up), and record the reasons; and (3) neutral questions the chair can ask to draw out evidence rather than adjectives. Leave every evidence and score cell empty. Do not suggest a score, a rating or a recommendation. Use British English. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the worksheet follows your rubric exactly — same competencies, weights and anchors — and that the agenda keeps independent scores hidden until the reveal.
Diligence: Interviewers fill in the evidence and scores locally, alone, before the debrief, and the panel decides together. Candidate notes and personal data never go into an AI tool; AI never scores, ranks or compares candidates.

H-EvaluateH-Evaluate gives you a report on each candidate's assessment evidence to bring into this debrief.How H-Evaluate helps →

Don't miss: Letting a strong technical score cover a weak communication score. In this role, a gap in either one turns into a stalled deployment.

Stage 10 of 13Optional

0 of 2 done

Check references

References and background checks

Who runs it: Recruiter (references) + HR (checks)
Done when: At least two references that test specific competencies, plus only the checks that are lawful and relevant to the role.

Use when:: It is lawful where you hire, and specific evidence from a referee would change the decision.
Skip when:: Local law or company policy rules it out.

Key tool

Ask each referee

1What could the customer or team do after [candidate]'s deployment that they couldn't do before, and is it still running?
2Tell me about a time [candidate] had to give a customer or stakeholder unwelcome news. How did it go?
3When they handed something over, how much did people need to go back to them afterwards?

AI as an advantage4D framework

Delegate: Hand AI the drafting of reference questions aimed at the competency the panel was least sure about. Choosing referees, making the calls and interpreting the answers stay with the recruiter.

Show the prompt and the checks

Describe: You are helping a recruiter write competency-based reference questions for a Forward Deployed Engineer role. Context: I will paste the competency model and the one or two competencies where our evidence is thinnest — no candidate details. Produce: 3–4 questions per competency that ask for specific examples ('tell me about a time…') rather than ratings; an opening question about how the referee worked with the person and for how long; and a closing question about what their next manager could do to help them do their best work. Use British English and inclusive wording. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the questions ask for examples rather than opinions, that they stay on job-related competencies, and that none asks about health, family or other protected matters.
Diligence: References are taken with the candidate's consent and interpreted by people. Referee answers and candidate details never go into an AI tool; AI drafts the questions, people decide.

Don't miss: Accepting 'customers loved them' without asking what the customer could do after they left that they couldn't before.

Framework

Competency-based referencing

Treat references as a last structured conversation about the candidate's work, aimed at the competencies where your evidence is thinnest.

With the candidate's consent, ask for two people who saw their relevant work directly — ideally a former manager and a peer.
Accept suitable alternatives if a manager or peer isn't available, and never penalise a candidate for a former employer's no-reference policy.
Aim your questions at the one or two competencies the debrief was least sure about.
Ask for examples, not ratings. 'Tell me about a time they…' works here too.
Set the timing of each background check by the law and policy that apply.

Why it works: Generic reference questions tend to produce little job-related evidence. Asking for specific examples tied to the role's competencies turns referencing into something you can use.

Core reference questions and checks

Open with: 'How did you work together, and for how long?' — it tells you how much weight the rest can carry.
Ask: 'Tell me about a time something they owned went wrong. What did they do?'
Close every reference with: 'What should their next manager do to help them do their best work?'
Verify only claims that were material to the decision — don't verify a degree the role never required.
Run criminal-record checks only where the role justifies them and local law allows; many roles don't need one.
Schedule formal work-authorisation checks at the legally required time: before employment starts in the UK; for US Form I-9, Section 1 by the first day of paid work and Section 2 within three business days.

Reference questions specific to this role

1.What could the customer or team do after [candidate]'s deployment that they couldn't do before, and is it still running?
Listen for: A concrete, lasting outcome and some sense of whether it survived after they moved on.
2.Tell me about a time [candidate] had to give a customer or stakeholder unwelcome news. How did it go?
Listen for: Evidence of honesty under pressure from someone who saw it, including how the relationship held up afterwards.
3.When they handed something over, how much did people need to go back to them afterwards?
Listen for: Whether their hand-overs worked in practice, not only on paper.

Compliance checkpointUS

If a consumer reporting agency provides a background report, the Fair Credit Reporting Act requires a clear, stand-alone written disclosure and the candidate's written authorisation before you order it. Before rejecting someone because of the report, give them a copy and the FCRA summary of rights and a reasonable opportunity to review and dispute it before any adverse action; if you still reject, send a final adverse-action notice. State and local 'fair chance' laws may delay criminal-history questions or checks until after a conditional offer.

Sources: FTC — Background checks: what employers need to know · FTC — Using consumer reports: what employers need to know · checked 2026-09-25

Stage 11 of 13Required

0 of 2 done

Agree the offer

Offer, negotiation and close

Who runs it: Hiring manager + recruiter
Done when: An accepted written offer within the approved band, with a start date.

Key tool

Build the offer around

•Impact they can see: customers going live on work they did, and product changes that started with their field notes.
•A clear, written picture of travel, on-site time and the number of deployments carried at once.
•Direct access to the product team, with a regular slot to bring field evidence to roadmap decisions.
•A transparent level and what progression looks like, whether towards leading deployments or moving into product engineering.

AI as an advantage4D framework

Delegate: Hand AI the first draft of the offer message built around what the candidate said matters to them. The figure, the approval and the conversation stay with the hiring manager.

Show the prompt and the checks

Describe: You are helping a hiring manager draft an offer message for a Forward Deployed Engineer role. Context: I will paste three general priority categories (for example: learning, flexibility, scope) — not the candidate's words, notes or personal details; the parts of the offer; and the start-date options — without the salary figure. Produce: a warm, plain-English message that links each part of the offer to one of their priorities, says what happens next and when the written offer follows, and invites questions. Use British English and inclusive wording, and leave [brackets] for figures and names. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that nothing promised is outside policy or the approved band, that every claim about the role is true, and that the message reads as personal rather than templated.
Diligence: The hiring manager places the offer in the band using the same pre-set factors for everyone and makes the verbal offer personally. Figures and personal details are filled in by people, never pasted into AI.

Don't miss: Leaving travel load or customer count vague and letting the candidate discover it after they join.

Framework

Close plan (motivators → offer → objections)

Build the offer around what the candidate told you they care about, anticipate their objections, and make sure the verbal and written offers match.

List the candidate's top three motivators from your notes at every stage.
Make the verbal offer personally, and link each part of it to a motivator.
Ask what else they are weighing and when they have to decide.
Place the offer in the band using the same pre-set, job-related factors for everyone, and record why.
Send the written offer promptly after the verbal one.

Why it works: A close plan ties the offer to the candidate's stated priorities and makes approvals explicit before the final interview.

Offer checklist and negotiation

Stay inside the approved band. If the candidate is worth more, re-level them with evidence rather than stretching the band.
Trade in things that cost less than salary where policy allows: start date, learning budget, working pattern.
Before the written offer, ask: 'What would make this an easy yes?'
Agree approval and the pay band before the final interview, so the offer isn't held up.
The hiring manager makes the verbal offer; the written offer follows within a working day.
Record which pre-set factors placed the offer where it is in the band.
Tell unsuccessful finalists personally, without avoidable delay, with brief feedback.

What will close this candidate

Impact they can see: customers going live on work they did, and product changes that started with their field notes.
A clear, written picture of travel, on-site time and the number of deployments carried at once.
Direct access to the product team, with a regular slot to bring field evidence to roadmap decisions.
A transparent level and what progression looks like, whether towards leading deployments or moving into product engineering.

Compliance checkpointEUUS

Use objective, gender-neutral, pre-agreed factors to place candidates within the band, apply them consistently and record the decision as an internal pay-equity control. Check the national law implementing Directive (EU) 2023/970 and any local record-keeping rules; this recommendation is good practice, not a universal statutory documentation rule.

Sources: EU Pay Transparency Directive 2023/970 · checked 2026-09-25

Stage 12 of 13Required

0 of 2 done

Help them settle in

Pre-boarding and 30-60-90 onboarding

Who runs it: Hiring manager + buddy + HR
Done when: A new hire who has worked through a written 30-60-90 plan tied to the 12-month outcomes, with a check-in at each milestone.

Key tool

Before day one
Laptop, product access and a personal sandbox copy of the product ready before day one.
Days 1–30: learn
Learns the product well enough to tell a product bug from a customer-side problem, and meets the product, support and customer success leads.
Days 31–60: contribute
Leads a smaller deployment with a buddy available, from scoping through to go-live planning.
Days 61–90: own
Owns a customer deployment end to end, including the customer relationship and the hand-over.

AI as an advantage4D framework

Delegate: Hand AI the first draft of the 30-60-90 plan from the 12-month outcomes. Agreeing the plan with the new hire stays with the manager.

Show the prompt and the checks

Describe: You are helping a hiring manager draft a 30-60-90 day onboarding plan for a new Forward Deployed Engineer. Context: I will paste the 12-month outcomes from the intake meeting, the systems and people the hire will work with, and anything they will need before day one. Produce: a pre-boarding checklist (equipment, access, a named buddy, a first-week schedule); then three sections — days 1–30 learn, days 31–60 contribute, days 61–90 own — each with 3–4 concrete, checkable expectations and one milestone check-in question. Use British English and plain wording. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that each expectation is realistic for a new starter, ties back to a 12-month outcome, and offers the hire support rather than a test.
Diligence: The manager agrees the plan with the new hire in week one and owns the check-ins. The new hire's personal details stay out of the prompt.

Don't miss: Sending a new hire alone to a difficult customer in their first weeks, before they know the product well enough to tell a product bug from a customer-side problem.

Framework

30-60-90 day plan

Three phases — learn, contribute, own — with written expectations for each, agreed with the new hire in week one.

Before day one: equipment, access, a named buddy and a first-week schedule.
Days 1–30, learn: systems, people and the current state of the work.
Days 31–60, contribute: a first scoped piece of work shipped with support.
Days 61–90, own: an area of responsibility with clear outcomes.
Hold a check-in at each milestone against the written plan.

Why it works: Hiring doesn't end at the signature. A written onboarding plan makes expectations and support visible to the new hire and their manager.

Before day one
- Laptop, product access and a personal sandbox copy of the product ready before day one.
- Travel and expense accounts set up so the first customer visit isn't held up by admin.
- A named buddy who has led customer deployments here.
- Reading before day one: the deployment playbook if one exists, hand-over notes from two recent deployments and the list of open customer issues.
Days 1–30: learn
- Learns the product well enough to tell a product bug from a customer-side problem, and meets the product, support and customer success leads.
- Shadows a live deployment and writes up what they would have done differently.
- Ships one small fix or improvement to a live customer integration.
Days 31–60: contribute
- Leads a smaller deployment with a buddy available, from scoping through to go-live planning.
- Writes their first piece of field feedback for the product team, with evidence.
- Reviews the team's hand-over notes and fills one gap they found.
Days 61–90: own
- Owns a customer deployment end to end, including the customer relationship and the hand-over.
- Runs a check of an AI feature on that customer's own data before go-live and shares the result with them.
- Presents what they have learned from the field to the product team.

Compliance checkpointUSUK

US: the employee completes Form I-9 Section 1 no later than their first day of paid work, and the employer completes Section 2 within three business days after that day (on the first day if the job lasts less than three business days). UK: complete the prescribed right-to-work check before employment starts, and apply it the same way to everyone.

Sources: USCIS — Form I-9 instructions · GOV.UK — Check a job applicant's right to work · checked 2026-09-25

Stage 13 of 13Required

0 of 3 done

Measure time to hire

Measure the process: mean time to hire

Who runs it: Recruiter / talent lead + hiring manager
Done when: A stage-by-stage timing record for this hire, the slowest step named, and one change agreed before the next requisition opens.

Key tool

Record when the hire accepts

•Time to hire: days from the successful candidate entering the pipeline (application or first contact) to the accepted offer. Average it across hires for mean time to hire.
•Time to fill, recorded separately: days from requisition approval to the accepted offer.
•Days per stage, from the stage's first action to its last — and whether the time was spent waiting or working.
•Offer-acceptance rate: offers accepted divided by offers made.
•Where candidates dropped out, and the reason you were given.
•How many days it took to prepare the anonymised customer email thread, data export and starter connector before the work sample could go out.

Check in at 90 days whether the hire is meeting the outcomes in the job description — that tells you whether the process picked well.

Read: mean time to hire Read: time to hire vs time to fill

AI as an advantageAI boost4D framework

Delegate: Hand AI the job of building a blank timing worksheet and the instructions for reading it. Entering dates, working out the timings and deciding what to change stay with the recruiter and the hiring manager.

Show the prompt and the checks

Describe: You are helping a recruiter and a hiring manager set up a timing review for a Forward Deployed Engineer hire. Context: I will list the stage names we used, in order (for example requisition approved, sourcing, screening, recruiter call, work sample, interviews, debrief, references, offer accepted). Produce: (1) a blank worksheet with one row per stage and columns for start date, end date, days in stage, days spent waiting (scheduling, approvals, no reply) and number of candidates who entered and left; (2) step-by-step instructions for us to work out, from our own records, time to hire (the successful candidate's entry to the pipeline, by application or first contact, to the accepted offer; average it across hires for mean time to hire) and, separately, time to fill (requisition approval to the accepted offer); (3) five questions we should ask about the slowest stage, separating waiting from working; (4) a short template for recording one change to make before the next hire. Use British English. Do not include benchmarks or example figures. Ask me questions if anything is missing. Rule: do not ask for, and I will not paste, candidate names, interview notes, CVs, submissions or any other personal data. If any appears, stop and tell me to remove it.
Discern: Check that the worksheet covers every stage you actually ran, that the two definitions are not mixed up, and that the questions point at the process rather than at any person.
Diligence: People fill in the dates and do the arithmetic from their own records, choose the one thing to fix and write it down. No dates, names or details about any candidate go into the prompt.

Don't miss: Counting a candidate who withdrew over travel as a process failure without checking whether travel was clearly described in the advert and the first call.

Framework

Mean time to hire, by stage

Time to hire is the number of days from the successful candidate entering your pipeline (their application or your first contact) to their accepted offer; mean time to hire is that figure averaged across hires. Time to fill — requisition approval to acceptance — is a separate measure. Record both per stage, so you can see where the time went rather than only the total.

When the hire accepts, write down the date each stage started and ended, and the day the successful candidate entered the pipeline.
Work out the days per stage, the time to hire and the time to fill, and mark the slowest stage.
Note the offer-acceptance rate and the stage where most candidates dropped out.
Separate waiting time (scheduling, approvals, silence) from working time, and decide which one to shorten.
Fix one thing before the next hire, and write down what you changed.

Why it works: A single total hides where the delay sits. Per-stage timing points at the one step to fix, and the acceptance rate and drop-out points show whether candidates kept pace with the process.

Record for every hire

Time to hire: days from the successful candidate entering the pipeline (application or first contact) to the accepted offer. Average it across hires for mean time to hire.
Time to fill, recorded separately: days from requisition approval to the accepted offer.
Days per stage, from the stage's first action to its last — and whether the time was spent waiting or working.
Offer-acceptance rate: offers accepted divided by offers made.
Where candidates dropped out, and the reason you were given.
Check in at 90 days whether the hire is meeting the outcomes in the job description — that tells you whether the process picked well.

What to log for this role

How many days it took to prepare the anonymised customer email thread, data export and starter connector before the work sample could go out.
How long it took to book a colleague from operations or customer success for the customer-room round.
Where candidates dropped out, and whether any withdrawal came after travel or on-site expectations were discussed.

Where this role's hiring slows down

Watch for the work-sample pack being rebuilt from scratch for each search instead of kept up to date.
Watch for the customer-room round waiting on one person's calendar, with no second colleague trained to play the customer.
Watch for travel and on-site details coming up for the first time late in the process, after candidates have invested hours.

Compliance checkpointUKEU

Under the EU and UK GDPR, tell candidates how long you will keep their data, or the criteria used to decide. Give that notice when you collect data from them directly, or within the Article 14 time limit when it comes from another source (such as a referral or a sourcing tool). Delete or anonymise data when it is no longer needed, keeping only what a documented lawful purpose still requires.

Sources: GDPR — Regulation (EU) 2016/679, Articles 5, 13 and 14 · ICO — UK GDPR guidance · checked 2026-09-25

General information, not legal advice. Rules depend on the employer, the role and where the work is done — confirm what applies with HR or counsel.

Frequently asked questions

What does a forward deployed engineer do?

They take a product a customer has already bought and make it work in that customer's environment: scoping what is really needed, connecting it to their systems and data, fixing what breaks, and handing it over in a state the customer can run. They also bring what they learn back to the product team so the next deployment is easier.

Is it forward deployed engineer or forward deployment engineer?

Both titles are in use for the same kind of role, and some companies say FDE. What matters is the job behind the title: an engineer who works directly with customers after the sale and owns whether the deployment works.

How is a forward deployed engineer different from a solutions engineer?

A solutions engineer usually works before the sale, helping a prospect understand and evaluate the product. A forward deployed engineer usually arrives after the contract is signed and is judged on a working deployment. Titles vary between companies, so compare what each role owns rather than the name.

How do you test a forward deployed engineer's customer skills?

Make the customer half part of the evidence. Ask for a written reply to a customer in the work sample, and run an interview round where the candidate explains a delay or a limitation to a colleague playing the customer. Score both against the same rubric for every candidate.

Do forward deployed engineers need AI experience?

It depends on your product. If customers deploy AI features, the hire needs to check how the model performs on each customer's own data and explain the results honestly, which this kit treats as a trainable competency. Strong integration and customer judgement are harder to teach, so weight those first.

Go deeper

Related hiring kits

Guides

Skills tests

See your first AI-generated assessment in 5 minutes

No credit card. No question library to learn. Paste a job description and watch H-Evaluate build.

Request early access