Context Engineering Interviews: Preserve Correction...

An assistant remembers the project name but forgets that the candidate corrected their responsibility. This is a context failure even when the summary is fluent. Anthropic’s context-engineering article discusses managing a finite context budget. Our worked example asks a narrower interview question: which correction must survive compaction, and how can you prove it did?

Give every source a job

Separate the current request, recent real turns, durable user facts, and supporting retrieval. State which source can define identity, which can only explain a concept, and which is allowed to be stale. Source provenance is more useful than a vague “memory” label.

Compress for continuity, not convenience

A summary should preserve decisions, corrections, unresolved questions, and ownership. Protect the current question and recent real turns before trimming optional background. Validate that the summary still points to its source; otherwise a shorter context can become a confident distortion.

Design recovery before optimization

Define what happens when retrieval fails, a summary is stale, or a provider times out. A safe fallback restores the last verified context and explains the gap. This is usually a stronger interview answer than promising an ever-larger context window.

Design a replay with a correction, a follow-up, and a stale write

Use a fictional dialogue. First, the candidate says, “I worked on the database migration.” Later they clarify, “I owned the rollback script; another engineer designed the migration.” The interviewer then asks, “What did you personally decide?” The correct answer should discuss the script, not claim ownership of the overall design.

Give the real turns stable source identifiers and chronological order. A background summary starts before the clarification and completes afterward. This creates the important race: newer raw evidence exists, but an older job is trying to publish a derived memory.

A plausible summary can still be stale

Do not accept a summary merely because it is well-formed. Check the source interval and version it summarizes. If it predates the correction, preserve the newer turn alongside it or reject replacement according to the existing memory contract. The summary should not silently become more authoritative because it is shorter.

Nor should retrieved technical background redefine the candidate’s role. A general migration guide might explain rollback strategies, but it cannot prove this person owned the migration. Separate explanatory material from identity and experience evidence before constructing the final request.

Test the answer, not just the summary field

Inspect the actual input passed to the answer model. The current question must be visible, the latest correction must be available, and the source order must remain clear. A database row saying “summary saved” does not prove that the next response used it correctly.

Create variants where summary generation times out, an older job finishes last, or a later turn says the candidate also reviewed a checklist. The last case adds a responsibility; it does not necessarily cancel the earlier limitation. A system that overwrites every old fact with the newest sentence can lose useful truth too.

The recovery path should use evidence that remains valid for the current session and permissions. “Last known good” cannot mean restoring a revoked document or a different interview’s material. Keep the current question and recent raw turns when a derived summary cannot be trusted, and disclose a missing fact rather than completing a biography from general knowledge.

A concise interview answer is: “I would replay the late-summary race, examine the final model input, and verify that the answer keeps personal ownership limited to the rollback script.” Then state what is still probabilistic: source preservation can be tested deterministically, but natural-language answer quality needs repeated evaluation and review.