Forward Deployed Engineer Interview Questions and Answers

Answer

This is a screening question for a realistic model of the role, not enthusiasm. Weak answers romanticise it ('I love talking to customers and building AI'). Strong answers show you understand the trade you are making: you give up deep ownership of one codebase and a predictable roadmap, and in exchange you get end-to-end ownership of outcomes at a customer, extreme variety, and direct exposure to how software creates or destroys business value.

Describe the week honestly: a Monday call where the customer has changed their priorities again, two days of building against an internal API that is documented nowhere, a demo on Thursday you prepared for on Wednesday night, and a Friday spent writing an eval so you can prove the thing works. Mention travel or on-site time if the company does it (Palantir historically expected heavy embedding; AI-lab FDE roles vary between on-site sprints and remote embedding). Then connect it to your evidence: times you enjoyed being the only engineer responsible for a result, or shipped under ambiguity and liked it.

The interviewer is evaluating three things: do you know this is a delivery job, not a research job; will you burn out when the customer is difficult; and are you running toward the role rather than away from a SWE job you did not enjoy. Close with why now: the 2025-26 wave means FDEs are where model capability meets enterprise reality, and you want to be at that junction while the playbook is still being written.

Answer

This is the core FDE behavioral question, and interviewers at Palantir-style and AI-lab loops ask a version of it in almost every round. Structure it with STAR but weight the S and R heavily. Situation: pick a project where you genuinely owned the outcome, not a ticket inside someone else's project.

Ideal examples: an internal tool you proposed, built, and drove adoption for; a client integration you scoped and delivered solo; a migration where you owned the cutover decision. Task: state what 'done' meant in business terms (hours saved, revenue unblocked, error rate reduced), because FDEs are measured on outcomes, not merged PRs. Action: this is where you demonstrate range.

Talk about the non-coding work: getting access, interviewing the people who would use it, cutting scope when the deadline moved, deciding what not to build. Interviewers specifically listen for moments where you did something outside your job description because the outcome required it. Result: give a number, then say what happened after launch, adoption, maintenance, what you would redo.

A common failure mode is picking a technically impressive project where a PM absorbed all the ambiguity for you; that reads as strong SWE, weak FDE. Another is claiming solo credit for team work, which experienced interviewers detect quickly through follow-up probing ('who wrote the deployment pipeline?'). If your best example is small, that is fine: a modest project you truly owned end to end beats a large one where you owned a slice. Finish with what the project taught you about the gap between shipping code and delivering an outcome.

Answer

FDE work is permanently spec-free, so the interviewer wants your method, not just a war story. A strong answer has a repeatable loop in it. First, you compressed the ambiguity: you found the person who feels the pain (not the person who requested the project) and watched them work, or got the rawest artifact available, an export of the real data, a recording of the real process, the spreadsheet the team secretly runs on.

Second, you picked a thin vertical slice that touches every risky layer once, real data in, real output to a real user, rather than building horizontally (auth, then schema, then UI) and discovering the fatal problem in week four. Third, you shipped something visibly imperfect fast, because a stakeholder correcting your wrong prototype is the fastest spec-writing machine that exists; people who cannot articulate requirements can always tell you what is wrong with a concrete thing. Then narrate the correction cycle: what you got wrong, how quickly you found out, what you changed.

Interviewers evaluate whether ambiguity makes you decisive or paralysed, whether you de-risk by sequencing (hardest assumption first) and whether you treat early wrongness as information rather than failure. A red flag they are watching for: candidates who resolved ambiguity by escalating it, asking their manager or the customer to just decide. FDEs are hired to be the person who absorbs that ambiguity and comes back with a proposal.

Answer

An FDE at Databricks might do insurance claims in Q1, steel manufacturing in Q2, and hospital revenue cycle in Q3, so domain-ramp speed is a hiring criterion in its own right. Pick a genuinely foreign domain (logistics, lending, pathology labs, GST compliance) and give a concrete timeline: 'I had ten days before the first workshop.' Then lay out a method, because that is what is being graded.

Strong methods share a shape: start from the money and the artifacts, not the textbook. Read the actual documents the business runs on (a claim form, a bill of lading, a rate card), map the end-to-end flow of one real transaction, and build a glossary of the twenty terms insiders use, because using their vocabulary correctly in week one buys enormous trust. Interview the operators, not just the managers, and ask 'what do you do when the system is wrong', since exception paths are where the real domain lives.

In 2026 you should also mention using LLMs as a ramp accelerator, generating a primer, interrogating it, then verifying against the customer's reality, while being explicit that you verified, because confidently repeating a model hallucination to a domain expert is a trust-destroying failure mode. Close with proof it worked: a moment where domain fluency changed a technical decision, for example realising that 'claim date' meant three different dates in three systems, which changed your whole data model. The interviewer is evaluating curiosity, method, and humility in front of domain experts, the exact posture FDEs need on site.

Answer

The interviewer is checking whether you have an explicit prioritisation model or just absorb pressure until the loudest voice wins. A strong answer has three layers. First, an ordering principle: what does the engagement actually get judged on?

Most enterprise engagements have one or two success criteria that decide renewal or expansion, and workstreams that feed those outrank everything, including workstreams whose stakeholder shouts loudest. Second, a risk lens: anything blocking other people (an access request with a three-week SLA, a security review, a data export another team must schedule) gets started first regardless of its own priority, because its latency is not under your control. Deadlines you cannot move, a board demo, a compliance date, also jump the queue.

Third, and this is what separates senior answers, you make the priority call visible instead of private. Send the champion and your own lead a short note: here are the five streams, here is the order I am executing and why, here is what will not get touched this week, object by Tuesday. That converts a political problem into a document, gives stakeholders a legitimate place to escalate, and protects you when someone claims surprise in week three.

Mention the failure mode you are avoiding: context-switching across all five to keep everyone slightly happy, which is how embedded engineers end a quarter with five 80 percent-done streams and zero delivered outcomes. One or two streams finished and demoed beats five in progress, every time.

Answer

This role-play appears constantly in FDE loops because it is the job: converting an executive slogan into a scoped, buildable engagement. Do not start by proposing architecture. Start by decomposing the process: ask them to walk one real claim through the pipeline end to end, intake, triage, document collection, adjudication, payout, appeals, and for each stage get volume, headcount, cycle time, and error cost.

Somewhere in that walk the actual pain surfaces, usually as a side comment ('the team spends most of its day re-keying data from PDFs'). Next, separate the stages by AI suitability: high-volume, pattern-heavy, tolerant-of-review steps (document extraction, triage routing, correspondence drafting) are strong candidates; judgment calls with regulatory exposure (final adjudication, fraud accusations) are not, at least not without a human approval step, and saying so out loud builds more credibility than any demo. Then pick one wedge: the narrowest slice with measurable value and available data, and define its success metric with them in the room, for example 'reduce average document-processing time on motor claims from four days to one, measured on next month's intake'.

Close the session with concrete asks: a sample of real (or redacted) claim documents, one operator you can shadow, and a named decision-maker. What the interviewer evaluates: whether you resist jumping to solutions, whether you quantify, whether you push back on AI-washing the hard parts, and whether you leave the room with commitments rather than vibes. A version of this answer works for any 'we want AI in X' prompt, so practise the decomposition reflex, not the insurance specifics.

Answer

The first two weeks decide whether the next two quarters are smooth or adversarial, and interviewers want a deliberate plan, not 'set up my laptop and read the wiki'. Week one is about people and access in parallel. People: map the three roles that matter, the economic buyer who pays, the champion who staked reputation on you, and the daily operators whose workflow you will change, and meet all three.

Operators matter most and are met last by weak FDEs; shadow them for at least half a day and write down every workaround and spreadsheet they use, because that shadow work is where your real backlog comes from. Access: file every request on day one, VPN, repo, database read replica, SSO, security training, because enterprise access queues run one to three weeks and they, not your skills, are the usual reason month one produces nothing. Week two is about data reality and a first artifact.

Pull real data and profile it yourself: row counts, null rates, duplicate keys, how yesterday's numbers disagree with the dashboard everyone trusts. Every enterprise dataset is worse than described, and discovering that in week two instead of week eight changes the whole engagement plan. Then ship one small visible thing, a data-quality report, a working query, a thin prototype, and demo it to the champion.

It proves motion, tests the demo path, and starts the trust flywheel. What is being evaluated: whether you treat embedding as a discipline with a playbook, and whether you understand that early trust and early access are engineering deliverables.

Answer

Two skills are being tested: translating LLM behaviour for a non-technical audience without condescension, and knowing the engineering controls. The explanation: avoid 'it is probabilistic' as a full sentence and stop there; that reads as an excuse. A framing that works with operations leaders: the system generates answers rather than looking them up, closer to a skilled new hire than a database, so phrasing, context, and sampling can shift the output.

Then immediately pivot to what you control, because an ops leader's real question is not 'why' but 'can I rely on this'. The controls, in the order you would apply them: set temperature to zero or near-zero for workflows where consistency matters more than creativity; pin the model version rather than floating on 'latest', since provider model updates are a real and under-appreciated source of day-to-day drift; ground answers in retrieved documents so the variable part is phrasing rather than facts; and constrain output to a schema so downstream systems see stable structure even when wording varies. Be honest about the residual: even at temperature zero, providers do not guarantee bitwise-identical outputs, and a model version bump can change behaviour, which is why you also propose a regression eval that runs the customer's own critical questions against any model or prompt change before it ships.

That last move usually lands hardest, because it reframes variability from a mysterious model property into a managed release process, which is language an operations leader already trusts. Close by agreeing with them on which workflows genuinely need consistency and which just need correctness, because the engineering cost of the two is different.

Answer

Retrieval-augmented generation separates knowledge from reasoning: instead of hoping the model memorised the customer's documents, you store those documents in a searchable index, retrieve the handful of passages relevant to each query, and put them in the prompt so the model answers from evidence it can cite. For a head of engineering, the architectural framing lands well: the model is a stateless reasoning engine; RAG gives it a read path into your data at inference time. Choose RAG over fine-tuning when the goal is knowledge access, which covers most enterprise asks: policy Q&A, support over product docs, contract lookup.

The reasons are operational, and this is what interviewers listen for. Freshness: when a document changes, you re-index in minutes; a fine-tune is stale until retrained. Access control: retrieval can filter by the querying user's permissions, while fine-tuned weights leak everything to everyone, which is usually disqualifying on its own in an enterprise.

Attribution: RAG answers cite sources, which is how you earn user trust and debug wrong answers. Cost and iteration speed: changing chunking or prompts takes hours, not training runs. Fine-tuning earns its place for a different problem class: teaching behaviour rather than facts, a consistent voice, a niche output format, a classification skill, or distilling a large model's behaviour into a smaller, cheaper one at high volume. The senior-sounding closer: the techniques compose, and the honest default in 2026 is a strong base model plus RAG plus good prompting, with fine-tuning added only when evals show a behaviour gap that prompting cannot close.

