The Case Study and Presentation
Prepare a deployment case that you can present, reproduce, and defend under changing requirements. Extract the customer’s workflow, required artifact, tool permissions, presentation constraints, and unresolved decisions before choosing a scope. Build a narrow, operator-reviewed demonstration, document setup and expected behavior, and distinguish supplied evidence from results you actually inspected. Present customer, problem, build, proof, and handoff with clear limits. Keep stale-evidence failures visible, require repaired controls and agreed owners before a pilot, and treat customer messaging as a separate action phase with approval, authorization, deduplication, receipts, reconciliation, explicit revised costs, and acceptance gates.
The R7 task in the previous lesson came with a function contract. A deployment case comes with a customer, and nobody tells you what to build. OpenAI’s interview guide lists take-home projects among its possible assessment formats, and the FDE take-home is typically a deployment case that you then present and defend live. The hard part is choosing a workflow, an artifact, and the proof that would justify it. A narrow, runnable submission gives the interviewer something concrete to inspect and gives you a boundary to defend when the request changes.
What should you pull out of the brief?
OpenAI’s FDE role description covers discovery, technical scoping, system design, build, and production rollout alongside customer engineering and domain teams. It measures success through adoption, workflow impact, and eval-driven feedback, and it asks FDEs to sequence work and trade scope, speed, and quality to protect delivery. A take-home case is a small window onto those same decisions.
Before you choose an artifact, find five things in the brief: the workflow to improve and the people who use it; the required submission, whether code, a document, a recording, or something else; which tools and kinds of help are allowed; the presentation’s format, audience, and time; and the open requirements whose answers could change the design or the proof. Your actual assessment instructions decide the artifact, format, tools, and time. If something is unclear, ask your recruiter before you start.
What does Northstar want?
Northstar Equipment Services wants faster service-request handling and a demonstration a reviewer can reproduce. Today, operators read incoming notes, look up the service records they’re allowed to see, classify urgency, draft a response, and decide whether to escalate or close the request. Northstar wants operators to keep that final decision.
Before committing to a design, ask the questions whose answers would change it:
Access: Which operators and service identities may read which records? If nobody can answer, the demonstration runs on test records only.
Error cost: What happens if an urgent request is treated as routine, or a draft relies on an outdated record? This tells you which mistakes need their own release gate.
Review: What must an operator see before accepting or correcting a draft? This shapes the output and the screen.
Execution: What can the reviewer run, and which dependencies are allowed? This shapes setup and reproducibility.
Operation: Who defines labels, reviews outputs, maintains access, and supports a pilot?
Write down every unanswered question as an assumption. “Customer engineering will own identity configuration” is a proposal until customer engineering agrees to it.
What should you build?
Choose an operator-reviewed, read-only triage draft. It reads a record the operator is entitled to see, ...