Suppose a wholesale company receives customer purchase orders every day. Before entering them as sales orders in its ERP, some item codes fail to match and some prices differ from the agreement. Staff open several screens to find the cause. If someone asks us to “use AI to check purchase orders,” where should we start, and how will we know whether what we build helps?
This is a hypothetical case to explain a way to prepare, not client work or the result of a system I have built. The answer might begin with talking to the people who receive orders, checking how reliable the source data is, and building a read-only exception list before deciding where AI belongs.
This kind of problem helps explain the Forward Deployed Engineer (FDE) role: an engineer who works closely with a customer’s team, understands its processes and constraints, builds or adapts software, and follows through until it works in the real environment.
The scope varies by company. Palantir describes work across data, architecture, and applications, while OpenAI and Anthropic emphasize bringing AI systems into customer use. The title does not mean prompt writing alone or one required skill set at every company. The cited job postings were checked on October 27, 2026 and may change.
Before writing code, find where the problem occurs
If staff say “purchase orders are often wrong,” I would break that down first. Does the error arise when the file arrives, when an item code is matched, when a price is calculated, or while someone waits for approval? Who sees it first, who can fix it, and where does unresolved work lose time? Those questions identify a starting point without guessing at the whole system.
For the hypothetical case, I would write a one-page problem brief: the path of one purchase order, which data is authoritative, common exceptions, who may decide, and what we should measure in the current process. Then I would ask the people doing the work to check whether that brief is accurate. If we cannot yet say what “wrong” means, starting with an AI model may make the work harder to check.
This is consistent with how OpenAI describes its own FDE work: learning the customer’s work and testing against real tasks beyond a demo until the system is used. I think the lesson applies to business systems more broadly, even when the chosen technology is not AI.
Build a small slice that shows both normal work and failure
For a preparation project based on purchase orders, I would use synthetic data, not put a former customer’s data in my portfolio. I would start with a screen for problematic orders, a mock ERP API, and rules to check item codes, prices, and user permissions. A failed check should explain why and identify who reviews it next.
The project should be inspectable from start to finish: how data arrives, which fields are mapped, what happens if the ERP is slow or sends malformed data, how failures are logged, and who owns the work after handoff. I would make this part read-only first. If I later add sales-order creation in the ERP, the server must enforce permissions, record who approved it, and prevent duplicate creation on a resubmitted or retried request. A human approval click alone is insufficient.
Skills to practice in this project include SQL for inspecting data, API design and authentication, event logs that make failures traceable, and tests for both normal operation and downstream outages. For Python versus TypeScript, inspect the languages used by the roles of interest and start with the one that lets you finish the project. No one technology stack is mandatory for every FDE role.
If applying for an AI-focused FDE role, I would then add help classifying exceptions or suggesting what a person should inspect. Keep a test set covering normal events, ambiguous data, and answers the system should refuse. Record when a recommendation is wrong and how a person corrects it. Text in a purchase order is external input; even if it says “approved,” it must not change permissions or cause a sales order to be created on its own. OpenAI discusses evaluation on representative work before live use, while Anthropic lists AI evaluation experience among desired qualifications for this role. This practice project is my suggestion, not a requirement from either company.
| What to demonstrate | Evidence in the practice project |
|---|---|
| Understand the work | A brief on the purchase-order flow, users, exceptions, and chosen acceptance criteria |
| Build a system | One small screen, a mock API, a field-mapping diagram, code, and repeatable run instructions |
| Handle failure | Test cases, read-access rules, failure logs, and a path to human review |
| Measure before claiming results | A way to record time and errors in the old process and a plan to compare after a trial, without unmeasured outcome figures |
| Hand off the work | An explanation of decisions, a system owner, monitoring instructions, and what must be fixed before real use |
This table is my suggested portfolio approach, not an evaluation rubric from any employer. A reader should be able to follow the reasoning and run the project. If someone new tries a synthetic order, record whether they succeed and where they get stuck. A video showing one successful screen flow does not answer questions about failure or ongoing support.
Turn existing experience into evidence
People who build ERP or customer systems may already know how to ask about requirements, connect APIs, migrate data, and fix problems on site. That experience matters. When discussing it with an FDE recruiter, show how you made decisions under constraints rather than only saying you led a large project.
I have worked for years with business software and with translating management needs into systems. If I prepare a portfolio for this role, I would choose work I can disclose, remove names and sensitive data, say which part I did, and explain choices I had to weigh: build a new function or change the existing process, let a system act or route the decision to a person. Work I have not done would be labeled as a practice project, never given invented client results.
A newcomer can use the same principle without an enterprise project history. Choose a small process, use synthetic data, ask someone else to try a task, and record where they struggle. The two applicants have different evidence to provide, but both should be able to explain their decisions and the limits of their project.
Prepare by reading the actual work in each posting
At some companies, an FDE role may overlap with solutions engineer, architect, or consultant work. I would read each posting with four questions: What must I build? How long do I stay with the work? How do we know people can use it? How do lessons get back to the product team? This is a way to read a posting, not a universal line between roles.
The Palantir posting emphasizes building with customer data and applications. OpenAI’s mentions understanding the problem, designing, coding, deploying, and checking whether people really use it. Anthropic’s describes Claude systems in customer environments and feeding reusable patterns back into shared practice. Those differences should shape which portfolio pieces and interview stories to use. Read experience, language, location, and travel requirements for each role; they can change.
For preparation, I would use 6 to 8 weeks as a flexible practice window, adjusted to my background and the project’s scope.
- Weeks 1–2: Read roles of interest, talk with people doing similar work, and write the problem and current-work measures.
- Weeks 3–4: Build the read-only data path and an exception screen that someone else can run.
- Weeks 5–6: Test failures and, if included, AI cases; ask someone else to use the project with synthetic data.
- Weeks 7–8: Record where the trial user gets stuck, write handoff instructions, and assemble the portfolio.
If I cannot finish in time, I should reduce the scope to one complete path. This schedule does not guarantee readiness or an application result.
Before sending a portfolio, ask someone else to open the project using its written instructions and find what goes wrong with one fictional purchase order when the ERP responds slowly. If they can rerun it, see why the system stopped, and know who should review it next, the portfolio supports a more useful engineering discussion than a screenshot of the happy path.