Answer

Give a cheap-to-expensive ladder and a diagnostic for climbing it, because the framework's point is stopping at the lowest rung that passes evals. Rung one, prompting: always first. A well-structured prompt with role, rules, and three to five worked examples solves a surprising share of enterprise tasks, iterates in minutes, and costs nothing beyond tokens.

Exhaust this before anything else; most 'we need to fine-tune' requests die here. Rung two, RAG: climb when the failure mode is missing or stale knowledge, the model does not know your policies, prices, or contracts. No amount of prompting fixes absent facts.

Rung three, fine-tuning: climb when the failure mode is behaviour, not knowledge, the model knows enough but will not reliably produce your format, tone, or judgment even with few-shot examples, or when you need a small model to match a big one on a narrow task to cut cost and latency at volume. The diagnostic that ties it together: build a small eval set (even 50 real examples) and read the failures. Wrong facts point to RAG; right facts delivered wrongly point to prompting first, then fine-tuning; too slow or too expensive at target quality points to distillation via fine-tuning.

Also name the anti-patterns, since customers arrive holding them: fine-tuning to inject documents (poor retention, no access control, instant staleness) and RAG for style problems (retrieval cannot fix tone). Emphasise that the ladder is not exclusive; mature systems often use all three, but each addition must be justified by a measured failure, not by architectural ambition.

Answer

Evals are the FDE's core instrument, so 'the customer has nothing' cannot mean 'we ship on vibes'. Lay out a bootstrap sequence. First, mine the exhaust of the existing process: support tickets with their resolutions, past documents with the values a human eventually extracted, emails a team actually sent.

Almost every enterprise workflow you are automating has been done manually for years, and those historical pairs are your seed inputs and reference outputs; 50 to 100 of them beats zero, and beats 5,000 synthetic ones. Second, run a labelling session with the customer's own experts, one hour with two senior operators grading model outputs on twenty real cases, arguing where they disagree. The disagreements are gold: they surface unstated rules ('we never promise refund timelines in writing') that become both prompt rules and rubric lines.

Third, synthesise the hard tail with an LLM: edge cases, adversarial inputs, out-of-scope questions that must be refused, then human-review every synthetic case before it enters the set, because unreviewed synthetic evals encode the generator's blind spots as your quality bar. Structure the set from day one: each case gets an input, a reference or rubric, a category tag, and a difficulty tag, so you can later say 'the regression is only in multi-invoice cases'. Twenty well-chosen cases wired into CI on day five is worth more than a five-hundred-case set delivered in month three, and the discipline of grading against it turns every future prompt or model change from an argument into a diff. The meta-point interviewers want: you treat eval-building as customer discovery, the rubric conversation teaches you the domain faster than any workshop.

Answer

Answer as a layered defence, because no single fix eliminates hallucination and interviewers are testing whether you know that. Layer one, grounding: policy answers must come from retrieved policy text, not model memory. If the assistant was already RAG-backed, the failure is more specific and more fixable: either retrieval returned nothing relevant and the model filled the gap (fix: retrieval quality, and an explicit instruction plus behavioural test that no-evidence means 'I could not find this' rather than a guess), or retrieval returned the right passage and the model contradicted it (fix: prompt restructuring to quote-then-answer, a stronger model, or a groundedness check).

Layer two, output-side verification: for high-stakes domains add a checking pass, a second model call that verifies each claim in the draft answer against the retrieved passages and flags unsupported ones. It roughly doubles cost per answer, which is a fine trade on policy questions and a bad one on chit-chat, so scope it by route. Layer three, product design: citations on every answer so users can verify, confidence-based deflection to a human channel, and wording that distinguishes 'per policy doc X' from general talk.

Layer four, process: add this exact failure to the eval set so the fix is provable and the regression is guarded forever, and set up sampling review of production answers so the next one is found by you, not by an angry employee. Close with the honest framing you give the customer: the goal is not a system that never errs, it is a system whose errors are visible, bounded, cheap to correct, and decreasing, that framing survives contact with reality, and 'we fixed it, it cannot happen again' does not.

Answer

Structured output is the workhorse of enterprise LLM integration, extraction, routing, and enrichment all reduce to it, so interviewers expect a crisp production answer. The modern approach has three layers. First, use the provider's native structured-output mechanism rather than prompt-begging: OpenAI's structured outputs with a JSON schema, Anthropic's tool-use pattern where the schema is the tool signature, or constrained decoding (outlines, guided JSON in vLLM) for self-hosted models.

These constrain generation so the output parses by construction, which kills the whole regex-and-pray class of bugs. Second, validate semantically anyway: schema conformance is not correctness. A syntactically perfect response can still contain an invoice total that fails the checksum against line items, a date in the wrong century from an ambiguous scan, or an enum the model chose because it had to choose something.

Pydantic models with field validators are the standard pattern; validation failures either trigger a bounded retry with the error message fed back, or route to a review queue. Third, design the schema defensively: make uncertain fields nullable and instruct the model that null beats guessing; add a confidence or evidence field for values you will audit; keep enums closed with an explicit 'other'. Mention the operational edge: log every parse or validation failure with the raw output, because those failures cluster (a new document template, a locale change) and are your early-warning system for input drift. This question separates people who have shipped LLM integrations from people who have read about them; the shipped ones always talk about validation and failure handling, not just the happy path.

from pydantic import BaseModel, field_validator
from openai import OpenAI

class Invoice(BaseModel):
    vendor_name: str
    invoice_number: str
    total_amount: float | None  # null beats guessing
    currency: str
    line_item_sum: float | None

    @field_validator("currency")
    @classmethod
    def currency_code(cls, v: str) -> str:
        if len(v) != 3 or not v.isalpha():
            raise ValueError("expected ISO 4217 code")
        return v.upper()

client = OpenAI()

def extract(document_text: str, retries: int = 2) -> Invoice:
    err = ""
    for _ in range(retries + 1):
        # older openai-python SDKs: client.beta.chat.completions.parse
        resp = client.chat.completions.parse(
            model="gpt-5",
            messages=[
                {"role": "system", "content": "Extract invoice fields. "
                 "Use null when a value is not clearly present." + err},
                {"role": "user", "content": document_text},
            ],
            response_format=Invoice,
        )
        inv = resp.choices[0].message.parsed
        if inv.total_amount is None or inv.line_item_sum is None or \
           abs(inv.total_amount - inv.line_item_sum) < 0.01:
            return inv
        err = f" Previous attempt failed: total != line sum ({inv.total_amount})."
    raise ValueError("extraction failed cross-check; route to review queue")

Answer

Order matters here; interviewers are checking that you reach for measurement and cheap wins before architecture. Lever zero: measure per-route. Get cost and latency per workflow, not per account, because in most deployments two or three routes drive 80 percent of spend, and optimising the wrong route wastes a month.

Lever one: prompt hygiene. Enterprise prompts accrete; a 6,000-token system prompt with three obsolete instruction blocks, repeated on every call, is common and free to fix. Trim context, deduplicate retrieved chunks, cap retrieval depth to what evals say you need.

Lever two: model right-sizing per route. Not every step needs the frontier model; classification, routing, and simple extraction usually hold quality on a model a tier or two down, verify with your eval set, never by eyeball. Lever three: caching.

Provider-side prompt caching for the static prefix (system prompt plus few-shot examples) cuts input cost dramatically on high-QPS routes, and response-level caching handles genuinely repeated queries. Lever four: latency-specific moves that cost nothing: stream tokens so perceived latency drops even when total time does not, parallelise independent calls, and cut maximum output length, since generation time scales with output tokens. Lever five, only after the above: architectural changes, distilling a fine-tuned small model for the highest-volume narrow route, or batching offline work into async queues where the provider's batch tier is half price. Wrap it in the FDE framing: you present the customer a cost-quality-latency curve with options, because 'cheaper but two points worse on your eval' is a business decision they should make, not one you make silently.

Answer

This is the idempotency question in FDE clothing, and it is asked because enterprise integrations live in exactly this world: flaky networks, aggressive retry policies you do not control, and financial data where double-processing is a customer-trust incident. The core design: make every ingestion request carry an idempotency key, and make processing conditional on that key never having been seen. For file-level ingestion, derive the key from content, a hash of the file bytes plus the source system identifier, rather than trusting filenames or timestamps, because upstream systems re-export 'the same' file with new names constantly.

Record the key in a processed-files table with a unique constraint, and insert it in the same database transaction as the ingested rows, so the claim 'this file is processed' and the actual rows commit or roll back together; checking a flag first and writing second is the classic race that fails exactly when the retry storm hits. Return success for an already-seen key (with the original result) instead of an error, so the upstream retry loop terminates peacefully. Go one level deeper for partial-failure handling: if a 10,000-row file dies at row 7,000, you want either transactional all-or-nothing (clean, fine at this scale) or row-level idempotency keys so a re-run skips completed rows.

Mention the operational sidecar: a reconciliation report comparing source row counts to ingested counts per file, because silent drops are worse than loud duplicates. Strong candidates also note what they ask the customer: what the upstream retry policy actually is, whether files can be amended and resent as corrections (which needs versioning, not deduplication), and how late data arrives, since those answers change the design more than any pattern choice.

Answer

This is a realistic day-one FDE task, and the interviewer wants working pragmatism: normalisation first, exact dedupe second, honest reporting of what fuzzy matching would add, not a research project. The shape of the answer: load defensively (mixed encodings and delimiters are near-certain in a three-company merge), normalise the fields that carry identity, then deduplicate in tiers of decreasing confidence. Tier one: exact match on normalised email, the highest-precision signal in contact data.

Tier two: normalised phone number, after stripping formatting and handling country-code variants, in India specifically, the same number appears as 98765xxxxx, +9198765xxxxx, and 098765xxxxx across systems, and naive string equality misses all of it. Tier three: name plus company after normalisation (case, whitespace, honorifics, Pvt Ltd versus Private Limited), which is where precision starts to drop and where you stop for a first pass, flagging the tier-three merges for review rather than auto-merging. Report all three numbers separately: 'you have at most X uniques by email, Y after phone matching, Z if the name-level merges hold', which is the honest answer to 'how many customers do we have' and shows the customer you understand match confidence is a spectrum. In code, groupby on the normalised keys with a survivorship rule (keep the most complete record, not the first) is enough at 1.2 million rows in pandas on a laptop; mention that true fuzzy matching (edit distance, blocking, a linkage library like splink) is the follow-up engagement if the review sample shows tier three is leaving value on the table.

import pandas as pd
import re

df = pd.read_csv("contacts.csv", dtype=str, encoding="utf-8",
                 encoding_errors="replace").fillna("")

def norm_email(e: str) -> str:
    return e.strip().lower()

