TL;DR
To hire a forward deployed engineer, name one workflow and the person who can approve its result. Ask candidates to show what they built, how they tested it and what happened at handover. Use a paid, bounded work sample with approved data and access. Agree acceptance criteria, release ownership and support before work begins. Choose a pilot for one defined outcome, fractional capacity for a changing backlog, or a full-time hire for continuing full-week ownership.
Start with the work, then choose the role
By Rohit Raj — AI Consultant · Forward Deployed Engineer · LinkedIn
An FDE works with users and engineers to turn a specific workflow into deployed software. The job can include discovery, integration, testing and rollout, but the boundaries differ between companies. What a forward deployed engineer does explains the role in more detail.
Before writing a job description, write down the task: who uses the system, which data and tools it needs, who approves a result, and what fails today. An agent that cannot yet access internal data has a different hiring need from a well-specified feature that simply needs implementation. If your team has not chosen the workflow or cannot make product decisions, appoint an internal owner first.
For a customer-specific integration, ask who will work with the users and who will write the code. For a defined AI feature in your own product backlog, a freelance AI engineer may fit. The labels overlap; the work and decision rights are the useful comparison.
Write a scorecard a candidate can actually answer
Use the same short scorecard for each candidate or provider. Keep the answers tied to a project they can discuss and evidence you are allowed to inspect.
| Question | Evidence to request |
|---|---|
| Who discovered the workflow? | The users involved, a scoped problem statement and a decision they changed after seeing real use. |
| What did you implement? | A repository, architecture note, demonstration or another artifact they are allowed to share; ask which parts they personally built. |
| How was it checked? | Representative inputs, expected outputs, failure cases and a release decision. |
| What access was allowed? | How credentials, permissions and sensitive data were limited. |
| What happened after release? | The monitoring, support boundary, receiving owner and handover artifacts. |
Client work can be confidential. If a candidate cannot share code, ask them to walk through a sanitized design and a failure they investigated. Public portfolio projects can show engineering choices, but they are not evidence of a client's production result. For example, StellarMIND is an inspectable MCP and chat-to-SQL engineering example; any proposed result for your system still needs its own acceptance test.
Ask for the candidate's contribution rather than assuming that a project title proves ownership. A strong answer names a tradeoff, a limit and the next check that would reduce uncertainty.
Run a paid work sample with safe access
A small work sample can test collaboration and engineering judgment before a larger commitment. Pay for the agreed work, limit the scope, and make the evaluation criteria visible to both sides. An interview can still cover communication and team fit; the work sample gives you an artifact to discuss.
- Choose one bounded task. A staging integration, a retrieval evaluation or a permission test is easier to assess than a vague request to build an agent.
- Agree inputs and access. Use approved, representative examples in your environment. Grant only the repository and system permissions the task needs; do not make production credentials a condition of a trial.
- Set the acceptance check. Record the expected behavior, relevant failure cases and who will review the result before implementation starts.
- Ask for a handover. Require a short explanation of what was changed, how to run it, what is still uncertain and what your team would need to maintain it.
Score the result against the written task. If access is delayed or the examples do not represent the real workflow, record that as a scope constraint rather than treating the result as a prediction of production performance.
Choose the engagement shape and first milestone
The right model follows the amount and continuity of work. Timelines depend on availability, access, procurement and the systems involved; ask each provider for a plan against your actual prerequisites.
| Model | Useful when | First milestone to agree |
|---|---|---|
| Fixed-scope pilot | One workflow has a defined acceptance decision. | A working path in staging, evaluation examples and a release plan. |
| Fractional FDE | The backlog changes and benefits from the same engineer returning on agreed days. | Priorities, reserved days, review cadence and an internal decision-maker. |
| Full-time FDE | The organization needs continuing, full-week embedded engineering ownership. | An onboarding plan, first customer workflow and team responsibilities. |
| Agency team | Several disciplines need to work in parallel. | Named delivery owners, repository and account ownership, review points and handover. |
For a bounded outcome, see my forward deployed engineer pilot. For an ongoing part-week backlog, see the fractional FDE engagement. Both descriptions state what is delivered and what must be agreed before rollout.
Agree acceptance, release and support before the build
A useful first milestone is a decision supported by evidence, not a date promised without access to the system. Write down:
- Scope: the users, one workflow, connected systems and tasks explicitly left out.
- Quality: approved examples, a baseline where one exists, expected outputs, failure cases and who sets the threshold.
- Permissions: which actions the software may take, how disallowed actions are tested and who grants credentials.
- Operations: a staged rollout, monitoring, fallback, cost and latency limits, and a person who can stop or approve release.
- Handover: code and configuration in the agreed accounts, evaluation results, deployment instructions and a receiving engineer.
The AI project scope and acceptance checklist provides a brief you can adapt. If the required data, security review or receiving owner is unavailable, the first deliverable may be a gap assessment and a narrower staging slice. Do not represent that slice as a production outcome.
Questions to settle before you sign
How quickly can an FDE start? Ask about the engineer's actual availability and your access prerequisites. A pilot, retainer and employee search each have different dependencies; a fixed industry-wide start time would be misleading.
Should the first milestone be live in production? Only if your data, integration, review and release owners are ready. Otherwise agree a staging result and the evidence needed for a production decision.
How is an FDE different from a solutions engineer? Titles vary. Compare who works with users, who writes and deploys code, and who owns the system after the evaluation. Do not infer those responsibilities from the title alone.
Can an FDE work part-time? Yes, when the backlog and decision cadence fit agreed delivery days. Set response and incident coverage separately; a part-week delivery commitment does not imply continuous on-call support.
What should a candidate show when client code is private? A permitted, sanitized design review, a public project, a demonstration, or a paid work sample. Ask which outcomes are directly evidenced and which are illustrative.
Make the next decision concrete
Bring one workflow, approved examples, the systems involved and a named person who can accept the result. Use the scorecard to compare candidates, then agree a small first milestone with explicit access and handover. That process makes it easier to decide whether you need a pilot, recurring fractional capacity or a permanent team member.
If the embedded pilot model fits, discuss hiring me as a forward deployed engineer. I will review the scope and dependencies before proposing a delivery plan; the portfolio examples on that page show implementation patterns, not promised results for your environment.