FDE at Intercom: reading the job posting line by line, and preparing with an AI agent integration project

You open Intercom’s posting for a Forward Deployed Software Engineer in Dublin. One line states the job plainly: drive adoption of Fin by helping prospects take advantage of its AI capabilities.

Skim it and the sentence sounds like every AI company’s job ad. Read it slowly and each word points to a concrete situation at a customer’s site, and your portfolio should show you have handled that situation before.

Read the posting as a checklist of skills and you miss the most important part. What follows is a line-by-line reading that separates the work that is yours from the goals that belong to the product, plus a sample Fin-style project you can finish in a few evenings.

What does the posting actually ask you to do?

Fin is Intercom’s AI customer service agent. The FDE role revolves around getting it into real use: the Dublin posting calls that adoption, not a numerical target.

The word prospects is worth noticing. These are customers who have not signed a contract, so it is reasonable to infer that FDEs appear while a customer is still weighing whether Fin suits them.

Open.cx, a competitor and therefore a source to read with caution, says Fin also offers paid professional services. If that is right, large customers buy not just software but the time of a technical person who works alongside them.

The next line describes the shared goal: ensuring Fin delivers real, measurable business outcomes in complex real-world environments. That is a goal for the product, not a requirement for candidates, and the posting gives no figure.

Of Intercom’s three forward deployed postings, only the Forward Deployed Data Scientist role in San Francisco asks candidates for a track record of applying data science to real business problems with measurable results. That is a different role. The Staff FDE posting in Dublin adds a leadership layer: leading and mentoring both FDEs and Solutions Engineers.

Why “complex environments” is where you score

A customer service agent that only reads documentation can only answer generic questions. The most valuable questions, such as “where is my order” or “why was I charged twice”, need data that sits in each customer’s own systems, and the connection is usually an API.

The posting does not list this as a requirement. But if you want to show you understand the phrase “complex real-world environments”, no evidence is more concrete than an integration that runs on messy data and comes with measurements.

Even model selection at Intercom went through testing. According to AWS’s case study page, Intercom chose Anthropic’s Claude after extensive testing found it gave the best results for its needs. Your customers will want the same kind of evidence, not a feeling.

Sample project: “Where is my order?”

Picture a customer that is a retailer with an internal orders API. You need a small function the agent can call when a user asks about an order. A version that “works” takes ten minutes; a version solid enough to hand to a customer looks like this:

import re
import httpx

ORDER_API = "https://orders.internal.example.com/v1/orders"

def lookup_order(raw_order_id: str, customer_email: str, token: str) -> dict:
    order_id = re.sub(r"[^A-Za-z0-9]", "", raw_order_id)  # "#A-1029" -> "A1029"
    if not order_id or len(order_id) > 20:
        return {"ok": False, "reason": "invalid_order_id"}
    try:
        r = httpx.get(f"{ORDER_API}/{order_id}",
                      headers={"Authorization": f"Bearer {token}"},
                      timeout=3.0)
    except httpx.TimeoutException:
        return {"ok": False, "reason": "upstream_timeout"}
    except httpx.HTTPError:
        return {"ok": False, "reason": "upstream_error"}  # DNS, connection reset...
    if r.status_code == 404:
        return {"ok": False, "reason": "not_found"}
    if r.status_code >= 400:
        return {"ok": False, "reason": "upstream_error"}  # 401, 500, 503...
    try:
        order = r.json()
    except ValueError:
        return {"ok": False, "reason": "upstream_error"}
    if order.get("email", "").lower() != customer_email.lower():
        return {"ok": False, "reason": "not_owner"}  # never leak someone else's order
    return {"ok": True, "status": order.get("status"),
            "eta": order.get("eta"), "carrier": order.get("carrier")}

In an interview, be ready to explain three decisions in this code. It checks who owns the order, so the agent never reads someone else’s order to the person asking.

It returns only the few fields needed, because the agent does not need, and should not see, addresses or payment details. Every failure, including network errors and 5xx errors from the API, returns a clear reason instead of crashing the function, so the agent knows when to ask again and when to hand over to a human.

Finishing the code gets you halfway. Take 30 order questions, label the correct outcome for each and run the test. Suppose 18 of 30 are resolved without a human: 60%.

The most valuable step is reading the 12 failures and sorting them by cause. In this example, seven came from users typing IDs such as “#A-1029”, two from API timeouts and three from questions outside the scope of orders.

The largest group tells you what to fix first: one line at the top of the function that strips stray characters from the order ID. The next run reaches 25 of 30, or 83%. The remaining five belong to the other two groups, and they become the to-do list for the next round, already in order.

Which numbers should you bring to a customer?

Customers will ask what percentage Fin resolves, and the public answer varies by source. Anthropic’s case study page says 51% out of the box, with no customisation. Intercom and AWS report an average of 56% within the first 30 days of deployment.

Open.cx cites a more recent figure: 67% on average across more than 7,000 customers, rising about 1% a month. WorkOS reports Fin handling up to 86% of conversations, but only in some deployments; WorkOS itself notes that typical deployments come in lower, though 50-70% is common.

These are figures from the vendor or third parties, not promises to any particular customer. So the only honest answer to “what will it be for us” is to run an eval on their own conversations, like the 30-question exercise above.

Turning each line into evidence

Line in the posting	The question behind it	Evidence to have
Drive adoption of Fin	Can you turn a demo into real use?	Before-and-after measurements
Help prospects take advantage of Fin	Can you talk to customers who have not signed?	A demo with an explanation of its limits for people who do not code
Measurable outcomes in complex environments	Does it work on real, messy data?	An integration repo with auth, timeouts, error handling and an eval set
Mentor FDEs and Solutions Engineers (Staff)	Do you make the whole team better?	A story about someone you coached
Measurable results (Data Scientist)	Do you have real numbers?	A query that computes the resolution rate

On a CV, a good bullet point has all three parts: the system you connected, the hard decision and the number. Based on the project above: “Built an order lookup function for a support agent with an order-ownership check; the self-resolution rate on a 30-conversation eval set rose from 18 to 25.” The pattern works at any company hiring FDEs.

Mistakes that sink strong candidates

The most common mistake is drilling algorithm problems and skipping integration, when the whole role is built around getting customers to actually use the product. The next is bringing a polished demo with no numbers to prove it works.

A subtler mistake is quoting vendor figures as a guarantee. Telling a customer “Fin resolves 56%” without mentioning that it is a self-reported average is the fastest way to lose their trust when their real number comes in lower.

Staff-level candidates tend to fall into telling stories about doing everything themselves. The Staff posting stresses leading and mentoring, so a story about an FDE or Solutions Engineer you coached can be more persuasive than ten features you built alone. Candidates on the data scientist track should bring how they measured outcomes, not just notebooks full of charts.

This week’s exercise

Pick a public API with per-user data, such as orders, tickets or appointments, and write a lookup function that includes all three decisions above. Put it behind a simple agent, run 30 questions and record the cause of every failure.

What follows you into the interview is not the repo. It is the moment you can say something like “7 of the 12 failures came from how users typed the order ID”, and only someone who has done the work can say that.