def norm_phone(p: str) -> str:
    digits = re.sub(r"\D", "", p)
    if len(digits) == 12 and digits.startswith("91"):
        digits = digits[2:]          # +91 prefix
    if len(digits) == 11 and digits.startswith("0"):
        digits = digits[1:]          # trunk 0
    return digits if len(digits) == 10 else ""

def norm_name(n: str) -> str:
    n = re.sub(r"\s+", " ", n.strip().lower())
    return re.sub(r"^(mr|mrs|ms|dr)\.?\s+", "", n)

def norm_company(c: str) -> str:
    c = re.sub(r"\s+", " ", c.strip().lower())
    # Pvt Ltd == Private Limited == Pvt. Ltd.
    c = re.sub(r"\b(private limited|pvt\.? ?ltd\.?|pvt|ltd|llp|inc)\b", "", c)
    return c.strip(" .,")

df["email_n"] = df["email"].map(norm_email)
df["phone_n"] = df["phone"].map(norm_phone)
df["name_n"] = df["full_name"].map(norm_name)
df["company_n"] = df["company"].map(norm_company)

# completeness score for survivorship: keep richest record
df["score"] = (df[["email_n", "phone_n", "name_n"]] != "").sum(axis=1)
df = df.sort_values("score", ascending=False)

tier1 = df[df.email_n != ""].drop_duplicates("email_n")
no_email = df[df.email_n == ""]
tier2 = no_email[no_email.phone_n != ""].drop_duplicates("phone_n")
rest = no_email[no_email.phone_n == ""]
tier3 = rest.drop_duplicates(["name_n", "company_n"])  # flag for review

print(len(tier1), len(tier2), len(tier3))
print("upper bound uniques:", len(tier1) + len(tier2) + len(tier3))

Answer

Reconciliation SQL is bread-and-butter FDE work, and the interviewer wants a narrowing strategy, not one clever query. Step one: compare aggregates before rows. Total counts and sums by day (or by whatever partition the sync runs on) between your table and a fresh ERP export tell you immediately whether the discrepancy is everywhere (systematic transformation bug), concentrated in recent days (sync lag or a deploy), or in one historical window (a backfill that failed silently).

Step two: for the worst partition, do a full outer join on the business key and classify every row into three buckets, missing from ours, missing from theirs, present in both but different, because those three buckets have completely different causes. Missing-from-ours usually means filtered or failed ingestion; missing-from-theirs often means the customer's export has its own filters (cancelled orders, test accounts) and your table is actually right, which happens more often than customers expect and is worth saying diplomatically with evidence. Present-but-different needs a column-level diff, and the usual culprits are timezone shifts on date columns (IST versus UTC moves orders across day boundaries), currency or unit conversions, status-mapping differences, and float rounding on amounts.

Step three: turn the finding into a permanent asset, a reconciliation query that runs on schedule and alerts on drift, because a mismatch the customer finds before you do costs trust you spent months building. Candidates who jump straight to row-level diffing on 10 million rows, or who assume their own pipeline is wrong before checking the customer's export filters, both lose points; the method is aggregate, localise, classify, then fix.

-- Step 1: where does it diverge? Compare daily aggregates
SELECT COALESCE(o.d, e.d) AS day,
       o.cnt AS ours_cnt, e.cnt AS erp_cnt,
       o.amt AS ours_amt, e.amt AS erp_amt
FROM (SELECT DATE(created_at AT TIME ZONE 'Asia/Kolkata') d,
             COUNT(*) cnt, SUM(amount) amt
      FROM synced_orders GROUP BY 1) o
FULL OUTER JOIN
     (SELECT DATE(order_date) d, COUNT(*) cnt, SUM(total) amt
      FROM erp_export GROUP BY 1) e USING (d)
WHERE o.cnt IS DISTINCT FROM e.cnt
   OR ABS(COALESCE(o.amt,0) - COALESCE(e.amt,0)) > 0.01
ORDER BY 1 DESC;

-- Step 2: classify row-level differences for one bad day
SELECT COALESCE(s.order_id, e.order_id) AS order_id,
       CASE WHEN s.order_id IS NULL THEN 'missing_from_ours'
            WHEN e.order_id IS NULL THEN 'missing_from_erp'
            ELSE 'value_mismatch' END AS bucket,
       s.amount AS ours_amount, e.total AS erp_amount,
       s.status AS ours_status, e.status AS erp_status
FROM synced_orders s
FULL OUTER JOIN erp_export e USING (order_id)
WHERE (s.order_id IS NULL OR e.order_id IS NULL
       OR s.amount IS DISTINCT FROM e.total
       OR s.status IS DISTINCT FROM e.status)
  AND COALESCE(DATE(s.created_at AT TIME ZONE 'Asia/Kolkata'),
               DATE(e.order_date)) = DATE '2026-08-03';

Answer

The interviewer is testing whether you have a disciplined loop for the vaguest possible bug report, which is the standard form AI complaints arrive in. Step one: get concrete cases. Reply asking for two or three specific examples with the expected answer, and in parallel pull the trace logs yourself, if you built the system properly you can see every recent interaction's input, retrieved context, prompt, model output, and metadata (model version, prompt version, latency).

Without concrete cases you cannot even confirm the problem exists; 'wrong' sometimes means slow, sometimes means differently formatted, and sometimes means a user disagreed with a correct answer. Step two: localise each failing case along the pipeline. For a RAG system the classic split: was the right document retrieved?

If not, it is a retrieval problem (embedding quality, chunking, a stale index missing newly added documents, a permissions filter excluding too much). If retrieval was right, did the model use it faithfully? That is a generation problem (prompt regression, model version change, context overflow truncating the evidence).

Step three: check what changed. Wrong answers that start on a date usually correlate with a deploy, a prompt edit, a provider model update, or a change in the customer's own data, diff all four before touching code. Step four: fix, then institutionalise, add the failing cases to the eval set, run the full eval to confirm no collateral regression, and close the loop with the customer showing the before and after on their own examples.

That last move converts a trust-losing incident into a trust-building one, which is half the FDE job. The meta-answer being graded: you never debug an LLM system by staring at the model; you debug it by instrumenting the pipeline around it.

Answer

FDEs absorb feedback with no manager standing between them and the customer, so this question tests composure and whether feedback actually changes your behaviour. Pick real, painful feedback about you or your work, not a humble-brag ('they said I worked too hard') and not feedback about someone else's failure you got caught in. Good examples: a customer saying your demo wasted their executives' time because it ignored their actual workflow; an operator saying your tool made their day slower; a champion saying you over-promised a date and made them look bad internally.

Structure: context in two sentences, then the moment itself. What interviewers watch for in 'the room' part: did you defend, deflect, or listen? The strong move is to ask clarifying questions until you can restate their criticism better than they said it, resist explaining yourself in that meeting, and commit to a specific follow-up rather than a vague apology.

Then the 'after' part, which carries most of the weight: name the concrete behaviour change and show it stuck. 'I now demo against the customer's own data and rehearse with one of their operators first' is a system; 'I became more careful' is nothing. If the feedback was partly unfair, it is fine to say so, but show you extracted the fair kernel anyway, because customers are sometimes wrong about causes while being right about the experience, and an FDE has to act on the experience. End with the relationship outcome: harsh feedback handled well usually deepens trust, and if you can honestly say that customer became your strongest reference, say it.

Answer

Demo-day failure is an FDE rite of passage, and the question has two halves: live recovery and prevention systems. In the moment: stay flat, narrate briefly without technical excuse-making ('that call failed, let me show you this on the fallback'), and switch to your prepared fallback path within thirty seconds, a recorded run, a cached environment, or a second tenant you smoke-tested that morning. What you must not do: debug live for five minutes while executives check their phones, blame the customer's network in an accusatory way, or pretend the error did not happen.

If the failure is total, pivot the slot to a whiteboard walk of what they would have seen and take the twenty minutes of executive attention on the problem itself; a composed pivot often lands better than a smooth demo, because leadership is partly evaluating whether they can trust you under pressure. Afterwards, own it in the follow-up note the same day, with a specific re-demo date. Prevention is where senior candidates differentiate.

A demo checklist: rehearse the exact click-path twice, once within an hour of the demo; freeze deploys to the demo environment for 24 hours; pre-warm anything that cold-starts; have offline fallbacks for everything that depends on wifi, VPN, or a third-party API; know which failures are recoverable live and which trigger the fallback immediately. For LLM demos specifically: pin model versions, pre-run the exact prompts you will use, and never take fully open-ended audience prompts to a system you have not hardened for them, offer a constrained 'try it yourself' segment instead. The interviewer is evaluating composure, ownership, and whether your reliability comes from systems or from luck.

Answer

Every serious FDE loop contains a failure round, and it filters more candidates than any technical question. The evaluation is specific: do you own a real share of a real failure, can you separate causes from symptoms, and did the failure produce a durable change in your operating system rather than a lesson-shaped sentence. Choose a genuine failure with stakes, an engagement that got cancelled, a launch that users rejected, a deadline missed badly enough to damage trust, not a 'failure' that secretly showcases you.

Structure: what the goal was, what actually happened, why, your share, the change. On your share, be surgical. 'The customer kept changing requirements' is what happened to you; 'I kept absorbing the changes without resetting the timeline or forcing a priority conversation, so the deadline became fiction and I knew it weeks before I said it' is your share.

Interviewers push follow-ups here ('what would the customer say your share was?'), so pick a story you can examine honestly under pressure. On the change: make it operational and verifiable. Examples that land: instituting a written weekly status with a red/amber/green that you actually mark red; demoing to real end users by week three instead of building for the buyer's description of them; refusing to quote dates before a data-access audit.

Then, ideally, show the change paying off in a later project. Two disqualifying patterns: the disguised success ('we failed to hit an extremely ambitious goal, hitting only a very good one') and blame arbitrage, where your share of the failure rounds to zero. Both read as a person who will hide bad news at a customer site, which is the exact risk this round exists to catch.

Answer

FDEs live on this fault line: you serve the customer but you work for the platform, and the roadmap will regularly refuse things your customer needs. The interviewer wants evidence you can advocate hard without going rogue. A strong story has four beats.

First, you strengthened the signal before escalating: one customer's anecdote is easy to refuse, so you documented the concrete workflow blocked, quantified the impact (revenue at risk, hours lost, renewal exposure), and checked with other FDEs whether their accounts hit the same wall, turning 'my customer wants X' into 'four accounts representing this much ARR are blocked on X'. Product teams do not ignore that shape of evidence, and building it is the FDE's unique leverage: you are the company's highest-fidelity sensor of what enterprises actually need. Second, you understood the refusal before fighting it: sometimes the roadmap is right and the request is a local optimum, and saying you seriously entertained that possibility signals judgment.

