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 (preview)

The full library pairs strong and weak examples with notes on what makes each work (or fail). Here's how two of the strong stories open.

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.
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 full Task → Action → Result walkthrough and the "why this works" notes are in the member version.

What's in the full theme

2 full STAR answers (strong and weak, with interviewer notes) · 6 common pitfalls · 5 follow-up strategies

Subscribe to Continue

Get full access to gitGood.dev with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

2,000+ practice questions
AI mock interviews (3/day)
Coding challenges with real execution
Verified skill badges
146 certification guides, 26 with practice exams

View Plans

7-day trial, then $8/mo - or $64/yr ($5.33/mo, save 33%). Cancel anytime.

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 (preview)

The full library pairs strong and weak examples with notes on what makes each work (or fail). Here's how two of the strong stories open.

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.
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 full Task → Action → Result walkthrough and the "why this works" notes are in the member version.

What's in the full theme

2 full STAR answers (strong and weak, with interviewer notes) · 6 common pitfalls · 5 follow-up strategies

Subscribe to Continue

Get full access to gitGood.dev with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

2,000+ practice questions
AI mock interviews (3/day)
Coding challenges with real execution
Verified skill badges
146 certification guides, 26 with practice exams

View Plans

7-day trial, then $8/mo - or $64/yr ($5.33/mo, save 33%). Cancel anytime.

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 →