Practice AI and FDE
interview questions.

Clarify first

Which repeated task takes the most operator time, and what happens when it is done incorrectly?

1. Observe a complete case. Follow an operator from opening a ticket to resolving it. Record the current handling time, required systems, and rework. Select one frequent task with a clear finish, such as drafting a policy-backed response for review.
2. Write the acceptance agreement. Agree on eligible ticket types, an error definition, reviewer workload, and a baseline comparison. Mark target improvements as pilot goals, not measured savings. Name the customer owner who will judge the result.
3. Ship one measurable slice. Build a read-only draft flow using approved examples, with the operator retaining the send action. Evaluate held-out tickets, capture rejected drafts, and finish with a go, revise, or stop decision supported by the observed results.

The tradeoff: A narrow pilot covers fewer tickets but lets you attribute changes and learn whether the workflow helps. A broad chatbot may demonstrate more features without establishing value.

Clarify first

Which fields drive a downstream decision, and which errors require review?

1. Inspect before promising coverage. Sample across templates, dates, scan quality, and common exceptions. Track whether errors come from missing source data, extraction, or interpretation. Ask for the minimum authorized data needed to test those categories.
2. Build a small reviewed set. Have domain staff label the required fields and mark genuinely ambiguous cases. Reserve a separate sample for validation. Report coverage alongside field accuracy so discarding difficult documents cannot look like an improvement.
3. Deliver with a review queue. Start with supported templates and show extracted values beside source locations. Route unsupported or ambiguous records to operators. Quantify review effort and maintain a backlog of source-data fixes with customer owners.

The tradeoff: Restricting the supported document set can make the pilot useful sooner, but the customer must see how much work remains outside that boundary.

Clarify first

What decision does the demo need to enable, and which new request is essential to that decision?

1. Make the new boundary visible. Explain that retrieval from a new data domain and modifying orders each add integration and acceptance work. Show the current scope alongside the requested changes, their dependencies, and the evidence already available.
2. Offer a concrete sequence. Keep the approved search flow as the demonstrable delivery. Offer an order-update design walkthrough or a clearly labeled test-environment prototype only if it serves the decision. Put production writes behind a separate scoped milestone.
3. Confirm the trade in writing. Agree on what is deferred, the next owner, and which acceptance checks must precede access expansion. Give the sponsor an updated plan they can communicate rather than a technical objection without an alternative.

The tradeoff: A small addition can improve the customer conversation, but combining untested permissions and writes can undermine the original delivery. Decide using the demo's purpose and remaining verification time.

Clarify first

Who owns document updates, application incidents, and model or prompt changes?

1. Transfer an operating contract. Document supported workflows, known limitations, permissions, versioned configuration, and what the customer accepted. Identify each ongoing task and a named team responsible for it, including data freshness and deletion.
2. Rehearse common failures. Ask the new operators to diagnose a failed ingestion, inspect a poor answer, and exercise a fallback in a test environment. Supply dashboards and a runbook organized around symptoms, evidence, and reversible recovery steps.
3. Make changes reviewable. Provide the evaluation set, its access rules, release checks, and rollback procedure. Explain how new failure examples enter the suite. Agree on how future work becomes reusable product improvements rather than an undocumented customer-specific patch.

The tradeoff: Extensive documentation is expensive to maintain. Prioritize the actions the receiving team must perform and verify that the handover actually enables them.

Clarify first

Was the exception in the exact context sent to the model, or only somewhere in the source document?

1. Inspect the actual evidence path. Reproduce the case with a redacted trace. Follow the exception through extraction, chunking, candidate retrieval, reranking, and final context assembly. A correct document ID does not establish that the decisive sentence reached generation.
2. Test the failing stage. If the exception is absent, inspect chunk boundaries and candidate coverage. If present, test whether the answer preserves both the rule and exception with reduced distracting context. Change one factor at a time and retain the original failure as a regression case.
3. Judge claims, not citation presence. Check whether each material claim follows from the accessible passage. Include negative examples with valid citations but false statements. Review abstention when the policy cannot support an answer.

The tradeoff: More retrieved text can recover an exception but can also add conflicting policy versions. Measure evidence completeness and answer correctness together.

Clarify first

Which queries require multiple cells, a heading, or a footnote to be interpreted correctly?

1. Define an evidence unit. Identify complete units for the target queries: a procedure with prerequisites, or a table row with headers and applicable footnotes. Preserve source locations and document versions so a reviewer can inspect the original context.
2. Compare concrete candidates. Try structure-aware boundaries and bounded parent-context expansion against the current splitter. Avoid treating one token length or overlap percentage as universally correct. Keep extraction, embeddings, and evaluation queries fixed during the first comparison.
3. Evaluate downstream use. Label whether each retrieved result carries enough information to answer. Then inspect generated answers, context size, and latency. Include long tables and exception-heavy procedures in a held-out set before selecting the new default.

The tradeoff: Larger evidence units retain meaning but may bring irrelevant rows. Smaller searchable units plus controlled surrounding context are another option to test.