What do interviewers evaluate in Written Communication questions?

Interviewers listen for signals like: Has a document you wrote actually changed a decision - and can you reconstruct the argument that did it? Do your docs steelman alternatives and quantify tradeoffs, or advocate for a conclusion you'd already reached? Do you use writing to think - finding the holes in your own reasoning before circulating - or only to announce?

gitGood.dev

StripeFoundational Premium

Rigorous Written Communication (Stripe Culture)

Stripe is a writing-first company - decisions travel in documents, not meetings. Interviewers test whether you can think on paper and change outcomes with a well-made written argument.

About this theme

Stripe is famously a writing company. Meetings open with silent reading of a pre-read, decisions are proposed and contested in long-form documents, API changes go through written review, and the internal bar for prose is high enough that Stripe runs its own book-publishing arm (Stripe Press) as a cultural statement. The underlying belief is that writing is thinking made inspectable: a document forces the author to find the holes in their own reasoning before spending anyone else's time, scales an argument across time zones without a meeting, and leaves a record that keeps decisions honest later. Interviewers probe for this directly and indirectly. Directly: they ask for times your writing changed a decision, how you structure a design doc, how you communicate across teams and time zones. Indirectly: they listen to whether you describe alignment as something achieved through artifacts (docs, RFCs, written decision records) or through charisma and meetings. The signal they want is that you treat writing as a tool for rigor, not decoration - your documents state the problem crisply, steelman the alternatives, quantify tradeoffs, make a recommendation, and invite written dissent. The anti-signals are candidates whose 'communication skills' turn out to mean talking, who circulate documents only to broadcast decisions already made, or who can't point to a single artifact that did real work in their career.

What interviewers are evaluating

→Has a document you wrote actually changed a decision - and can you reconstruct the argument that did it?
→Do your docs steelman alternatives and quantify tradeoffs, or advocate for a conclusion you'd already reached?
→Do you use writing to think - finding the holes in your own reasoning before circulating - or only to announce?
→Can you align people across teams and time zones asynchronously, without defaulting to a meeting?
→Do you invite and incorporate written dissent, or does feedback on your docs go nowhere?
→Is your writing calibrated to its reader - a one-pager for executives, full depth for the reviewing engineers?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time something you wrote changed a technical decision.
?Walk me through the best design doc you've written. What made it good?
?Describe aligning multiple teams on a contentious choice. How did you do it?
?Tell me about a time written feedback changed your own proposal.
?How do you communicate a complex technical tradeoff to a non-technical audience?
?Describe working effectively with a team in a very different time zone.
?Tell me about a time poor communication caused a problem, and what you changed afterward.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: the doc that stopped a rewrite

Prompt: "Tell me about a time something you wrote changed a technical decision."

Situation: My org had informally decided to rewrite our billing service in a new language - the momentum came from two influential engineers, a string of painful incidents in the old service, and a general feeling that the codebase was beyond saving. A kickoff was scheduled and headcount was being sketched. I believed the rewrite would fail: the incidents traced to two specific subsystems, not the language, and we'd be freezing a revenue-critical service for a year to fix the wrong variable.
Task: Arguing this in the kickoff meeting would have been me against the room's momentum. I decided the only way to test my belief honestly - and to change the outcome if I was right - was to write the case so clearly that it could be attacked in the open, asynchronously, by everyone with context.
Action: I spent three evenings on a six-page document. Structure mattered: page one stated the decision to be made and my recommendation in four sentences, so nobody had to read six pages to know my position. I then steelmanned the rewrite genuinely - I listed the strongest three arguments for it, in language its advocates agreed was fair (I checked with one of them before circulating). The core of the doc was evidence: I categorized all 14 billing incidents from the prior year and showed 11 traced to the retry subsystem and the ledger reconciliation job - both isolatable and rewritable in place in about a quarter - while zero traced to language-level problems. I quantified the rewrite honestly using our own history (our last comparable rewrite: 14 months against a 6-month estimate, plus a revenue-impacting parity bug) and laid out a costed alternative: strangler-pattern replacement of the two bad subsystems with defined exit criteria. I circulated it as a comment-enabled doc with a named decision deadline ten days out, tagged the two rewrite advocates first, and answered every comment thread in writing - one commenter found a real flaw in my incident categorization (two incidents were arguably language-adjacent), which I incorporated and flagged as a correction rather than burying.
Result: By the decision deadline, both original advocates had shifted position in the comment threads - one wrote 'I came in pro-rewrite and this doc moved me.' Leadership approved the strangler plan. The two subsystems were replaced over the following two quarters, billing incidents dropped from 14 to 3 year-over-year, and the doc became a referenced template - two later 'rewrite vs repair' debates in the org started by copying its structure. The comment record also meant that a year later, when someone asked 'why didn't we rewrite?', the entire reasoning was one link away.

