Practice AI and FDE
interview questions.

Clarify first

Which facts are binding constraints, which were corrected, and which are historical discussion?

1. Separate state from narration. Store explicit current constraints, decisions, and unresolved questions in a scoped task record. Retain provenance and corrections. Use a conversational summary for background, not as the sole store of requirements that determine acceptable results.
2. Build a bounded prompt. Keep the current request, binding constraints, recent relevant turns, and targeted evidence. Budget tool results and output space as well as messages. Retrieve older detail when needed rather than keeping every previous itinerary in the active context.
3. Test retention under revision. Create long conversations with corrected preferences, distractors, and conflicting old plans. Check whether generated itineraries satisfy the latest constraints after compression. Compare token usage and task success on the same conversations.

The tradeoff: Structured state takes more application work and can itself be wrong. Validate updates and retain enough provenance to inspect how a constraint entered the record.

Clarify first

Is the preference global, specific to one project, or only for the current task?

1. Define a scoped record. Represent the owner, project scope, preference key, revision, source, and validity. Derive user identity from authenticated context. A retrieved sentence should not override a more authoritative correction simply because it ranks highly.
2. Propagate the correction. Supersede the old value in the authoritative store and update or exclude its derived retrieval records. Invalidate affected cached context. Preserve an audit trail only under an appropriate retention policy, not as another active preference candidate.
3. Test the complete lifecycle. Verify recall before and after correction, across sessions and projects. Test expiration, deletion, ambiguous scope, and other users' records. Ask for clarification when a correction does not identify which project it applies to.

The tradeoff: Keeping more memories can improve recall but increases conflict and maintenance work. Store information with a defined use and lifecycle.

Clarify first

Which request types create most spend, and which mistakes are expensive for operators?

1. Establish cost per useful outcome. Measure request mix, input and output tokens, cache use, failed calls, and accepted drafts. Use current provider prices with the relevant conditions. Avoid inferring production savings from headline token prices alone.
2. Compare policies on fixed cases. Evaluate the existing model, a cheaper candidate, and a simple routing rule on the same held-out tasks. Slice results by complexity, language, and exception handling. Include the router's cost and mistakes, not just the selected model's answer.
3. Release with a quality boundary. Define which failures trigger escalation and test whether the validator catches them. Introduce the policy gradually, monitor accepted outcomes and total spend, and retain a reversible configuration. Do not treat model self-confidence as calibrated correctness.

The tradeoff: Routing can preserve difficult-case quality, but an inaccurate router and repeated escalation may erase the savings. A simpler model change may be better if it passes the actual workload.

Clarify first

What does this provider cache, and what are its eligibility, lifetime, write, and read billing rules?

1. Inspect the request shape. Compare consecutive serialized requests. Look for changing timestamps, tool order, formatting, and user data inside the intended reusable prefix. Confirm the endpoint and model support the requested caching behavior.
2. Separate stable and variable content. Place eligible shared instructions and tool definitions in a stable order, with per-request content afterward where the provider's rules permit. Keep version changes deliberate. Do not move sensitive data across users merely to improve reuse.
3. Measure warm and cold behavior. Run controlled repeated requests within the relevant cache lifetime. Inspect cache-specific usage and compare total billed reads, writes, and uncached tokens. Report results for this workload rather than assuming a universal discount.

The tradeoff: Maintaining a stable prefix can improve reuse but must not freeze a policy that needs updating. Correctness and version invalidation remain part of the design.