architecture-interview

Architecture Interview

Analyze, review, or plan architecture alternatives through a structured interview when the user needs tradeoffs surfaced before implementation or Linear decision capture.

Philosophy

• Architecture is decision-making under constraints, not a tour of every possible pattern.
• The useful output names what is chosen, what is sacrificed, and what must be verified.
• For Jamie projects, capture durable decisions in Linear-ready notes instead of ADR files unless explicitly requested.

When To Use

• Choosing between viable system design alternatives.
• Surfacing tradeoffs before implementation starts.
• Producing a concise Linear decision note with assumptions, consequences, and validation criteria.

Avoid

• The user is asking for implementation details before the decision is framed.
• There is no real tradeoff or reversible architecture consequence.
• The output would create an ADR by default in a project that uses Linear for decisions.

Inputs

• Decision statement or architecture problem.
• Candidate options and known constraints.
• Dominant drivers such as simplicity, security, performance, cost, operability, or speed.
• Existing Linear issue, spec, plan, or decision context when available.

Outputs

• One-question-at-a-time interview path when the decision is still unclear.
• Recommended option with sacrifices, assumptions, risks, and validation criteria.
• Linear-ready decision note, not an ADR file, unless the user explicitly asks for ADR output.
• Schema-bound outputs include schema_version.

Workflow

1. Start by framing the decision in one sentence.
2. Ask only the next highest-leverage question when inputs are missing.
3. Compare 2-4 viable alternatives against explicit drivers and constraints.
4. Name the sacrifice and the non-obvious consequence of the recommended option.
5. Produce a concise Linear-ready decision note once the user approves the direction.
6. Fail fast if the decision is too vague to compare real alternatives.