Why this works

What makes this strong: (1) the document did real work against real momentum - it changed the minds of the specific people who disagreed, in writing, traceably; (2) it demonstrates the full rigor toolkit Stripe's culture prizes: recommendation up front, genuine steelmanning verified with an opponent, quantified evidence, a costed alternative, a decision deadline, and public incorporation of a flaw a commenter found; (3) the outcome is measured both immediately (incidents 14 to 3) and culturally (the doc became a template and a durable decision record).

WEAK

Weak: 'communication' that means meetings

Prompt: "Describe aligning multiple teams on a contentious choice. How did you do it?"

Situation: Two teams disagreed about which of two internal frameworks we should standardize on, and it was getting political.
Task: As the senior engineer involved, I needed to get everyone aligned. Communication is one of my strengths, so I took it on.
Action: I set up a series of meetings with both teams and did a lot of hallway conversations to understand where people stood. I'm good at reading the room, so I could tell who the real influencers were and I focused on winning them over one-on-one. After a few weeks of talking to people I got a critical mass on board with option A. I did write everything up afterward - I sent out a summary doc of the decision so there was a record and everyone knew the outcome.
Result: We standardized on option A and the debate died down. Some of the option-B folks were still unhappy, but the decision was made and documented, so we could move on.

Why this is weak

Why weak: (1) 'communication' here means persuasion through meetings and hallway influence - the document appears only after the fact, as a broadcast of a decision already made, which is the exact anti-pattern a writing-first culture screens against; (2) there's no inspectable reasoning anywhere - no stated criteria, no tradeoff analysis, nothing the option-B team could engage with or attack on the merits, which is why they ended 'still unhappy' rather than convinced or fairly overruled; (3) winning over 'the real influencers' one-on-one optimizes for social dynamics over argument quality - at Stripe that reads as politics, and the residual resentment in the result is the predictable cost.

Common pitfalls

×Describing communication skill entirely in terms of talking - meetings, presentations, hallway influence - with no artifact doing real work.
×Circulating documents only to announce decisions already made. Writing-first means the document is where the decision happens.
×Docs that advocate instead of analyze - no steelmanned alternatives, no quantified tradeoffs, conclusion visibly predetermined.
×Burying the recommendation. If a reader needs six pages to learn your position, the document is badly built.
×Treating comments as objections to survive rather than error-correction to incorporate - and never being able to name a time feedback changed your doc.
×No named decision mechanism - documents that circulate forever without a deadline or an owner produce alignment theater, not decisions.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'what made the doc persuasive?', answer structurally - recommendation placement, steelmanning, evidence - not 'I'm a good writer.'
→If asked 'did anyone disagree?', the strong answer includes written dissent and how it was engaged on the merits, ideally with your position updating somewhere.
→If asked 'how do you keep docs short?', show calibration: state the reader, the single decision the doc serves, and what you cut.
→If asked about async work, have concrete mechanics ready - comment deadlines, decision owners, time-zone-aware review windows - not just 'we used docs.'
→Expect your claim to be tested live: your answers in the interview are a writing sample spoken aloud. Structure them - situation, position, evidence, result.

Related behavioral themes

Earn Trust

Amazon LP

Amazon's bar for how leaders build credibility: listen, speak candidly, treat others respectfully, and be vocally self-critical even when it is awkward.

Are Right, A Lot

Amazon LP

This LP is a trap if you read it as 'I'm always right.' Interviewers screen for strong judgment under uncertainty AND willingness to be disconfirmed.

API Craft & Operational Excellence

Stripe

Stripe treats APIs as products and reliability as a feature - backward compatibility, idempotency, and boring operational rigor. Interviewers test whether you've built things other people could bet on.

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

StripeFoundational Premium

Rigorous Written Communication (Stripe Culture)

Stripe is a writing-first company - decisions travel in documents, not meetings. Interviewers test whether you can think on paper and change outcomes with a well-made written argument.

About this theme

What interviewers are evaluating

→Has a document you wrote actually changed a decision - and can you reconstruct the argument that did it?
→Do your docs steelman alternatives and quantify tradeoffs, or advocate for a conclusion you'd already reached?
→Do you use writing to think - finding the holes in your own reasoning before circulating - or only to announce?
→Can you align people across teams and time zones asynchronously, without defaulting to a meeting?
→Do you invite and incorporate written dissent, or does feedback on your docs go nowhere?
→Is your writing calibrated to its reader - a one-pager for executives, full depth for the reviewing engineers?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time something you wrote changed a technical decision.
?Walk me through the best design doc you've written. What made it good?
?Describe aligning multiple teams on a contentious choice. How did you do it?
?Tell me about a time written feedback changed your own proposal.
?How do you communicate a complex technical tradeoff to a non-technical audience?
?Describe working effectively with a team in a very different time zone.
?Tell me about a time poor communication caused a problem, and what you changed afterward.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: the doc that stopped a rewrite