Third, the bridge: while the debate ran, you built a sanctioned workaround, a customer-side script, a configuration, an interim integration, that kept the customer moving without forking the product, and you were explicit with the customer about what was temporary. The unsanctioned fork you quietly maintain forever is the classic FDE trap and interviewers listen for whether you know it. Fourth, the resolution, in either direction: the feature shipped and you migrated the workaround away (name that cleanup; it shows discipline), or it did not ship and you reset the customer's expectations honestly. What is being evaluated: evidence-building over volume, loyalty to both sides of the fault line, and whether your workarounds converge back to the product or drift away from it.

Answer

Multi-account load is normal at Databricks, Salesforce, and post-scale AI companies, so interviewers probe both the detection system and the triage. Detection first, because 'quietly' is the operative word: accounts rarely announce decay, they show it as small signal changes. The champion takes longer to reply.

Meeting attendance thins from six people to two. Usage metrics plateau. Questions shift from 'how do we expand this' to 'can you send a summary for our internal review', which often means your project is being evaluated for cutting.

A strong answer names an explicit weekly account-health habit, ten minutes per account checking usage data, open commitments, and last-contact recency, because relying on ambient awareness is exactly how the quiet account dies. Then triage. First move on the sick account: diagnose before treating, request a direct conversation with the champion and ask plainly what changed; the cause is usually one of budget pressure, a stakeholder change, an unresolved disappointment nobody escalated, or a competing internal project.

Each has a different response and guessing wrong wastes the account's remaining patience. On the healthy accounts, the discipline is honest renegotiation rather than silent starvation: tell them you are compressing this fortnight, move their deliverables explicitly, and keep the small predictable touchpoints (the weekly note especially) because rhythm, not hours, is what accounts read as commitment. Escalate early to your lead with a specific ask, cover on one account, a joint call, a priority ruling, since managers can absorb a load problem in week one but not a churned account in week eight. What is evaluated: proactive sensing, diagnosis before action, and whether you communicate capacity honestly instead of degrading service silently across all three.

Answer

This tests influence without authority in its purest enterprise form, and interviewers want a ladder of moves, not a single trick. Rung one: make yourself easy to approve. Most stalled access requests are stalled because approving them requires work or carries risk for someone: the ticket is vague, the security implications are unassessed, the approver does not know who you are.

So find the actual human owner (not the queue), book fifteen minutes, and arrive with the request pre-shrunk: read-only, scoped to specific schemas, time-boxed, with your security questionnaire answers already written. Shrinking the blast radius of a yes is the highest-leverage move in enterprise access politics. Rung two: build the relationship rather than the pressure.

IT teams block outsiders who treat them as an obstacle and help insiders who treat them as stakeholders; ask about their change process, follow it visibly, and credit them in front of their boss when access lands. Rung three: route around the blocker without violating it, ask whether an extract can be pushed to you instead of you pulling, whether a customer-side engineer can run your profiling script and share results, or whether a masked snapshot in a sandbox satisfies policy faster than production access. Progress on 80 percent of the data often restarts a stalled project.

Rung four: escalate through the customer's own hierarchy, not yours, by equipping your champion: a crisp note saying what is blocked, the cost per week of delay, and the specific approval needed, so the champion spends their internal capital efficiently. What you never do: guilt-trip the IT team, borrow someone else's credentials, or let three more weeks pass in silence while the deadline dies. The story you tell should show at least two rungs and a result.

Answer

Scope creep at a customer site is not a contracts problem, it is a relationship dynamic, and the interviewer wants to see you manage it without either capitulating or lawyering. The failure modes bracket the answer: absorb everything and the core deliverable slips, which the same customer will hold against you at renewal regardless of how many favours you did; refuse everything and you become an adversary inside their building, which kills the trust an embedded engineer runs on. The working pattern has three parts.

First, a visible backlog: every request, however small, gets written into a shared list with a rough size, immediately and cheerfully, 'great idea, adding it to the board' costs nothing and converts a hallway ambush into an artifact. The person asking usually wants acknowledgment more than immediate delivery. Second, a trade conversation instead of a yes/no conversation: at the weekly sync, present the board and make the arithmetic theirs, 'we can take these two now if we move the reporting milestone a week, or park them for phase two; which do you prefer?'

This keeps you as the person maximising their outcome rather than defending your scope, and it forces the customer's own stakeholders to argue priority with each other instead of all of them arguing with you. Third, spend judgment on the exceptions: some small requests are strategically free, a fifteen-minute fix that delights the operator who champions your tool is worth breaking process for, and knowing when to just do it is part of the skill. Mention the compounding asset: a written record of delivered extras is renewal-conversation gold, and a written record of deferred asks is the natural seed of the phase-two proposal, which is how good FDEs turn scope creep into expansion revenue.

Answer

The test is whether you can say no in a way that increases trust, which is a learnable structure. Step one: do not argue in the meeting where the ask lands. Acknowledge the underlying need, ask what is driving the number and the date, and buy a day.

The drivers matter: '100 percent' usually decodes to 'my team cannot spend hours checking every output' or 'a regulator or client is auditing us', and each decodes to a different solvable problem. Arguing against the literal ask before decoding it wastes the pushback on the wrong target. Step two: come back with numbers, not adjectives.

Never say 'that is impossible'; show the current system's measured accuracy on their own forms, the realistic ceiling for handwriting extraction on their document quality, and, critically, what each accuracy band costs in review effort. Concrete numbers move VPs; engineer intuition does not. Step three: reframe from accuracy to outcome.

The workable proposal is almost always a confidence-routed workflow: the system auto-processes the cases it is confident about, routes the rest to human review, and the customer gets a guarantee you can actually sign, '100 percent of extractions are either high-confidence or human-verified', which satisfies most audit and staffing drivers better than a fake accuracy promise would. Offer the trade explicitly: higher automation rate over time as the eval set grows, with the review queue as the safety net from day one. Step four: put the commitment in writing with the metric defined precisely (accuracy on what distribution, measured how), because vague promises are how this exact conflict returns in month three with your name on it. What is evaluated: decoding the ask, quantified honesty, and converting an impossible demand into a signable design.

Answer

Regulated-data engagements are a growing share of FDE work (banks, insurers, hospitals, telecom), and the interviewer wants a layered plan rather than despair or naive workarounds. Layer one: build against structure, not values. Schemas, data dictionaries, column statistics, null rates, cardinalities, and value distributions are usually shareable even when records are not, ask for them explicitly, because most of your pipeline design depends on shape rather than content.

Layer two: synthetic and redacted data for development. Have the customer's own team produce either masked extracts (real structure, scrambled identifiers, perturbed values) or fully synthetic records generated to match the dictionary; you write the generator or masking script, they run it inside their perimeter and review the output before it crosses. Be explicit in the interview that naive masking leaks (rare combinations re-identify people; free-text columns hide PII), so free text gets dropped or synthesised, never 'scrubbed'.

Layer three: move the compute to the data. The deployment model becomes: your code ships into their environment (their VPC, their on-prem cluster) via their approved CI process, and runs there under their controls. That inverts your normal workflow, so name the consequences you will engineer around: slower iteration loops, so you invest in strong test coverage on synthetic data before each deployment; no eyeballing production records, so validation becomes metrics and aggregates their staff can approve for export, match rates, error distributions, eval scores, never row-level examples.

Layer four: a cleared human proxy. A customer-side engineer or analyst who can look at real data becomes your eyes: you write the diagnostic queries and evaluation harnesses, they run them and report aggregate results. Budget real relationship investment there, because that person's responsiveness becomes your iteration speed. Close with the trust frame: treating their constraint as a design parameter rather than an obstacle is precisely what wins regulated enterprises.

Answer

This scenario tests field discipline: debugging with constraints, extracting maximum information per hour of scarce access, and leaving the site with the problem either fixed or fully characterised. The winning structure is preparation, triage, and evidence capture. Preparation: the day starts before the flight.

You arrive with hypotheses ranked from whatever logs and descriptions exist, a written test plan ('reproduce, then check these five things in this order'), offline copies of documentation and your own code, and any diagnostic scripts pre-written so on-site time is spent executing, not authoring. Ask in advance what you will and will not have: a machine on their network? Read access to which systems?

Whose hands type if yours cannot? The 5 pm IT contact is your scarcest resource, so their hours get scheduled first, access verification and anything requiring their permissions happens in the morning, not discovered broken at 4:45. Triage on site: reproduce the failure first and resist fixing symptoms before seeing the mechanism, plant integrations fail for physical-world reasons (a PLC clock drifting, a file share filling, a network segment flapping when a machine powers on) that remote hypotheses rarely include, which is exactly why you were flown in.

Walk the actual data path end to end with your own eyes. Evidence capture: assume you will not be allowed back soon. Collect logs, configs, screenshots, timestamps, and exact versions into one place, within their export rules, so remote follow-up is possible; a debugging visit that ends with 'it did not reproduce today' but complete evidence is a partial success, one that ends with a lucky fix and no understanding is a failure that will page you again.

End the day by briefing the plant contact in their terms and writing the summary before leaving the parking lot, while details are fresh. What is evaluated: whether your effectiveness survives the removal of your tooling comfort zone.

Answer

Pilots die in the pilot-to-production gap more than anywhere else, and interviewers want evidence you have crossed it. The conversation you force is a definition conversation, because 'production' means different things to every stakeholder in the room. Pin down five axes in writing.

Scale: pilot served one team's 200 documents a day; production means which teams, what volume, what growth? Reliability: a pilot can be restarted by you personally; production needs an SLA, on-call ownership, and an answer to 'who gets paged at 2 am', and 'the FDE, forever' is not an answer, so the support handoff plan (their team, your product's support org, or a managed arrangement) gets decided now, not after the first incident. Security and compliance: pilots run on exceptions and temporary approvals; production triggers the customer's real review gauntlet, security assessment, data-protection sign-off, procurement, sometimes a regulator, and those clocks are long enough that they start immediately, in parallel with engineering.

Integration depth: pilots tolerate manual steps and CSV hand-offs; production means SSO, the real ERP write-path, audit logging, and access controls per the customer's model. Success metrics: the pilot proved value on a friendly team that volunteered; production means adoption targets among people who did not choose the tool, so training, champions per team, and a rollout sequence become part of the plan. Then re-scope honestly: the classic failure is treating productionisation as 'deploy the pilot bigger', when it is usually 50 to 80 percent new work, hardening, permissions, monitoring, migration, support tooling.

Present that as a phased plan with the first production team live early rather than a big-bang cutover. What is evaluated: whether you protect the pilot's momentum while refusing to let its shortcuts become production's foundations.

Answer

The interviewer wants you past the tutorial architecture (embed, store, top-k, generate) and into the decisions that determine quality on real corpora. First decision: ingestion and chunking, which is where more quality is won or lost than anywhere else. Enterprise documents are not clean text: contracts have nested clauses, SOPs have tables and step lists, policies have versions and effective dates.

