The OpenAI FDE
interview

Practical implication for candidates: this is an applied role at a research company. Deep model expertise is not what is being screened. What is screened is whether you can take an API, a messy enterprise problem and a sceptical stakeholder, and produce something that works and gets used.

This matches the dividing question in FDE vs solutions engineer: who is accountable once it runs in production? I found no general Solutions Engineer posting on OpenAI’s board — the only ones are in Ads Solutions — so the architect role is the closest pre-sales-to-adoption equivalent. Expect more design and account strategy in that loop, and more code in the FDE one.

Twenty points; under fourteen would not advance in a competitive loop. For the timing method and a second spec, see the take-home playbook.

import json
from typing import Optional
from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

# 1. Structured output: the schema is the contract. Strict mode makes every field required,
#    so "optional" is spelled as nullable.
class Renewal(BaseModel):
    supplier: str
    renewal_date: Optional[str]
    notice_days: Optional[int]
    auto_renews: bool

r = client.responses.parse(model=MODEL, input=contract_text, text_format=Renewal)
renewal = r.output_parsed          # check for a refusal before trusting this; route it to a person

# 2. A tool round trip: each function_call is answered by a function_call_output, same call_id.
r = client.responses.create(model=MODEL, input=items, tools=TOOLS)
items += r.output
for item in r.output:
    if item.type == "function_call":
        result = run_tool(item.name, json.loads(item.arguments))
        items.append({"type": "function_call_output", "call_id": item.call_id,
                      "output": json.dumps(result)})
r = client.responses.create(model=MODEL, input=items, tools=TOOLS)

# 3. State on the server instead of resending the transcript every turn.
r = client.responses.create(model=MODEL, previous_response_id=r.id, input="And the notice period?")

The measurement point matters at OpenAI in particular: the FDE posting itself names eval-driven feedback as a success measure.⁷¹ Turning a fuzzy customer goal into a golden set, a calibrated judge and a gate is the skill that separates a strong answer from a plausible one. Evals for Client Work →

Two illustrative submissions to the supplier-contract brief above. A built a chat UI, tuned OCR and answers questions over all 400 contracts. B followed the “strong submission” list. Here is how each scores on the page’s 20-point rubric.

A did more work and scored 5. B did less and scored 18. Look at the verification row. Nine right out of ten sounds like 90%, but with only ten labels the honest range is wide: a 95% Wilson interval for 9 of 10 runs from about 60% to 98%. B earns its points by saying that out loud and proposing to grow the set, with procurement signing off the target. B still loses a point for not growing it, and that point is the cheapest fix left.

Here Time is a rough share of the five hours (illustrative), Space is the rubric points the work can earn, and Why is the reason to do it or cut it.

The kept rows add up to about 4 hours, which leaves an hour for whatever breaks. That buffer is what the page means when it says a well-scoped four-hour build beats an eight-hour one.