Walk me through how you would write a technical proposal for a significant platform investment so that it gets a decision in one meeting rather than a fourth round of questions.

What the interviewer is testing

Whether you understand that a proposal is not an explanation, it is a request for a specific decision from a specific person, and whether you know what that person needs in order to say yes without fear. Candidates who describe document structure have answered a formatting question.

The clarifying questions that change the answer

• Who decides, and what are they accountable for? A CTO approving a budget, an architecture group approving a direction and a team lead approving their own quarter need different documents.
• What is the cost of delay? If deferring costs nothing, the document must create urgency honestly or accept a slow decision. If it costs a migration window, that goes in the first paragraph.
• Is this reversible? The single most useful framing available: a reversible decision deserves a fast, cheap process, and stating that explicitly is what unblocks cautious approvers.

A strong answer's arc

1. Open with the decision requested and the money. "I am asking for approval to spend two engineers for one quarter on X. Here is what we get and what happens if we do not." Approvers read the first paragraph properly and skim the rest.
2. State the problem in the organisation's currency, not in technical terms. Cost, risk, delivery speed, customer impact, regulatory exposure. Pick the one that the approver owns.
3. Give options with consequences, including doing nothing, and say which you recommend. A document with one option reads as advocacy and invites the question "what else did you consider?"
4. Make the reversibility and the exit explicit. What we would see in eight weeks that would tell us to stop, and what it costs to stop. This is the section that converts a nervous approver, and it is missing from most proposals.
5. Pre-wire the objections. Talk to the two or three people who can block it before the meeting, put their concerns in the document in their words, and answer them. A meeting is for confirming a decision, not for discovering opposition.

Common weak answers

• "I'd include a detailed technical design." Depth in the wrong place is why proposals get deferred. The approver cannot evaluate your sharding scheme and will ask for more detail because that is the only safe response to a document they cannot assess.
• "I'd present it and take questions." Presenting a decision that nobody has read beforehand fails for a structural reason, not a presentational one: sensible people do not commit to something they have seen for 15 minutes, so the meeting produces a request for a second meeting. Amazon's written-narrative practice, public since around 2018, exists to remove exactly this failure by putting 20 minutes of silent reading at the start.

What a strong answer adds

A named decision date and what happens if no decision is made by then. Most proposals die of neutrality rather than rejection, and the default path needs to be stated: "if there is no decision by the end of the month we will continue on the current platform and revisit in Q3, which costs approximately X." That sentence converts a deferral from a free option into a choice with a price, which is the only thing that reliably produces an answer.