Interview answer frameworks

Status: Complete. Last reviewed 2026-08-28.

Frameworks are compression tools, not scripts. State the important assumption, follow one causal thread, and stop when the question is answered. Use the linked scenario practice to rehearse them against incomplete evidence.

Definitions

Use name → mechanism → consequence → trade-off. A definition without mechanism is shallow; a mechanism without consequence sounds memorized.

Design questions

Use requirements → invariant → options → decision → failure/measurement.

Experience questions

Use context → responsibility → decision → evidence → learning.

Diagnosis

Use impact → observations → hypotheses → discriminating evidence → mitigation → root fix → verification.

• Establish affected users, time window, and business invariant before chasing a component.
• Keep observations separate from conclusions. Rank a few hypotheses; do not list every possible cause.
• Ask for the smallest query, trace, log, metric, experiment, or diff that distinguishes the leading hypotheses.
• During active harm, choose a bounded reversible mitigation before perfect diagnosis when evidence supports it.
• Verify user outcomes and system state, not only that one graph returned to normal.

Practice: old-worker migration and import retries.

Code review

Use invariant → supported finding → severity/confidence → missing evidence → smallest safe repair → verification → non-blocking feedback.

• Rank security, correctness, money/data loss, compatibility, and operability before maintainability and style.
• Cite the code path and plausible failure. Do not claim a missing control is absent system-wide when the diff cannot prove it.
• Mark a question as a question. Say what answer would promote it to a blocker or close it.
• Prefer the smallest repair that restores the invariant; separate larger redesign from merge-blocking work.
• Include tests at the boundary capable of proving the claim and the telemetry/rollout needed for residual production uncertainty.
• Label preferences and follow-ups explicitly so “non-blocking” has meaning.

Practice: tenant-scoped CRUD, cache keys and locks, and checkout.

Failure timeline

Use initial state → actor A → actor B/failure → durable boundary → retry/observation → violated invariant → recovery.

Write a numbered interleaving rather than saying “race condition” or “not idempotent.” Mark each database commit, broker acknowledgement, lease expiry, external effect, and timeout. A timeout changes knowledge, not necessarily remote state. Then place the repair at the strongest boundary and replay the same timeline to show why it converges.

Practice: checkout, import retries, and cache lease expiry.

Short-answer discipline

For a 60–120 second response, use answer first → one mechanism → one consequence/example → decision trigger.

• Lead with the distinction or decision, not background history.
• Name at most one or two assumptions that materially change the answer.
• Follow one representative failure path instead of reciting an API catalogue.
• Give evidence or a revision trigger: “I would change this if…”
• Stop. Offer depth only if the interviewer asks; completeness is not the same as saying everything known.

The definition, design, experience, diagnosis, and review frameworks can all be shortened this way. For example: “This is blocking because the cache key omits tenant identity; two tenants can receive the same authorized representation. I would key an authorization-neutral projection by tenant and resource, apply policy after retrieval, and add a cross-tenant feature test. I would confirm project IDs are not globally unique before finalizing severity.”

Follow-up discipline

• State assumptions rather than silently inventing requirements.
• Distinguish what must be correct from what can be eventually consistent.
• Name what evidence would change the decision.
• Prefer one concrete example to a list of fashionable terms.