How to Hire Your First Forward Deployed Engineer

Hire your first forward deployed engineer against a real deployment problem. The person must build production software, discover what a customer actually needs, and make sound delivery decisions when the requirements are incomplete. A job title or polished presentation gives you little evidence of those skills. A clear brief and a realistic, bounded assessment give you a better basis for the decision.

Write the job you need done

Describe the first customer or internal workflow, the systems the engineer will encounter, and the result they must reach. State whether they join before or after a sale, how much time they spend with users, and who owns the implementation after launch. Explain travel, support coverage, and access to core engineering before candidates commit to the process.

A small AI vendor might need someone who discovers the workflow, writes integrations, and delivers the first accepted production case. A consultancy might need someone who builds alongside a product manager and a client process owner. A corporate team might need someone who works across internal business units. These assignments require different domain experience and authority even when each employer uses the FDE title.

Set expectations for the first 90 days as outcomes you can review: a scoped deployment, a tested production release, an accepted handover, and evidence of which parts another engagement can reuse. Treat the time horizon as your planning choice, adjusted for the customer's access and approval process. Check whether you need an FDE before building a hiring process around work that belongs elsewhere.

Create an evidence-based scorecard

Agree on the scorecard before interviewing. For a first hire who will operate with limited supervision, require evidence of the following capabilities. Match technical depth to the deployment rather than demanding every fashionable tool.

1. Production engineering. They have built and operated software for real users. Ask about tests, permissions, releases, monitoring, and a failure they diagnosed. For AI work, ask how they evaluated incorrect outputs and controlled system actions.
2. Discovery. They can ask an operator about actual cases, find exceptions, and distinguish a requested tool from the business outcome. Look for evidence that customer input changed what they built.
3. Delivery judgement. They can cut scope, explain a trade-off, and identify a dependency before promising a date. They know when to stop a release or involve a specialist.
4. Communication. They can explain the same problem to an engineer and a business owner without hiding uncertainty. A written update should identify the decision, evidence, owner, and next step.
5. Reuse and handover. They can document an implementation, transfer it to another team, and identify which customer-specific work belongs in the shared product.

Set a minimum bar for each required capability. Don't let an impressive demo cancel out a serious weakness in production ownership. Ask interviewers to record observed behaviour and artifacts separately from their overall impression.

Look beyond the FDE title

Look at generalist software engineers who worked closely with customers, technical founders, implementation engineers, and consultants who shipped and operated systems. A solutions engineer may fit if their experience includes production code and delivery responsibility. Ask candidates to describe what they personally built, which decisions they owned, and who supported the result.

Current hiring briefs span different experience levels. OpenAI's Sydney role asks for five or more years of engineering or technical deployment experience with customer work. Crustdata's founding FDE role lists one or more years of production coding and customer-facing engineering. Those employer choices show why you should set seniority from your supervision and risk, rather than treating a single tenure requirement as the industry standard.

If the first hire will work alone in unfamiliar systems and negotiate technical scope with executives, test whether they have already handled comparable responsibility. If you can provide close engineering support and a bounded assignment, a less experienced candidate may succeed. Make that support explicit.

Test discovery before coding

Use a simulated customer conversation with synthetic records. For example, the client asks for an AI system to draft distributor quotes. Give the interviewer a few facts to reveal when asked: inconsistent product codes, an approval rule for discounts, missing source permissions, and a peak-period queue. Tell the candidate the exercise is about clarifying and scoping the work.

Watch whether they ask for recent cases, the current baseline, the cost of a wrong quote, and who can approve a change. A strong candidate makes the first release smaller when the evidence calls for it. They should explain which facts they still need, propose a way to test the result, and avoid promising production before resolving access and approval.

Then ask for a short written deployment note. It should state the outcome, scope, assumptions, dependencies, quality checks, and release owner. Compare it with the conversation: did the candidate hear the operator, or write a generic AI architecture that ignores the workflow?

Use a bounded paid work sample

Give candidates the same small repository, synthetic data, and acceptance criteria. Agree a time limit and pay for the work sample. A two- to four-hour exercise can ask them to repair an integration, add a test for an exception, and explain what they would need before deployment. This is a suggested format, not a claim that that duration fits every role.

Let candidates use the tools the job permits, including AI coding tools, and disclose those rules in advance. Ask them to explain and modify their result during review. Inspect how they verify generated code, handle missing data, and avoid logging sensitive values. The assessment should test ownership of the solution, including its limits.

Firecrawl's published interview process combines a technical customer scenario with a paid work trial. Lemma's process includes a project discussion and a paid trial. These are examples of employers assessing the work directly; choose a smaller simulated exercise if it gives you the evidence you need. Keep production access and live customer delivery out of an ordinary candidate assessment.

Make the decision from evidence

Have interviewers score their evidence before discussing candidates together. Use a simple scale with anchors: cannot yet do the task, can do it with support, or has demonstrated independent ownership. Check the same required capabilities for every candidate and explain where evidence is missing.

Look closely at candidates who talk confidently but cannot explain their own implementation, promise dates before checking dependencies, or dismiss operator feedback. During references, ask what they owned at launch, how they handled a scope conflict, and whether the next team could maintain their work. Offer candidates a realistic account of the role's pressures and the support they can expect.

Give the hire a supported first deployment

Start with one bounded workflow and a named business owner. Provide access to core engineers, a reviewer for security and permissions, and an account lead who handles commercial commitments. Give the FDE time to observe users and build an evaluation set before setting a launch date.

Review the first deployment through accepted outcomes, errors, support effort, and the receiving team's ability to operate it. Ask what the next customer can reuse and what still needs product work. A first FDE hire succeeds when the organisation gives them the authority and colleagues needed to deliver, alongside the engineering and customer skills you assessed.