Parse structure-aware (headings, clauses, tables kept intact), chunk along semantic boundaries rather than fixed character counts, and attach metadata to every chunk: source document, section path, effective date, document type, owning department, access level. Metadata is not decoration; it powers filtered retrieval ('current policies only'), permission enforcement, and citations. Second decision: hybrid retrieval.

Dense embeddings miss exact identifiers (policy codes, clause numbers, product SKUs) that enterprise queries are full of, so combine vector search with BM25 keyword search and fuse results; add a reranker (a cross-encoder over the top 50 candidates) because it is the single cheapest large quality gain in most deployments. Third decision: handle the version problem explicitly, when a policy has five versions, retrieval must prefer the effective one and the answer must say which version it used; getting this wrong in a contractual engagement is how you generate confidently outdated answers, the worst failure class. Fourth: measure retrieval separately from generation.

Build a retrieval eval (does the right chunk appear in the top k for known question-source pairs?) because end-to-end evals cannot tell you which half is broken. Finally, staleness: documents change, so ingestion is a pipeline with change detection, not a one-time load. Summarise with the honest heuristic: when RAG answers are bad, it is retrieval roughly four times out of five, and disciplined chunking plus hybrid search plus reranking fixes most of it before you touch prompts.

# Hybrid retrieval + rerank: the shape that survives production
from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder
import numpy as np

# load the reranker ONCE at import; per-query construction reloads the model
RERANKER = CrossEncoder("BAAI/bge-reranker-v2-m3")

def user_can_read(chunk) -> bool:
    # supplied by the host application's permission layer
    return True

def build_bm25(chunks):  # run ONCE at ingestion, reuse across queries
    return BM25Okapi([c["text"].lower().split() for c in chunks])

def hybrid_search(query, chunks, embedder, index, bm25, k_dense=30, k_kw=30):
    # dense leg
    qv = embedder.encode([query])[0]
    dense_ids = index.search(np.array([qv]), k_dense)[1][0].tolist()
    # keyword leg (catches policy codes, clause numbers, SKUs)
    kw_scores = bm25.get_scores(query.lower().split())
    kw_ids = np.argsort(kw_scores)[::-1][:k_kw].tolist()
    # reciprocal-rank fusion
    fused = {}
    for rank, cid in enumerate(dense_ids):
        fused[cid] = fused.get(cid, 0) + 1 / (60 + rank)
    for rank, cid in enumerate(kw_ids):
        fused[cid] = fused.get(cid, 0) + 1 / (60 + rank)
    candidates = sorted(fused, key=fused.get, reverse=True)[:50]
    # filter to effective versions + user's permissions BEFORE reranking
    candidates = [c for c in candidates
                  if chunks[c]["is_current"] and user_can_read(chunks[c])]
    # cross-encoder rerank: cheapest big quality win
    scores = RERANKER.predict([(query, chunks[c]["text"]) for c in candidates])
    ranked = [c for _, c in sorted(zip(scores, candidates), reverse=True)]
    return [chunks[c] for c in ranked[:8]]

Answer

This question checks whether you design agentic systems by risk analysis or by enthusiasm. Start with the decomposition principle: an 'agent' is a loop of model calls with tools, and every step should be classified on two axes, how reversible is the action, and how verifiable is the decision. Reading and classifying an email: fully reversible, cheaply verifiable, automate freely.

Looking up a PO in the ERP: read-only, automate. Drafting a reply: reversible while it is a draft. Sending money-adjacent replies or writing to the ERP: irreversible and externally visible, and that is where autonomy stops until trust is earned.

The deployment pattern that follows is graduated autonomy: phase one, the agent does everything except act, it drafts, a human approves each output, and every human correction is logged; phase two, categories with a demonstrated high approval rate over a real volume threshold (say 98 percent over 500 cases) graduate to auto-send with sampling review; phase three, only boring, high-volume, well-evidenced categories run fully autonomously, and novel or low-confidence cases route to humans forever. This gives the customer a system whose autonomy is an earned, revocable, per-category property backed by their own approval data, which is an easy thing for a risk owner to sign. On structure: prefer an explicit workflow (deterministic steps with the model doing classification, extraction, and drafting inside them) over a free-running loop that plans its own tool calls; you gain traceability, testable steps, and bounded failure at the cost of flexibility you rarely need for a defined business process.

Add the operational guardrails as a list: tool-side input validation (the model proposes, typed and validated code disposes), spend and rate limits, timeout and retry policies, a kill switch per category, and full trace logging of every step for the audit conversation that will certainly come. Close with the escalation design, since 'escalate' is in the ask: escalation is a first-class outcome with a reason code, not a failure branch, and its rate is a health metric you watch.

# Explicit workflow beats free-running loop for defined processes
from dataclasses import dataclass

@dataclass
class Decision:
    action: str          # 'auto_reply' | 'draft_for_review' | 'escalate'
    category: str
    confidence: float
    reason: str

AUTONOMY = {"invoice_status": "auto_reply",     # earned: 98%+ approval
            "po_mismatch": "draft_for_review",  # human approves
            "payment_dispute": "escalate"}       # never autonomous

def handle_email(email) -> Decision:
    cls = classify(email)               # LLM call, structured output
    if cls.confidence < 0.8 or cls.category not in AUTONOMY:
        return Decision("escalate", cls.category, cls.confidence,
                        "low confidence or unknown category")
    po = erp_lookup(cls.po_number)      # deterministic, read-only
    if po is None:
        return Decision("escalate", cls.category, cls.confidence,
                        "PO not found")
    draft = draft_reply(email, po, cls) # LLM call, template-constrained
    action = AUTONOMY[cls.category]
    log_trace(email.id, cls, po.id, draft.id, action)
    return Decision(action, cls.category, cls.confidence, "ok")

Answer

The harness question separates teams that iterate from teams that thrash. Describe a three-layer harness. Layer one: deterministic checks on every case where ground truth exists, exact or normalised match for extraction fields, schema validity, presence of required refusals, latency and token cost per case.

These are cheap, unambiguous, and catch most regressions. Layer two: LLM-as-judge for qualities without ground truth, faithfulness to retrieved context, completeness, tone compliance. The critical discipline: a judge is only trustworthy after you have measured its agreement with human graders on a calibration sample (50 to 100 cases graded by both); report that agreement number, and re-check it when you change the judge model or rubric.

Use rubric-based binary or few-level judgments ('does the answer contain any claim not supported by the provided context: yes/no') rather than 1-10 scores, which are noisy and drift; compare candidate outputs pairwise when ranking two prompts, but randomise position, judges have measurable position bias. Never let the same model family judge its own outputs unchecked; known self-preference bias inflates scores. Layer three: human review as the periodic anchor, a weekly sample of production outputs graded by the customer's experts, both to catch what the harness misses and to keep the judge calibrated against reality drift.

Then the workflow answer: the harness runs on every prompt, model, or retrieval change like CI, produces a diff against the current baseline (overall and per category tag), and the answer to 'did it get better' becomes 'plus four points on multi-document questions, minus one on refusals, here are the three cases that flipped', which is a sentence a customer can act on. Mention statistical honesty at the end: on a 60-case eval, a two-point move is noise; run repeated samples or expand the set before celebrating.

# Eval harness core: deterministic checks + calibrated judge
import json
from openai import OpenAI

client = OpenAI()
JUDGE_RUBRIC = ("You are grading an answer against source context.\n"
  "Return JSON {\"grounded\": true|false, \"complete\": true|false}.\n"
  "grounded=false if ANY claim lacks support in the context.")

def judge(question, context, answer):
    resp = client.chat.completions.create(
        model="gpt-5-mini",  # judge must be a different family than your system's model
        response_format={"type": "json_object"},
        messages=[{"role": "system", "content": JUDGE_RUBRIC},
                  {"role": "user", "content":
                   f"QUESTION:\n{question}\n\nCONTEXT:\n{context}\n\n"
                   f"ANSWER:\n{answer}"}])
    return json.loads(resp.choices[0].message.content)

def run_eval(cases, generate):
    rows = []
    for c in cases:
        out = generate(c["input"])
        row = {"id": c["id"], "tag": c["tag"]}
        if "expected" in c:  # deterministic where truth exists
            row["exact"] = normalise(out) == normalise(c["expected"])
        g = judge(c["input"], c.get("context", ""), out)
        row.update(g)
        rows.append(row)
    return rows  # diff against baseline per tag, not just overall

Answer

This tests whether you know the gap between advertised context windows and dependable behaviour. What goes wrong, concretely. First, degraded mid-context recall: even models with very long windows recall information placed in the middle of a long context less reliably than information near the edges, and performance on tasks requiring synthesis across many scattered passages degrades well before the token limit is reached.

Marketing needle-in-haystack benchmarks are the easy case; multi-fact aggregation is the hard one your customer actually has. Second, cost and latency scale with input: stuffing 300 pages into every query might multiply per-query cost versus retrieving twelve relevant chunks, which at production volume is real money for mostly wasted tokens. Third, distraction: irrelevant context does not just cost money, it measurably pulls answers toward wrong passages, especially near-duplicate clauses across contract versions, which is the exact structure of enterprise document sets.

The design that follows: retrieval remains the backbone even in the long-context era, and the window budget you actually use per query is an eval-derived number, not the maximum the model accepts. Use long context where it genuinely wins: whole-document tasks (summarise this contract, extract every obligation) where completeness beats precision, and cases where retrieval provably fails to gather the needed spread. For cross-document questions, prefer structured decomposition over one giant prompt: retrieve per document, extract per-document answers with citations, then synthesise in a second pass; you get traceability and the failure of one document does not poison the rest.

For repeated work over the same corpus (due-diligence style), consider a pre-extraction pass that turns each contract into a structured summary once, then query the structures. And whatever the architecture, test position sensitivity in your own evals, put known facts early, middle, and late in the assembled context and measure, because the honest answer to 'how long is too long' is always 'for this model, on this task, here is the curve we measured'.

Answer

This is the canonical FDE decomposition case, and the design conversation is graded more than the boxes you draw. Open with the questions that change the architecture: which system is the source of truth for which fields (the answer is per-field, never per-system, sales owns contact info, billing owns credit status); what latency does the business actually need (daily batch solves most 'real-time' requests once you ask what decision waits on the data); can both sides be written to, or is one direction enough (bidirectional sync roughly quadruples complexity, so earn it with a concrete requirement, not symmetry instinct). Then the core hard problem: identity.

The two systems will not share a key, so you need a matching layer, deterministic joins where possible (tax IDs, account numbers), fuzzy match with human review for the remainder, producing a persistent cross-reference table that becomes the engagement's most valuable artifact. Architecture: change capture from each side (Salesforce CDC events; for the old ERP, likely a nightly extract diffed against the previous one, because 15-year-old systems rarely have event streams), a transform layer that normalises to a canonical model, per-field conflict resolution driven by the ownership map with last-writer-wins only inside a field's owning system, and idempotent writes with a sync-cursor so replays are safe. Two things separate senior answers.

