The RFC Process: Formalizing Technical Decisions
An RFC (Request for Comments) is a formal document for proposing a major technical change, creating a public record of the decision. It's used for big shifts like adding a new design system component or changing a core API.
Why it exists
The RFC process was created to solve the problem of making significant, cross-cutting technical decisions in a way that is transparent, well-documented, and gathers input from all stakeholders. It avoids informal, hard-to-track decisions and creates a durable record of the 'why' behind a change.
The mental model
Think of an RFC not as a request for permission, but as a structured argument. It's a formal proposal that says, "Here is a well-thought-out solution to an important problem, along with its alternatives and tradeoffs. Please review it and help me find the flaws before we commit." It shifts the conversation from unstructured chat to a focused, written debate on a single artifact.
How it works
An engineer or team authors a document detailing a proposed change. This document typically includes the problem statement, the proposed solution, alternatives considered, and potential drawbacks. It's then shared with a wider group for a period of review and comments. Feedback is gathered, the proposal is revised, and eventually, a decision is made to accept, reject, or defer the proposal. The final RFC serves as the official documentation for the change.
When to use it
Use the RFC process for decisions with a large blast radius that require broad consensus. Examples include adding a new, complex component to a shared design system, deprecating a widely used API endpoint, adopting a new coding standard across a department, or changing a core architectural pattern that multiple teams depend on.
When not to use it
Avoid RFCs for small, localized changes that affect only one team or a small part of the codebase. Using it for minor refactors, bug fixes, or small feature additions creates unnecessary overhead and slows down progress. The process is for decisions that have long-term consequences, not for everyday development work.
One canonical example
The original RFCs define the internet's core protocols; for example, RFC 791 defines the Internet Protocol (IP). In a company setting, a design system team might publish an RFC to introduce a new "DataGrid" component. The document would outline its API, state management, and accessibility requirements for review by all product teams before it is built and adopted.
Interview question
Which scenario most strongly indicates that a technical decision should be formalized via an RFC?
- a.A proposed change will impact multiple dependent teams and establish a new architectural pattern.Correct
- b.A team needs to choose between two competing third-party libraries for a new microservice.
- c.A critical bug fix requires a temporary workaround that deviates from established coding standards.
- d.A new feature requires significant refactoring within a single team's codebase.
Why? this is the answer
The card states RFCs are for "decisions with a large blast radius that require broad consensus" and gives "changing a core architectural pattern" as a prime example. Option A directly aligns with these criteria, indicating a major, cross-cutting decision, whereas other options describe more localized or temporary changes.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on process — each one lists the topics its interview covers.
See open roles