Structure an executive-ready RFC summary for a major architectural migration

WHAT THIS TESTS: This question tests whether you treat an RFC as a decision instrument rather than a design diary. Senior engineers are skeptical of migrations that promise future benefits but hide present costs. The interviewer wants to see if you can front-load the decision ask, use evidence traceability, and make tradeoffs explicit so leaders can approve or redirect without a meeting.

A GOOD ANSWER COVERS: First, an active-voice problem statement and decision ask in the opening sentence, such as we propose decomposing the checkout monolith into three services within Q2 to reduce deployment failures by forty percent, and we request approval to staff a two-pilot team. Second, a two-tier structure with an executive lead summary that lists problem, context, options, recommendation, expected impact, and the ask, followed by appendices with architecture notes and benchmarks for engineers. Third, options analysis with at least two viable alternatives and traceable evidence, not just a single favored path. Fourth, explicit tradeoffs that state what improves and what worsens, such as increased operational complexity or temporary latency during the cutover. Fifth, concrete acceptance criteria with owners and timelines so done is unambiguous.

COMMON WRONG ANSWERS: Narrative drift is the biggest red flag, where the candidate spends minutes on background before stating the ask. Another failure is burying the recommendation beneath implementation details like schema changes or library versions. Passive voice and vague verbs like consider or evaluate weaken commitment. Omitting what worsens, such as higher infrastructure cost or team retraining, signals a lack of rigor. Undefined scope or missing acceptance criteria make the proposal unbounded and unmeasurable.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a senior engineer who rejects the migration due to operational risk, or how you would time-box a pilot to gather more evidence. They might also probe how you keep the document scannable for executives while preserving technical depth for staff engineers, or how you define rollback criteria if acceptance tests fail.

ONE CONCRETE EXAMPLE: A strong lead summary reads as follows. Problem: the monolith deploys weekly with a twenty-three percent rollback rate. Context: feature teams block on each other during releases. Options: one, modularize in place; two, strangler fig migration to services; three, status quo. Recommendation: option two with a bounded pilot on the payments module. Impact: reduce rollback rate to under five percent and enable daily deploys within two quarters. Tradeoffs: temporary latency increase of ten to fifteen milliseconds and sixty hours of SRE training. Ask: approve a four-engineer pilot for six weeks with a go-no-go review on March fifteenth. Acceptance criteria: payments module runs dual-write with zero data loss and deploys independently in production.