Interview Experience | Forward Deployed / AI | π₯π₯ | Palantir
2026 (late Sep to early Oct) Forward Deployed AI Engineer @ Palantir β New York β Virtual β 1 round | π Neutral | Medium
One virtual decomposition round for the Forward Deployed AI Engineer loop.
Decomposition
Prompt: a regional manufacturer gets hundreds of supplier emails a day about delays. Planners read them by hand and update a spreadsheet. They want "something with AI" so planners stop missing delays on critical parts. No schema, no success metric, no mention of which systems they already run.
I started with who actually touches the work. Planners act on alerts day to day. Buyers own the supplier relationship and care when a date changes again. The ops lead wants a weekly view of which plants are at risk, not every email. The spreadsheet sits between them today, and nobody trusts it fully because dates get overwritten without a trail.
MVP I pitched: classify each email as delay / not delay, extract part number, PO and new date into a fixed schema, match against open POs, and push only critical-part delays into a planner queue with the original email linked. Critical parts come from a simple flag on the BOM, not a fancy model. Anything the model cannot extract cleanly β missing PO, a date buried in a PDF attachment, output that is not valid JSON β goes to a manual-review bucket instead of being guessed. Non-delay mail stays out of the queue so planners are not flooded.
They asked how the extract step looks. I said one structured call with a JSON schema (part, PO, new_date, free-text reason), validate the fields, then try the PO against open orders. If the PO is missing or does not match, the row still lands in review with the raw email, not a fabricated PO. They pushed on whether the classifier and the extractor should be one model or two. I kept them separate so a bad extract does not force a re-classify, but I did not draw the retry path.
Midway the interviewer changed a constraint: some suppliers send the same delay three times with slightly different dates. I proposed keying on (supplier, PO, part) and keeping the latest date, with the history visible to the planner so they can see the supplier walked the date. Whether a later email that shortens the delay should reopen a closed alert was only sketched β I said reopen, but the exact state machine was not written down.
Last question was how they would know after a month that this is actually useful and not just a demo. I named missed-delay count (delays that hit production without an alert) and planner time per alert. Getting ground truth without asking planners to label every email did not get finished β I only said sample a week of mail and compare against what landed in the queue.