Hiring your first FDE: start with two people and a clear code boundary

Imagine you are the fifth engineer at an AI start-up. The demo works, an enterprise customer agrees to a trial, and then the proof-of-concept sits idle for six weeks because their data looks like nothing your team has ever tested. Sales calls every week, the product team is busy with the roadmap, and you are patching things in a hurry in the evenings.

That is almost exactly the moment Paraform, a recruiting marketplace, calls the clearest signal to hire a first FDE: a stalled proof-of-concept deal. It is not a sales problem. It is the engineering work that sits between the product and the customer’s reality, and nobody has been assigned to do it.

This piece is for two kinds of reader. If you are an engineering lead asked to build the team, here is the sequence to follow. If you want to become an FDE, here is how companies will assess you, and the questions you should ask them in return.

Which kind of FDE are you hiring?

Paraform says the most common reason an FDE search drags on is that the people involved cannot agree on what kind of FDE they are hiring. Rocketlane is blunter: FDEs come in five different shapes, and if you pick the wrong one for your deal size and pricing model, the numbers stop making sense.

The real scope of the work shows why. At Cursor, an engagement can be a gap analysis lasting a few weeks, or building an entire SDK over several months. Those two jobs need two different kinds of person.

Pricing pulls the role along with it too. Rocketlane argues that if you sell on outcomes, the FDEs become the team that delivers those outcomes directly to the customer, as part of a high-end sale.

So before you post the job, write a single page answering the five questions below. Have sales, product and engineering all read it. If the three give different answers, you have just found the reason the search will drag on.

Question	Example answer for the start-up above
What signal is making us hire?	A PoC with a logistics customer stalled on data integration
How long is a typical engagement?	A few weeks of integration, not months of building yet
How do we sell?	A trial with success criteria, then outcome-based pricing
Where does FDE code live?	A separate repo per customer, no direct changes to core
Who do FDEs report to?	The engineering lead, not the head of sales

The first hire writes the playbook, the second runs it

Recruiting from Scratch’s guide recommends starting with two FDEs. The first must be senior enough to define the deployment playbook; the second turns that playbook into everyday practice. The same guide warns that hiring more than about three FDEs before you have a repeatable playbook causes chaos.

What does “senior” mean here in concrete terms? Cursor looks for more than 5 years of software engineering, good system design intuition and experience working directly with customers.

Palantir’s job posting describes the work as operating in small teams with almost no supervision, and taking end-to-end ownership of important projects.

Paraform also warns that candidates who need a detailed specification before starting will struggle in the role. That is why the first hire cannot be a strong engineer who simply waits for tickets. At this stage there are no tickets.

Once the team has grown, Recruiting from Scratch aims for one FDE per strategic enterprise account. Treat that as a later destination, not a starting point.

Interview with a real working session

The test Recruiting from Scratch proposes is simple: ask candidates to build something small, then present it to a non-technical stakeholder sitting in the room, in place of the usual LeetCode or system design rounds. It checks exactly the two things an FDE has to do every week.

For the start-up above, a 90-minute session could be split as follows. In the first fifteen minutes, the interviewer plays the customer’s head of operations and describes the problem in the user’s language, for example “orders get duplicated whenever a driver loses signal”.

The candidate may ask as many questions as they like. The next hour goes on building a working version against a sample CSV file with deliberately planted errors.

In the final fifteen minutes, someone from sales or operations joins and listens to the candidate present. Score three things: did the candidate ask clarifying questions before writing code, did they spot the dirty rows on their own, and could they explain the limits of what they built without jargon?

A candidate who stops to ask “what is your definition of a duplicate order?” is usually worth more than the one who finishes fastest.

The boundary to draw before day one

Rocketlane advises drawing an architectural boundary between customer-specific builds and the core product before the first engagement. Without it, the first FDE will patch the core directly to hit a deadline, and after three customers you will have three different branches of the product.

In the example above, the rule might be: connectors and data-cleaning scripts live in each customer’s repo, and every change to core goes through review by the product team.

The reporting line matters just as much. Recruiting from Scratch argues that FDEs belong in engineering, because reporting to sales pulls them into pre-sales work.

Cursor takes a middle position: its VP in charge of FDEs places the team between engineering and product on one side and go-to-market on the other. Both approaches share one idea: FDEs must stay close to the code.

The mistakes that sink a first FDE team

The first mistake is expecting to hire quickly. Paraform recommends allowing 8 to 12 weeks for a full FDE search, most of it spent actively reaching out to candidates rather than waiting for applications. If you need someone for the stalled PoC next week, assign an engineer from the existing team temporarily while you keep hiring.

Advice such as search timelines or starting with two people should be read as the experience of recruiting practitioners, not as an industry standard.

The second mistake is hiring the third and fourth person before the first has finished the playbook. The third is having FDEs report to sales and then being surprised when they spend the whole week building demos. The fourth is harder to spot: hiring an excellent engineer who needs a clear spec, then putting them where no spec exists.

If you are the one being hired

Read the job posting carefully. If it states how long engagements last, who you report to and where your code will live, the company has done its homework. If not, ask exactly those three questions in the first interview.

On your CV, do not just write “worked with customers”. Describe a time you took on a problem with no spec, built the solution yourself, then explained it to a non-technical person and got them to adopt it. That is precisely the test the company will set you, so show that you have already passed it in real life.

A good FDE team does not start with a headcount. It starts with a stalled PoC, a page that defines the role clearly, and one person steady enough to turn the first deployment into the method for every one after it.