Technical Vision & RFC Process
What Interviewers Actually Want to See
When an interviewer asks about technical vision or RFCs, they're not looking for a writing sample. They're evaluating how you think about influence without authority. At staff level and above, you rarely get to mandate technical direction. You have to persuade people. The RFC is just the artifact. The real skill is the process around it: the conversations you have before writing, the way you incorporate feedback, and how you handle it when smart people disagree with you.
Think of it this way. A senior engineer writes good code. A staff engineer writes good documents that change how teams build software. The interview is testing whether you can do the second thing.
The RFC Lifecycle: Problem, Alternatives, Recommendation, Decision
A strong RFC follows a predictable structure, and interviewers expect you to know it:
-
Problem Statement - What's broken, what's the cost of inaction, and who's affected? This section should be compelling enough that someone who reads only this part agrees the problem is worth solving. Quantify the impact. "Our deploy pipeline takes 45 minutes and we deploy 12 times a day" is better than "deploys are slow."
-
Alternatives Considered - List at least three options, including doing nothing. For each one, lay out the pros, cons, estimated effort, and risks. Be genuinely fair to alternatives you don't prefer. If a reader can tell which option you favor just from the tone of the alternatives section, you need to rewrite it.
-
Recommendation - State your preferred approach and explain why. Reference the evaluation criteria you established in the problem statement. Acknowledge what you're giving up with this choice.
-
Decision and Next Steps - After the review, document the actual decision (which may differ from your recommendation), who made it, and what the first concrete milestone looks like.
Building Consensus Without Authority
The hardest part of the RFC process isn't writing. It's politics. Here's what works in practice:
-
Pre-socialize with skeptics first. Find the person most likely to disagree with your approach and talk to them before you write anything. Understand their concerns. Incorporate their perspective. When they see their input reflected in the RFC, they become allies instead of blockers.
-
Separate "I disagree with the approach" from "I wasn't consulted." A surprising amount of RFC friction comes from people feeling excluded from the process, not from genuine technical disagreement. Make a list of everyone who should have input and reach out to them individually.
-
Know when to disagree and commit. You won't always get consensus. Sometimes two reasonable people look at the same evidence and reach different conclusions. At that point, you need a decision-maker, a clear timeline, and the maturity to support the chosen direction even if it wasn't yours.
Good RFCs vs Bad RFCs: Concrete Examples
A bad RFC reads like a blog post advocating for a technology. It starts with the solution, works backward to justify it, and glosses over alternatives. You've seen these. "We should adopt Kubernetes because it's the industry standard." That's not analysis. That's marketing.
A good RFC starts with pain. "Our current deployment process requires 3 hours of manual steps per release, has caused 4 incidents in the last quarter, and is the number one complaint in our developer experience survey. Here are four ways we could address this, ranging from automating the existing process to rebuilding on a container orchestration platform. Here's how each option scores against our criteria of reliability, developer experience, and operational cost."
The difference is night and day. In interviews, describe your RFCs the second way. Show that you started with the problem, explored the space honestly, and arrived at a recommendation through structured thinking rather than personal preference.
Sample Questions
Describe a technical vision document you wrote. How did you get buy-in?
They want to see the process, not just the output. How did you socialize the idea before writing it? Who did you talk to first? How did the document evolve through feedback? Show that you treat a vision doc as a living artifact, not a declaration.
You believe your team should rewrite a core service in a new language. Walk me through how you'd drive that decision.
This tests structured decision-making, not advocacy. They want to see you weigh alternatives, quantify costs, define success criteria, and build a decision framework that others can evaluate. If you just pitch the rewrite, you've failed.
How do you handle strong disagreement on an RFC from a peer Staff engineer?
This probes your ability to navigate technical conflict. Do you understand when to seek consensus vs when to disagree and commit? Can you separate ego from the technical argument? Show that you know when to push and when to yield.
Evaluation Criteria
- Writes RFCs that clearly separate problem definition from proposed solution
- Builds consensus across teams before and during the formal review process
- Handles disagreement with peer engineers constructively and without ego
- Scopes multi-quarter technical work into concrete milestones with decision points
- Communicates tradeoffs in terms that resonate with both engineering and business stakeholders
Key Points
- •The RFC lifecycle has three distinct phases: draft (where you pressure-test your thinking), review (where you gather input and address concerns), and decision (where you commit to a path). Skipping any phase weakens the outcome.
- •Stakeholder mapping matters. Before you write a single line of the RFC, figure out who will be impacted, who has veto power, and who needs to feel heard. A technically perfect RFC that blindsides a key stakeholder will fail.
- •Not every decision needs an RFC. If the change is easily reversible, scoped to one team, and low risk, just make the call. Writing an RFC for trivial decisions burns organizational trust in the process.
- •Separate the problem statement from the solution. The best RFCs spend as much time defining why the problem matters as they do proposing how to solve it. If people disagree on the problem, no solution will satisfy them.
- •Measure the success of technical initiatives explicitly. Define what 'done' looks like before you start, including both technical metrics and business outcomes. Otherwise you'll ship something and never know if it worked.
Common Mistakes
- ✗Writing an RFC that's really a solution pitch in disguise. If you've already decided the answer, people will notice, and they'll disengage from the review process.
- ✗Not socializing before the formal review. If the first time your peers see the RFC is in the review meeting, you've already lost. The best RFCs have no surprises at the review stage.
- ✗Treating RFC approval as the finish line. Approval means you have permission to start, not that you're done. The hard work of execution, iteration, and course correction comes after.
- ✗Ignoring the 'do nothing' option. Every RFC should explicitly address what happens if you don't do this work. Sometimes the honest answer is that doing nothing is acceptable, and that's valuable information.