First, conflict handling as a product feature: disagreements that violate the ownership map go to a review queue with an owner, not into silent overwrites, and the queue's size is a health metric the customer watches. Second, reconciliation as a permanent fixture: a scheduled job comparing both systems field by field and reporting drift, because the sync will break quietly (API limits, schema changes, a locale-format surprise) and you want to be the one who notices. Offer the phased rollout: one direction, five fields, one entity type first; expand after two clean weeks.

Answer

The trap in this question is designing one giant table with every field and every consumer reading it directly, which fails exactly the way the interviewer expects you to predict: any producer schema change breaks four teams at once, access control becomes row-and-column spaghetti, and freshness requirements get dragged to the strictest consumer's needs at everyone's cost. The design that works is a core-plus-views architecture. A canonical core entity, customer identity, lifecycle status, and the small set of universally agreed fields, maintained by one owning pipeline with an explicitly versioned schema.

Around it, per-team serving views (or marts): finance's view joins billing aggregates with the currency conventions finance actually uses; support's view carries case history and SLA fields; data science gets a point-in-time-correct snapshot table for training, because training on today's values for yesterday's events is the silent leakage bug that ruins their models. Each view has a declared freshness contract (finance daily is fine, support wants minutes), so you engineer expensive freshness only where it is bought. Access control lives at the view layer, teams get permissions on their view, sensitive columns are masked per policy in the view definition, and nobody reads the core directly.

The contract discipline is the actual answer to 'without breaking each other': schema changes to the core are versioned and announced, views pin to a version and migrate deliberately, and additive changes are the default (new fields appear, old fields deprecate on a schedule, nothing mutates in place). Add data-quality checks at the core boundary (row counts, null-rate deltas, referential integrity against source) so bad loads are quarantined before fan-out multiplies them by four. Close with the organisational point interviewers reward: the hard part is agreeing what 'a customer' is, one definition meeting with all four teams up front prevents a quarter of reconciliation fights, and the FDE is usually the only person positioned to convene it.

Answer

Mixed-format ingestion is a staple FDE case because it tests whether you normalise early, preserve raw truth, and treat data quality as a first-class output. The architecture: per-source adapters, a raw landing layer, a canonical normalisation stage, and quality-gated serving tables. Adapters first: each device generation gets its own thin adapter (HTTP receiver, FTP poller, binary decoder) whose only job is to get bytes into the raw landing zone with envelope metadata, source ID, arrival time, batch ID, checksum.

Do not normalise in the adapter; keep it dumb so a new device generation is a new adapter, not a pipeline rewrite. Raw landing layer: append-only object storage of the original payloads, untouched. This is non-negotiable and worth saying explicitly: when normalisation logic turns out wrong in week six (it will; the binary spec document will disagree with the devices), you reprocess from raw instead of begging the trucks to resend.

Normalisation stage: decode each format into one canonical event schema (vehicle ID, event time, received time, measurement set, source generation, quality flags). The two named problems get explicit treatment here. Clock drift: never trust device time alone; record both event time and server arrival time, estimate per-device offset where protocols allow, and flag records whose device time is implausible against arrival time rather than silently 'correcting' them.

Gaps: gaps are data, not absence, a per-vehicle heartbeat expectation turns silence into a detectable event (device down? coverage hole? truck parked?), which is usually worth more to a logistics operator than the telemetry itself. Serving: time-partitioned tables with late-arrival handling (FTP batches arrive hours late, so downstream aggregations must tolerate updates within a lateness window, state it explicitly). Finally, per-source observability: counts, lag, and parse-failure rates per device generation on one dashboard, because with 2,000 devices something is always broken and the customer's first question every Monday is 'which ones'.

Answer