Prompt: "Tell me about a time something you wrote changed a technical decision."

Situation: My org had informally decided to rewrite our billing service in a new language - the momentum came from two influential engineers, a string of painful incidents in the old service, and a general feeling that the codebase was beyond saving. A kickoff was scheduled and headcount was being sketched. I believed the rewrite would fail: the incidents traced to two specific subsystems, not the language, and we'd be freezing a revenue-critical service for a year to fix the wrong variable.
Task: Arguing this in the kickoff meeting would have been me against the room's momentum. I decided the only way to test my belief honestly - and to change the outcome if I was right - was to write the case so clearly that it could be attacked in the open, asynchronously, by everyone with context.
Action: I spent three evenings on a six-page document. Structure mattered: page one stated the decision to be made and my recommendation in four sentences, so nobody had to read six pages to know my position. I then steelmanned the rewrite genuinely - I listed the strongest three arguments for it, in language its advocates agreed was fair (I checked with one of them before circulating). The core of the doc was evidence: I categorized all 14 billing incidents from the prior year and showed 11 traced to the retry subsystem and the ledger reconciliation job - both isolatable and rewritable in place in about a quarter - while zero traced to language-level problems. I quantified the rewrite honestly using our own history (our last comparable rewrite: 14 months against a 6-month estimate, plus a revenue-impacting parity bug) and laid out a costed alternative: strangler-pattern replacement of the two bad subsystems with defined exit criteria. I circulated it as a comment-enabled doc with a named decision deadline ten days out, tagged the two rewrite advocates first, and answered every comment thread in writing - one commenter found a real flaw in my incident categorization (two incidents were arguably language-adjacent), which I incorporated and flagged as a correction rather than burying.
Result: By the decision deadline, both original advocates had shifted position in the comment threads - one wrote 'I came in pro-rewrite and this doc moved me.' Leadership approved the strangler plan. The two subsystems were replaced over the following two quarters, billing incidents dropped from 14 to 3 year-over-year, and the doc became a referenced template - two later 'rewrite vs repair' debates in the org started by copying its structure. The comment record also meant that a year later, when someone asked 'why didn't we rewrite?', the entire reasoning was one link away.

Why this works

WEAK

Weak: 'communication' that means meetings

Prompt: "Describe aligning multiple teams on a contentious choice. How did you do it?"

Situation: Two teams disagreed about which of two internal frameworks we should standardize on, and it was getting political.
Task: As the senior engineer involved, I needed to get everyone aligned. Communication is one of my strengths, so I took it on.
Action: I set up a series of meetings with both teams and did a lot of hallway conversations to understand where people stood. I'm good at reading the room, so I could tell who the real influencers were and I focused on winning them over one-on-one. After a few weeks of talking to people I got a critical mass on board with option A. I did write everything up afterward - I sent out a summary doc of the decision so there was a record and everyone knew the outcome.
Result: We standardized on option A and the debate died down. Some of the option-B folks were still unhappy, but the decision was made and documented, so we could move on.

Why this is weak

Common pitfalls

×Describing communication skill entirely in terms of talking - meetings, presentations, hallway influence - with no artifact doing real work.
×Circulating documents only to announce decisions already made. Writing-first means the document is where the decision happens.
×Docs that advocate instead of analyze - no steelmanned alternatives, no quantified tradeoffs, conclusion visibly predetermined.
×Burying the recommendation. If a reader needs six pages to learn your position, the document is badly built.
×Treating comments as objections to survive rather than error-correction to incorporate - and never being able to name a time feedback changed your doc.
×No named decision mechanism - documents that circulate forever without a deadline or an owner produce alignment theater, not decisions.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'what made the doc persuasive?', answer structurally - recommendation placement, steelmanning, evidence - not 'I'm a good writer.'
→If asked 'did anyone disagree?', the strong answer includes written dissent and how it was engaged on the merits, ideally with your position updating somewhere.
→If asked 'how do you keep docs short?', show calibration: state the reader, the single decision the doc serves, and what you cut.
→If asked about async work, have concrete mechanics ready - comment deadlines, decision owners, time-zone-aware review windows - not just 'we used docs.'
→Expect your claim to be tested live: your answers in the interview are a writing sample spoken aloud. Structure them - situation, position, evidence, result.

Related behavioral themes

Earn Trust

Amazon LP

Amazon's bar for how leaders build credibility: listen, speak candidly, treat others respectfully, and be vocally self-critical even when it is awkward.

Are Right, A Lot

Amazon LP

This LP is a trap if you read it as 'I'm always right.' Interviewers screen for strong judgment under uncertainty AND willingness to be disconfirmed.

API Craft & Operational Excellence

Stripe

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →