Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Open with the decision, business context, scope, non-goals, deadline, owner, and constraints. State what new evidence could change the recommendation.
Establish scale assumptions
- Include explicit workload assumptions, current measurements, growth scenarios, skew, failure traffic, and confidence. Tie every large component to a quantified need.
Functional and non-functional requirements
- Separate functional outcomes from SLO, security, compliance, cost, operability, and migration. Rank constraints so reviewers see what is being optimized.
High-level architecture
- Show the simplest proposed boundaries, authority, major data flows, control and data planes, dependency ownership, and alternatives considered. Diagrams support decisions rather than replace text.
Data model and flow
- Document data classification, system of record, schemas, transaction boundaries, idempotency, ordering, retention, lineage, and deletion. Include how data moves during migration and rollback.
Consistency and transaction boundaries
- Name invariant owners and precise guarantees per operation. Avoid CAP slogans; explain what users observe during delay, partition, conflict, and repair.
Failure modes and recovery
- Provide a failure table covering dependency slowdown, overload, bad deploy, region loss, data corruption, control outage, and operator error with containment and recovery.
Security and privacy
- Include threat model, trust boundaries, identity, authorization, tenant isolation, key and privacy lifecycle, privileged operations, and unresolved risk owners.
Observability and SLOs
- Define SLOs, signals, dashboards, alert ownership, correctness reconciliation, capacity gates, and how success will be measured after launch.
Capacity and cost
- Show low, expected, and high cost; unit economics; staffing and on-call; vendor risk; and opportunity cost. Name what will be decommissioned.
Alternatives and trade-offs
- Compare credible alternatives against the same criteria, including do nothing. State why the chosen option wins now and when another would become preferable.
Evolution and migration
- Lay out stages, compatibility, backfill, canary, rollback limits, exit criteria, owners, and decision checkpoints. Temporary bridges have removal dates.
What Staff and Principal candidates should emphasize
- Staff-quality RFCs make uncertainty and accountability legible. The review should decide, assign risk, or request targeted evidence—not become an open-ended writing contest.
Decision trade-offs
RFC scope
Option A
Describe the complete future architecture
Option B
Document the current decision and staged path
Recommendation:Center the bounded decision and its migration; future-state context is useful only where it changes today’s choice.
Review process
Option A
Large synchronous meeting first
Option B
Async domain review followed by a decision meeting
Recommendation:Collect specialized evidence asynchronously, resolve factual gaps, then use the meeting for contested trade-offs and commitment.
Follow-up interview questions
- 01What belongs in non-goals?
- 02How many alternatives are credible enough to include?
- 03Who signs off security and operational risk?
- 04What outcome means the RFC succeeded?
Common weak answers and mistakes
- 01Leading with a detailed diagram before stating the decision and constraints.
- 02Presenting one preferred solution and straw alternatives.
- 03Omitting migration, ownership, and decommissioning.
- 04Using review as indefinite consensus rather than a decision mechanism.
Interviewer evaluation rubric
Produces a technology description with little business context, evidence, failure analysis, or execution ownership.
Frames decision, scope, assumptions, alternatives, risks, migration, SLO, cost, and owners clearly.
Makes invariants, uncertainty, failure, security, rollback limits, organizational impact, and success evidence explicit.
Uses the RFC to improve collective reasoning and produce a durable decision whose assumptions can be audited and revised.