The interviewer wants to know whether you reach for the right level of machinery and can name the correctness properties, because FDEs build exactly this at nearly every data-heavy customer. First decision, buy versus build: at 200 jobs with dependencies and retry policies, a workflow orchestrator (Airflow, Dagster, Temporal, or the customer's existing standard) beats hand-rolled cron, and picking what the customer already operates usually beats your favourite, because they inherit this system when you leave. Say that trade-off out loud.

Then the properties the design must guarantee, which matter more than the tool. Non-overlap: the finance requirement is a per-job concurrency limit of one, enforced by the scheduler (max one active run per job) plus a lease or lock at execution time as a second line, belt and braces, because scheduler bugs during restarts are exactly when double-runs happen. Catch-up policy: when a job misses its window (downtime, a long previous run), does it run once, run for every missed interval, or skip?

The answer is per-job (finance backfills, a cache-warming pull skips), and schedulers that conflate 'catch-up' with 'skip' cause either data gaps or thundering herds, so configure it explicitly per job. Idempotent runs keyed by logical execution window, not wall clock, so a retried 2 am pull writes the same partition as the original attempt and reruns are safe. Retries with backoff and a retry budget, after which the job parks in a failed state that pages a human, silent infinite retry against a customer API is how you get rate-limited and blamed.

Timeouts per job class, so a hung two-minute pull cannot hold a worker for a day. Resource isolation: separate worker pools for long and short jobs, or the two-hour pulls starve everything at the top of the hour. And the operational layer that makes it survivable: per-job SLA alerts ('finance pull not green by 6 am IST pages'), run-history visible to the customer, and a one-click manual rerun for the support person who is not you.

Answer

This is a pragmatism test: 4 GB is too big to eyeball and too small to justify infrastructure, so the expected answer is streaming Python that never loads the file into memory, plus a narrowing strategy. The strategy first, because code without one impresses nobody: pass one aggregates errors by day to find when the failure started (the customer's 'sometime last month' is usually wrong by a week); pass two zooms into the onset window and clusters error messages to find what changed; pass three pulls full context, the log lines before and after the first occurrences, to find why. Two techniques carry the exercise.

First, normalise error messages into templates before counting: raw messages embed IDs, timestamps, and paths ('timeout syncing order 8837421'), so naive counting shows ten thousand unique errors; replacing digits and hex tokens with placeholders collapses them into a handful of templates whose counts tell the story. Second, corroborate the onset against change events, deploy markers, config changes, the customer's own release notes, because 'first occurrence at 03:12 on July 14' is only useful when you can put it next to 'their vendor rotated certificates on July 14', and saying you look for that correlation is what makes the answer sound like someone who has done this. Practical touches worth mentioning: handle gzipped rotated logs transparently, parse timestamps defensively (the format will change mid-file when their log config changed), and write findings into a small CSV as you go, because the customer meeting after lunch wants a chart, not your terminal. If the logs were 400 GB instead, you would push them into DuckDB or their warehouse and do the same analysis in SQL; naming that threshold shows judgment about tooling scale.

import gzip, re, sys
from collections import Counter
from pathlib import Path

TS = re.compile(r"^(\d{4}-\d{2}-\d{2})[T ](\d{2}):")

def template(msg: str) -> str:
    msg = re.sub(r"0x[0-9a-fA-F]+", "<HEX>", msg)
    msg = re.sub(r"[0-9a-f]{8}-[0-9a-f-]{27}", "<UUID>", msg)
    return re.sub(r"\d+", "<N>", msg)[:160]

def lines(path: Path):
    op = gzip.open if path.suffix == ".gz" else open
    with op(path, "rt", errors="replace") as f:
        yield from f

by_day, by_tmpl = Counter(), Counter()
first_seen = {}
for p in sorted(Path(sys.argv[1]).glob("app*.log*")):
    for line in lines(p):
        if " ERROR " not in line and " FATAL " not in line:
            continue
        m = TS.match(line)
        if not m:
            continue
        day = m.group(1)
        t = template(line.split(" ERROR ")[-1].strip())
        by_day[day] += 1
        by_tmpl[t] += 1
        first_seen.setdefault(t, (day, line.strip()[:300]))

for day in sorted(by_day):          # pass 1: when did it start?
    print(day, by_day[day])
for t, n in by_tmpl.most_common(10):  # pass 2: what is failing?
    print(n, t, "| first:", first_seen[t][0])

Answer

The question rewards boring, defensive engineering over frameworks: this is a small-data problem (three files, weekly) where the risk is silent corruption, not scale. The design points interviewers listen for. Validate at the boundary, load nothing that fails: check expected columns exist (after normalising header variants through an alias map, because 'Inv Amt', 'Invoice Amount', and 'invoice_amount' are the same column in three people's Excel), parse dates by trying the known formats explicitly rather than letting a permissive parser guess (a guessing parser reads 04/07 as April 7 for the US-formatted file and July 4 for the Indian one, and that bug is invisible until quarter-end), and strip currency formatting deterministically.

Reject-and-report beats fix-and-hope: rows that fail validation go into a rejects file with row number and reason, and the load proceeds with the clean rows plus a summary email, three bad rows should not block 4,000 good ones, but they must be visible to the person who owns the source file. Loads are idempotent per file-week: stage into a temp table, then swap or upsert keyed on the natural key, so re-running after a partial failure (or a corrected re-send, which will happen weekly) cannot double-load. Keep an audit trail: store the original file, checksum, row counts in and out, and load timestamp in a load-log table, because 'what did we load on the 14th' is a question you will be asked.

Finally, the FDE touch: the summary email goes to the customer's file owner, not just to you, listing loaded counts and rejected rows with reasons, which quietly trains the upstream team to fix their data, and after a month of stable Mondays you propose replacing email with a drop folder or an API. Simple, observable, idempotent beats clever here.

import hashlib
import pandas as pd
from sqlalchemy import create_engine

ALIASES = {"inv amt": "amount", "invoice amount": "amount",
           "inv date": "invoice_date", "invoice dt": "invoice_date",
           "invoice no": "invoice_no", "inv #": "invoice_no"}
DATE_FORMATS = ["%d-%m-%Y", "%m/%d/%Y"]  # known variants, tried in order

def parse_date(v):
    for fmt in DATE_FORMATS:
        try:
            return pd.to_datetime(str(v).strip(), format=fmt)
        except ValueError:
            continue
    return None  # goes to rejects, never guessed

def load(path, engine):
    df = pd.read_excel(path, dtype=str)
    df.columns = [ALIASES.get(c.strip().lower(), c.strip().lower())
                  for c in df.columns]
    missing = {"invoice_no", "invoice_date", "amount"} - set(df.columns)
    if missing:
        raise SystemExit(f"{path}: missing columns {missing}")
    df["amount"] = pd.to_numeric(
        df["amount"].str.replace(",", "").str.strip(), errors="coerce")
    df["invoice_date"] = df["invoice_date"].map(parse_date)
    bad = df[df["amount"].isna() | df["invoice_date"].isna()
             | (df["invoice_no"].fillna("").str.strip() == "")]
    good = df.drop(bad.index)
    bad.assign(reason="failed validation").to_csv(
        f"{path}.rejects.csv", index=False)
    good["source_sha"] = hashlib.sha256(
        open(path, "rb").read()).hexdigest()
    good.to_sql("invoices_staging", engine, if_exists="replace",
                index=False)  # then upsert from staging in one txn
    print(f"{path}: loaded={len(good)} rejected={len(bad)}")

Answer

LLM observability differs from classic APM because the failure you care about is quality, which no status code reports, so the answer must cover three layers. Layer one, traces: every request gets a trace capturing the full pipeline, input, retrieved chunks with scores, assembled prompt, model and prompt version, raw output, parsed output, tool calls, token counts, latency per stage, and total cost. This is non-negotiable because debugging an LLM system without the exact context it saw is guesswork; tools like Langfuse, LangSmith, Braintrust, or OTel-based GenAI tracing into your existing stack (SigNoz, Datadog) all work, and at a customer site you prefer whatever their team can operate after you leave.

Layer two, system metrics with LLM-specific additions: alongside availability and latency percentiles, track token spend per route per day (cost regressions from a prompt change are found here, not in the invoice), parse and validation failure rates on structured outputs, retrieval no-result rates, refusal rates, and provider error and rate-limit counts. Alert on deltas, not absolutes, a refusal rate that doubles overnight means a model update or an input shift even if it is still 'only' 4 percent. Layer three, quality signals, which is what actually answers 'is it working': explicit user feedback where the UI allows it, implicit signals (retry rate, answer abandonment, escalation-to-human rate, edit distance between draft and what the user finally sent), and scheduled sampled grading, a daily job running a calibrated judge over a sample of production traffic, tracking groundedness and task-success over time on the same rubric as your offline evals.

The customer-facing dashboard shows exactly four things: volume, cost, reliability (uptime plus validation-failure rate), and a quality trendline with examples behind it. The senior detail: log prompts and outputs under the customer's data-retention rules, agreed in writing during deployment, because a trace store full of unredacted PII is a compliance incident you built yourself.

Answer

This is the advanced version of the failure question, and its sharpest part is 'why so late', because that is where interviewers learn how you metabolise disconfirming evidence. A strong story admits to the mechanism of self-deception, not just the outcome. Typical honest mechanisms: you validated with the wrong person (the buyer described the workflow, the operators lived a different one); you mistook politeness for validation (enterprise stakeholders rarely say 'this is useless' in a meeting, they say 'interesting' and stop attending); you fell for sunk-cost momentum (by week three the architecture was elegant and you defended it against evidence instead of testing it); or you demoed slideware and mockups for a month, which produce agreement, when only working software against real data produces truth.

Pick your real mechanism and name it plainly; the self-awareness is the point. Then the recovery: how you found out (ideally you engineered the discovery, put the real thing in front of real users, rather than being told), what you salvaged, how you re-planned, and crucially how you communicated it, walking into the customer or your lead with 'I built the wrong thing, here is what I now know, here is the shorter path to the right thing' is the single most trust-relevant move in the story. Then the system, which must be mechanical, not aspirational: real users touch working software on real data by a fixed early date, no exceptions; a written list of the assumptions the project dies on, each with a test and a date; watching behavioural signals (attendance, response latency, unsolicited questions) rather than verbal ones; and a standing rule that a demo that only shows what works is a demo that teaches nothing, you show the rough edges to provoke correction. Interviewers at Palantir-lineage companies especially probe whether the change survived: give the later project where the early-warning system fired and saved you a month.

Answer

Champion loss is the single most common cause of enterprise engagement death, and the interviewer wants a campaign plan, not a hope. Frame the situation honestly first: the new executive owes your project nothing, inherits its costs without its context, and gains political capital by cutting a predecessor's initiatives; your relationship capital just went to zero while your burn rate did not. The 60-day plan.

Days 1-10, evidence assembly: build the value dossier before requesting any meeting, usage numbers, cycle-time deltas, cost savings, quotes from the operators who rely on the system daily, all in the customer's own metrics, because the meeting you eventually get may be fifteen minutes long and it will not be rescheduled. Simultaneously, map your remaining allies: the operators and middle managers whose teams use the product are now your constituency, and their managers reporting value upward is worth more than you claiming it. Days 10-30, earn the meeting: route through whoever the new executive trusts, their chief of staff, a peer VP who benefits from the project, your own company's executive sponsor peer-to-peer, and when you get the slot, do not defend the past; ask about their priorities and re-anchor the project to their agenda.

A new leader keeps what makes their goals easier, not what honoured their predecessor's. Be genuinely open to resizing: offering to cut a low-value workstream buys credibility that defending everything never does. Days 30-60, create proof on their terms: propose one narrowly scoped deliverable aligned to something they publicly care about, ship it fast, and let them present it internally as an early win under their leadership, giving the new executive ownership of a success is how projects survive regime change.

Meanwhile, escalate honestly inside your own company: flag the renewal risk early, get executive-relationship help, and never let your leadership hear about the risk for the first time at cancellation. If it still dies, exit gracefully and keep the operator relationships; enterprise buyers recycle across companies, and today's cancelled deployment is a reference call in three years.

Answer

This scenario is increasingly common in 2026 and tests whether you can be honest about trade-offs while still finding a path. Architecture first. Full in-VPC means self-hosted open-weight models (Llama, Qwen, Mistral families, or a licensed deployment of a commercial model where the provider offers VPC or on-prem terms, worth checking before assuming open-weights-only, since Databricks-style platforms and some labs do offer in-perimeter options).

Serving runs on vLLM or a managed-inference layer over their GPUs, and everything around the model, vector store, orchestration, eval harness, tracing, must also be deployed inside: no Langfuse cloud, no external embeddings API, no telemetry that phones home, and procurement will scan for exactly that. Be direct with the customer about the capability delta: on hard reasoning tasks, a self-hosted mid-size model is typically behind frontier APIs, so you re-run the eval set on candidate models and let the numbers decide whether the gap matters for their workflows; often extraction, classification, and grounded Q&A hold up fine while complex agentic work degrades, which shapes scope. Workflow changes: model upgrades become their change-management events, not a provider flag flip; you own capacity planning (GPU quota, batching, cold-start behaviour); prompt iterations deploy through their CI; and debugging happens through their access controls, so you invest earlier in evals and tracing because casual poking is gone.

Economics invert: API pricing is variable cost with zero idle spend, self-hosting is committed GPU capacity plus an ops burden, so it is cheaper only at sustained volume, and someone must carry on-call for an inference stack, which becomes a staffing conversation with the customer, not a footnote. The strong close: propose a tiered design where genuinely sensitive routes run in-VPC while less sensitive, harder tasks use an approved external route if their policy allows segmentation, and if it does not, scope honestly to what the in-perimeter stack proves it can do on their evals. Enterprises respect a measured 'this route is not ready in-VPC' far more than a discovered failure in month four.

Answer

This is where fine-tuning is actually justified, and the interviewer wants the decision discipline, not enthusiasm for training. The preconditions you verify before committing: the task is narrow and stable (a fixed label taxonomy, not open-ended generation); you have real supervised data (three months of production gives you model outputs corrected by humans, the best training data that exists, because it concentrates on exactly the cases the base model got wrong); prompting is genuinely exhausted, demonstrated by an eval plateau across prompt variants and model tiers, not by one engineer's frustration; and the volume justifies it, at 400K documents a month, a fine-tuned small model matching the frontier model's accuracy cuts cost dramatically and usually latency too, so the business case writes itself if quality holds. Execution: curate before you train, deduplicate, re-verify a sample of the human corrections (some 'corrections' are themselves wrong), balance label distribution or at least know its skew, and hold out a test split that never touches training, with the eval set frozen before training begins so nobody optimises into it.

Start with the cheapest adequate technique: LoRA-style parameter-efficient tuning on a small open model, or the provider's hosted fine-tuning if the deployment allows it; full-parameter training is rarely warranted for classification. Compare four candidates on the frozen eval: base small model prompted, fine-tuned small model, frontier model prompted (current production), and fine-tuned small with the frontier as fallback for low-confidence cases, that router usually wins, giving frontier-level accuracy at a fraction of the cost because 90 percent of traffic is easy. Protecting the gain is the part most candidates miss: a fine-tune is a snapshot, and the customer's document mix drifts, so you ship a monitoring loop (confidence distributions, sampled human review feeding a fresh correction pool) and a scheduled retraining path with the eval gate automated.

State the ownership question out loud: who retrains in a year, you, the customer's team, or nobody? A fine-tune without a retraining owner is technical debt with a countdown, and saying so is what makes this an FDE answer rather than an ML-engineer answer.

Answer

The core insight the interviewer wants stated: multi-agent failures are compounding failures. If each step succeeds 95 percent of the time, a ten-step chain succeeds around 60 percent, and errors do not just accumulate, they propagate, a slightly wrong extraction becomes a confidently wrong query becomes a fluent report built on garbage, with the polish of the final output hiding the rot upstream. That framing drives every engineering answer.

First, shrink the surface: most 'multi-agent' designs are over-agentified, and steps with deterministic logic (routing on a known field, a fixed SQL template, formatting) should be code, not model calls; every model call you delete is compounding risk removed. Reserve agent autonomy for steps that genuinely need judgment. Second, verify at boundaries rather than trusting the chain: each agent's output passes a contract check before the next consumes it, schema validation, referential checks (does the table in the generated query exist; do the report's figures match the query results), and cheap plausibility tests.

Fail at the boundary and you have a diagnosable step error; fail at the end and you have an unexplainable bad report. Third, design the failure paths explicitly: bounded retries with the validator's error fed back, then fallback to a simpler path (template query instead of generated SQL), then human escalation with partial results and a stated reason, an honest 'analysis incomplete, steps one and two attached' beats a complete fabrication, and building that behaviour is your job, not the model's default. Fourth, checkpoint state between steps so a step-six failure resumes from step five rather than reburning the whole run's cost, which also gives you the audit trail per step (input, output, validation verdict) that turns 'the pipeline is flaky' into 'SQL generation fails on fiscal-quarter questions'.

Fifth, evaluate per step and end-to-end separately, because per-step metrics tell you where the 40 percent loss lives. Finally, place humans at the highest-leverage gate, typically approving the analysis plan or reviewing the final artifact, not clicking OK between every step, which numbs reviewers and adds latency without safety. Reliability here is an engineering property of the harness around the models, not a property you prompt into existence.

Answer

This is the payment-grade correctness case, and the trap is promising exactly-once delivery, which does not exist across independent systems; what exists is at-least-once delivery plus idempotent application plus reconciliation, and opening with that reframe is what marks a senior answer. The design. Every invoice gets a deterministic idempotency key derived from its business identity (source system, invoice ID, version), minted when the invoice is approved, not when the post is attempted, so retries at any layer reuse the same key.

The bridge maintains its own state store, a posting ledger recording each key's status (pending, posted, confirmed, failed) with the payment system's returned transaction reference, and transitions are the only source of truth the bridge trusts about itself. The dangerous window is the crash between 'sent the payment request' and 'recorded the response': you cannot eliminate it, so you engineer around it, before sending, write an intent record; on restart, any intent without a recorded outcome triggers a query to the payment system by idempotency key ('did you see this?') before any resend. This requires the payment side to support idempotent posting or lookup-by-reference; if it supports neither, you say so plainly and push for it, because correctness is impossible without one of them, and negotiating that API capability with the payment vendor is precisely the FDE's job.

Wrap the posting path in explicit state-machine transitions rather than ad hoc retries: at-least-once retries with backoff on network failures, no automatic retry on ambiguous business errors ('insufficient budget' must not be hammered), and a dead-letter queue with human resolution for everything ambiguous. Then the layer that saves careers: continuous reconciliation, a job that compares the procurement system's approved set, the bridge ledger, and the payment system's posted set three ways, every hour, alerting on any divergence, because the reconciler catches the failure modes you did not foresee, which is the only class of failure that matters after this much design. Close with blast-radius controls: a daily posting cap, an anomaly gate (today's total versus trailing average) that pauses posting and pages a human, and a documented manual replay procedure your champion's team can run without you.

Answer

The technical answer is change data capture; the graded answer is the migration path, because fifty live reports mean a big-bang cutover is professional malpractice. CDC first: tail the transactional database's log (Debezium or the cloud provider's native CDC into a stream), land changes into staging, and apply them to the analytical store continuously. Log-based capture beats query-based polling because it sees deletes, captures intermediate states, and adds no load to the source, but it brings obligations you must name: schema changes upstream now break the pipeline in real time rather than at tonight's batch, so schema-change handling (tolerant consumers, an alerting contract with the DBA team, a replay path) is part of the design, not an afterthought.

So is initial state: CDC gives you changes, and you need a consistent snapshot plus log position to start from, which modern CDC tooling coordinates but which you verify rather than assume. Now the migration path, which is where the question is really decided. Phase one: run CDC in parallel with the nightly batch, writing to new tables, touching nothing the reports read; use the period to burn in the pipeline and, critically, to run automated equivalence checks, every morning, compare yesterday's batch output against the CDC-built state for the same logical day, and chase every diff to root cause (the diffs will teach you the batch job's undocumented filters and timezone quirks, which the fifty reports silently depend on).

Phase two: expose the CDC tables under new names to a handful of friendly report owners, keeping the batch as the system of record. Phase three: cut reports over in cohorts behind views, the reports query views that today point at batch tables and tomorrow point at CDC tables, so cutover and rollback per cohort are a view definition change, not fifty report edits. Keep the batch running as a shadow for weeks after full cutover, with the equivalence check as your regression alarm, and only then decommission. Two honest caveats close it: some reports depend on batch semantics (end-of-day snapshots), so those get materialised snapshot views on top of the stream rather than raw freshness; and five-minute staleness is a pipeline SLO you must now monitor forever, lag dashboards, alerting, and a documented catch-up procedure become deliverables alongside the pipeline itself.

Answer

Multi-provider is the default enterprise posture in 2026 (resilience, negotiation leverage, per-task fit, data-residency routes), and the design question tests whether you treat the gateway as serious infrastructure. Core structure: a single internal API that all application code calls, with the gateway owning provider adapters, credential management, and policy. Application teams request a capability tier ('fast-cheap', 'balanced', 'frontier', 'in-perimeter-only'), never a provider, which is the abstraction that makes everything else possible.

Routing policy lives in configuration: per-route model assignments driven by eval results, data-classification rules that force sensitive routes to the in-perimeter model regardless of quality preference, and per-tenant overrides where contracts demand them. Failover: health-check each provider (error rates, latency percentiles, rate-limit headroom), trip a circuit breaker on degradation, and fail over to the route's designated fallback, with two honesty requirements most designs miss. First, fallback responses differ in quality and behaviour, so mark degraded-mode responses in the trace and, for sensitive routes, prefer queueing or failing fast over silently answering with a weaker model; whether degraded answers are acceptable is a per-route business decision the customer makes, recorded in config, not an engineering default.

Second, prompts are not portable: each provider has its own formatting quirks, tool-call conventions, and refusal behaviours, so the gateway maintains per-provider prompt adaptations, and no fallback pair enters production before the eval suite has run against both sides, quality comparability is an eval artifact, not an aspiration. Cost control: per-route and per-team budgets enforced at the gateway (soft alert, then hard cap with a defined over-budget behaviour), spend attribution in every trace, and caching (exact-match plus provider prompt-cache exploitation) as first-class features, because the gateway is the only place in the architecture that sees all spend. Operationally: version-pin models per route with upgrades gated through the eval suite as regression tests, log every request with model, version, tokens, latency, and route for the capacity and renegotiation conversations, and keep the whole thing boring, an off-the-shelf gateway (LiteLLM-class, or the customer's platform-native router) beats a bespoke one unless policy needs demand custom code, and saying that trade-off out loud is part of the answer.

Answer

Entity resolution is the hardest recurring data task an FDE meets, and the answer is graded on method: blocking, multi-signal scoring, and a review tier, not one clever fuzzy match. Method first. Normalise aggressively before comparing: case-fold, strip punctuation, expand or remove legal suffixes (Pvt Ltd, Private Limited, LLP, Inc), normalise addresses structurally (pincode extraction does most of the work in Indian data), and canonicalise GST or tax IDs where present, because a matched tax ID settles the question outright and should short-circuit everything else.

Then blocking: comparing 60,000 against 45,000 records is 2.7 billion pairs, so you only compare within candidate blocks, same pincode, same normalised name prefix, same tax-ID fragment, and you overlap multiple blocking strategies to cover records that fail any single one. Missing the blocking step is the answer's classic disqualifier. Scoring: for each candidate pair, combine similarity signals with per-field weights, token-set name similarity (robust to word order and abbreviation), address similarity, phone and email exact matches after normalisation, and calibrate thresholds on a labelled sample you create with the customer's procurement team (an afternoon of labelling 200 pairs beats any default threshold).

Output three tiers, not two: auto-merge above the high threshold, auto-distinct below the low one, and a human review queue between, sized honestly, if the queue is 8,000 pairs, you tune blocking and weights or negotiate review staffing, but you do not silently widen the auto-merge band, because every false merge in a supplier master becomes a mispaid invoice. Survivorship completes the job: for each cluster, a golden record built by field-level rules (most recent address, most complete bank details, the tax-ID-bearing record wins identity), with lineage back to every source record, because the customer's auditors will ask where a bank account number came from. Mention the industrial path: at larger scale or for ongoing sync you would reach for a linkage framework (splink's probabilistic scoring is the current standard) and persist match decisions so tomorrow's records resolve incrementally rather than re-clustering the world. The code shows the skeleton: normalisation, blocking, scoring, tiering.

import re
from itertools import product
from rapidfuzz import fuzz

SUFFIX = re.compile(r"\b(pvt|private|ltd|limited|llp|inc|co)\b\.?", re.I)

def norm_name(n):
    n = SUFFIX.sub("", n.lower())
    return re.sub(r"[^a-z0-9 ]", " ", n).split()

def norm_gst(g):
    g = re.sub(r"\W", "", (g or "").upper())
    return g if len(g) == 15 else ""

def block_key(rec):  # multiple keys per record widen recall
    toks = norm_name(rec["name"])
    yield "pin:" + (rec.get("pincode") or "")
    if toks:
        yield "np:" + toks[0][:4]
    if norm_gst(rec.get("gst")):
        yield "gst:" + norm_gst(rec["gst"])[:10]

def score(a, b):
    ga, gb = norm_gst(a.get("gst")), norm_gst(b.get("gst"))
    if ga and gb:
        return 1.0 if ga == gb else 0.0   # tax ID settles it
    s = 0.6 * fuzz.token_set_ratio(" ".join(norm_name(a["name"])),
                                   " ".join(norm_name(b["name"]))) / 100
    s += 0.25 * (a.get("pincode") == b.get("pincode") and 1 or 0)
    s += 0.15 * (a.get("phone") and a.get("phone") == b.get("phone") and 1 or 0)
    return s

def resolve(sap, proc, hi=0.90, lo=0.65):
    blocks = {}
    for src, recs in (("sap", sap), ("proc", proc)):
        for r in recs:
            for k in block_key(r):
                blocks.setdefault(k, {"sap": [], "proc": []})[src].append(r)
    merge, review = [], []
    for b in blocks.values():
        for a, p in product(b["sap"], b["proc"]):
            s = score(a, p)
            if s >= hi:
                merge.append((a["id"], p["id"], s))
            elif s >= lo:
                review.append((a["id"], p["id"], s))
    return merge, review  # review tier goes to humans, never auto-merged

Answer

This tests incident command under access constraints, and the strongest answers run three tracks in parallel rather than sequentially: communication, diagnosis-at-a-distance, and access restoration. Communication first, because in enterprise incidents trust decays faster than uptime: within the first thirty minutes, someone (you, until relieved) sends the customer a first status note, what is known, what is being done, when the next update comes, and then keeps that update cadence religiously even when the update is 'no change'. Silence is what turns a technical incident into an executive escalation; the COO email means that already happened, so your leadership needs a two-line brief they can respond with, and you write it for them.

Diagnosis-at-a-distance: no production access does not mean no information. Whatever telemetry legitimately exits the VPC, dashboards, exported metrics, alert payloads, health-check endpoints visible from outside, gets mined first to classify the failure: is it the application, the model-serving layer, an upstream dependency (expired credentials and certificates are disproportionately common Saturday-night causes because they fail on schedule, not on load), or the customer's own infrastructure? A precise hypothesis transforms the access problem, because 'please restart the inference pod and paste the last 200 lines of this log' is executable by any customer engineer with keyboard access under your guidance on a screen-share, whereas 'give me access so I can look around' is a security exception nobody grants at midnight.

Access restoration in parallel: the unreachable engineer is a process failure, not a person failure, so you work the customer's own escalation tree (their NOC, their on-call manager, the security team's break-glass procedure, which most regulated enterprises have precisely for this) rather than waiting on one phone. If a break-glass path grants you temporary supervised access, every action goes into the incident log, both for their audit and your post-incident credibility. Afterwards, the part that separates senior candidates: the postmortem's real findings are usually organisational, single-keyholder access, no runbook executable by the customer's own staff, no agreed severity-response contract, and you leave the incident having fixed those, a tested runbook the customer's engineers can run, at least two access holders, monitoring that pages both sides, and an agreed comms protocol, because the second Saturday-night incident being boring is the actual deliverable.