Q302: RFCs Technical Proposals and Cross Team Alignment

What Interviewers Want To Evaluate

Interviewers want to know whether you can move complex technical decisions through an organization.

They are checking clarity, stakeholder alignment, proposal writing, trade-off communication, feedback loops, decision ownership, migration planning, and how you avoid endless discussion.

Short Interview Answer

An RFC is a structured proposal for a meaningful technical decision. I would include context, goals, non-goals, requirements, proposed design, alternatives, trade-offs, rollout plan, risks, observability, migration, ownership, and open questions. A good RFC aligns teams before implementation, gives reviewers specific things to evaluate, and ends with a clear decision, not a permanent discussion thread.

Detailed Interview Answer

RFC stands for request for comments.

In practice, it is a tool for shared thinking.

Use it when a decision affects:

multiple teams
shared architecture
developer workflow
user-facing reliability
security posture
long-term maintainability
large migration cost

Do not use RFCs for every small component tweak.

RFC Structure

A useful RFC contains:

summary
context
problem
goals
non-goals
requirements
proposal
alternatives
trade-offs
rollout
migration
testing
observability
risks
ownership
timeline
open questions

The structure reduces ambiguity.

Goals and Non-goals

Goals tell reviewers what the proposal is optimizing.

Non-goals prevent scope expansion.

Example:

Goal: support side-by-side JS and TS practice consoles.
Goal: preserve keyboard shortcuts and copy actions.
Non-goal: build a full IDE.
Non-goal: support backend language execution in this phase.

This protects delivery.

Alternatives

Alternatives show judgment.

Examples:

Use native textarea
Use CodeMirror
Use Monaco
Use embedded external sandbox
Use server-side execution
Use client-side transpilation

The proposal should explain why one option fits the constraints better.

Stakeholders

Identify who must review.

Examples:

frontend platform
design system
security
privacy
backend API
SRE
analytics
product
QA
accessibility

Invite the right reviewers early.

Too many reviewers can slow decisions.

Too few can miss risk.

Feedback Handling

Good RFC feedback is specific.

Useful:

This migration plan misses old API clients.
This metric does not capture task completion.
This edge cache rule can leak personalized content.

Less useful:

I do not like this library.
This feels weird.
Can we make it future-proof?

Authors should summarize feedback and resolve threads with decisions.

Decision Closure

An RFC needs an outcome.

Possible outcomes:

accepted
accepted with changes
rejected
deferred
superseded

Endless open RFCs create uncertainty.

Interview Framing

Say:

I use RFCs when the cost of misalignment is high. The document should make context, alternatives, trade-offs, rollout, and ownership explicit.

Then add:

A good RFC process creates a decision and a shared memory, not just a long comment thread.

Common Mistakes

• Writing too much background and no decision.
• Skipping non-goals.
• Asking reviewers to infer trade-offs.
• Inviting stakeholders after implementation.
• Never closing the RFC.
• Treating objections as blockers without clarifying risk.
• Using RFCs for changes that need normal code review only.

Learning Studio Example

An RFC for saved cloud progress could include:

anonymous local progress today
future authenticated sync
privacy model
data schema
offline conflict behavior
API contract
rollout plan
account deletion rules
observability
export/reset controls

This decision affects frontend, backend, privacy, and user trust.

Final Mental Model

RFCs are alignment tools.

They should make technical decisions:

clear
reviewable
bounded
owned
recorded
actionable