The OpenAI FDE interview: a semantic search take-home, a 60-minute review and an AI-enabled coding round

You open the recruiter’s email and read the brief: build a semantic search system over Amazon product data for ChatGPT to use. One OpenAI FDE candidate recounted on Aced that they received exactly this brief and had a week to build something that actually ran.

That is one person’s account, not a standard brief, and the sources describing the process do not fully agree. But Aced’s guide (Aced was formerly Exponent) lands on one point worth keeping: treat the take-home as a product delivered to a real customer.

The brief is a small contract, not an exam

The first thing to pin down is the time limit, because the sources differ. Aced’s guide says you have about a week to submit working code, a running application and a video walkthrough. Gaijineer and The Forward Deployed describe a take-home of about five hours, building something real on OpenAI’s API, with a video.

Even Aced gives two figures: its overview of FDE interviews, the source for the 60-minute review described below, puts the take-home at about five hours, while its OpenAI-specific guide says about a week. The process may have changed, or teams may run it differently, so do not treat either number as the rule.

The practical advice, then, is to ask the recruiter exactly what the deadline is and what you need to submit, just as you would agree scope with a customer before starting work. Final Round AI describes the video as presenting the application as if you were talking to a customer.

The grading criteria matter more than any technical trick. The candidate who received the Amazon brief said scoring leaned towards explaining decisions and tying them to customer needs.

Final Round AI is blunter: engineers who cannot clearly explain what they built do not advance. An impressive retrieval trick will not rescue a submission the grader cannot run or cannot follow.

Start from what the user types, not from an architecture diagram

Perspective AI advises starting from the customer’s job-to-be-done rather than from a reference architecture. Imagine you have received the Amazon brief. Instead of opening a notebook straight away, write down three queries a ChatGPT user might type: “noise-cancelling headphones under $100 for frequent flyers”, “gift for a 5-year-old who loves dinosaurs”, “iPhone 15 case that doesn’t turn yellow”.

These three queries immediately reveal two kinds of signal. The semantic part (“frequent flyers”, “loves dinosaurs”) suits embeddings. The hard constraints (“under $100”, “iPhone 15”) should go through a metadata filter, because embeddings are poor at comparing numbers, and this is exactly the kind of decision you will have to explain later.

Next comes how to represent a product. A record typically has a title, brand, category, a few lines of feature bullets and possibly reviews. The simplest option that is still defensible is one short text per product, with price and category kept as filter fields:

def product_to_text(p):
    # One document per product; price stays structured for filtering
    lines = [p["title"], f"Brand: {p['brand']}", f"Category: {p['category']}"]
    lines += p.get("bullets", [])[:5]
    return "\n".join(lines)

def search(query, max_price=None, k=5):
    q_vec = embed(query)
    candidates = [p for p in products if max_price is None or p["price"] <= max_price]
    return top_k_by_cosine(q_vec, candidates, k)

This is where chunking strategy comes in. If you split long descriptions into several chunks, you have to merge results back to the product level. Without merging, the same item can take three of the top five slots.

Adding reviews brings in everyday language such as “wore them the whole flight without sore ears”, but also noise. Either choice is fine, as long as you can say why.

Finally, measure. Suppose you write 30 queries yourself, each with the products that count as correct noted in advance. If 21 queries have at least one correct product in the top five, hit@5 is 70%, and that makes a good opening line for the review: “The first version hit 70%. Here is how far adding a price filter took it, and why.”

The decision log is what you bring to the review

Aced describes a 60-minute session that combines presenting your work with deep technical questioning. You explain your design choices, then answer follow-up questions on RAG, on the trade-off between fine-tuning and prompting, and on guardrails and evals.

Aced’s guide adds that interviewers check whether the design starts from what the customer actually needs.

A common question in this session, according to Aced, is: why did you choose this approach, and where did you decide not to go another way? The best preparation is a decision log that records which user need each technical choice came from. A template might look like this:

Decision	Rejected option	Reason, in terms of user need	When to change
One document per product	Split descriptions into multiple chunks	Users need a list of distinct products, not passages of text	When long descriptions dilute the embedding
Price as a hard filter	Put price in the embedded text	“Under $100” is a constraint, not a hint	Almost never
No reviews yet	Append reviews to the document	Keep the first version simple; measure before adding	When evals show misses on everyday-language queries

The last column is the most valuable. When asked “what if the customer had ten million products?”, you do not have to improvise, because you have already written down the conditions that would change your mind. Add a few rows for the topics Aced lists, such as why you do not yet need fine-tuning and which guardrail blocks results with the wrong price.

The AI-enabled coding round: what is graded is how you use the tools

The candidate who received the Amazon brief mentioned only briefly that even the coding screen had AI enabled, without describing the rules in detail. Aced’s guide is more explicit: AI tools are allowed, so share your screen and talk through your reasoning as you work.

When every candidate has the same tools, the only thing the interviewer can observe is how you think. Working out loud might sound like this:

“Before letting the AI write anything, one thing to settle: can the input be an empty array? Now I’ll ask it for a first version… This line uses sort, so it’s n log n, which is acceptable for this problem. I’ll add a test for duplicate elements, because that’s an easy case to miss.”

The advice here is to let the interviewer see you read AI-generated code carefully, write your own tests and catch bugs before running it. Pasting the output and waiting in silence wastes the chance to show how you think.

Mistakes that sink otherwise good submissions

One easy mistake is optimising the wrong thing: spending three days on an elaborate reranker while having no README, no one-line run command and no eval set. If you treat this as a product delivered to a customer, as Aced advises, that submission is weaker than a simple system with tests and measurements.

Another is a video walkthrough that opens with an architecture diagram. Open with the user’s query, show the results, and only then explain what sits underneath. Never answer a “why” question with “because the tutorial did it that way”; the decision log exists so you never have to say that.

This preparation is not wasted even if you never interview at OpenAI. A search project with evals, a decision log and a five-minute video is a portfolio piece that fits any FDE role.

On your CV, write it as one line with a number and a hypothetical customer, for example “semantic search over 200 products, hit@5 raised from 70% to X% with a price filter”, rather than just listing “RAG, embeddings”.

This week’s exercise: redo the Amazon brief in about five hours, the benchmark described by Gaijineer, The Forward Deployed and Aced’s overview, rather than the week that candidate was given. Then ask a friend to play the customer and question you for exactly 60 minutes, and write any question you cannot answer straight into the “when to change” column.