Tell me about a time something you wrote to a teammate was taken the wrong way.
answer
- name the message and how it landed
- own the effect, not the intent
- move to higher bandwidth quickly
- repair where the misread happened
- the writing habit you changed
basics
~10 sTests whether you own the effect of your writing rather than defending your intent. Answer with one message that landed badly, the repair you initiated fast, and the habit you changed afterwards.
how to answer
5 beats- the message and why you wrote it that waySet the scene in two or three sentences: who the reader was, what channel, and what you were actually trying to say. Keep this to roughly fifteen percent of your airtime and resist relitigating whether you were technically right.
- how you noticed it had landed badlyName the concrete signal — the thread going quiet, a stiff one-line reply, a question routed around you. This beat is short but it is the one that proves you read text carefully, so do not skip straight to the fix.
- the repair you initiatedThis is the bulk of the answer, around sixty percent. Say what you did first, how fast, and in which channel; if you moved to a call, say who chose the time. Apologise for the framing without retracting the substance, and make it clear you initiated rather than waited.
- where things landedClose the loop with evidence rather than a feeling: the decision that got made, the work that unblocked, a number if you have one. One sentence is enough, but it must exist.
- what you write differently nowState one rule you actually follow, specific enough to repeat back — numbers before verdicts, an explicit blocking-or-opinion label, a question instead of a conclusion. Result and reflection together should take about a quarter of the answer.
your answer
5 story prompts- Find a message of yours that got a silent or unusually formal reply — that silence is the story.
- Pick one where you initiated the repair, not one where someone else smoothed it over.
- Note which channel the misread happened in; you will need to say where you fixed it.
- Write down the one wording rule you follow now as a result, in a single sentence.
- This can be the same relationship as your disagreement story, angled at the words instead of the argument.
draft and rehearse your own answer in a learn session
go deeper
Probes self-awareness and conflict repair in a medium where tone is not recoverable. The interviewer wants to see whether you own the effect of your writing rather than defending your intent, whether you move to repair quickly and in the right channel, and whether the experience changed how you write to people you cannot see.
I was a few months into a platform team at a large company, and I reviewed a change from the networking group that added a second gateway to every ephemeral test environment. I wrote the comment fast, at the end of my day: this nearly doubles what each environment costs us, we should not merge it. They read it at the start of theirs, with nobody around to explain it. The author replied once, very formally, and then the thread went quiet for two days. My lead pointed out that my comment gave a verdict and no reasoning, and that in text a verdict from someone you have never met reads as an accusation. So I asked the author for fifteen minutes on video and took a slot that worked for their morning. I apologised for the framing, not for the concern — I said I should have shown the arithmetic instead of leading with a conclusion. Then I rewrote the comment as a question with the breakdown attached: environments were running at 274 dollars a month each, their version put them at 431, and I asked whether a shared gateway would still meet their isolation requirement. It would, and they shipped that version the following week; we settled at 291 a month. Since then I write review comments the same way every time — numbers first, question second, verdict never — because I cannot stand next to the words and explain them.
The signal is noticing the two-day silence and moving to video the same day, plus apologising for the framing while holding the technical concern. The closing rule is specific enough to repeat. It would downlevel if the candidate spent the middle proving the cost claim was right instead of describing the repair.
I own the environment-provisioning module that four product groups build on. A team in another region posted a proposal to fork it so they could add their own seeding step. I left a long comment listing every way the fork would drift, and I ended with a line saying I would rather we did not do this. Because I own the module, that read as a veto wearing a polite hat, and their tech lead escalated to my manager before I was even online the next morning. When I saw it, I did not defend the wording. I replied in the thread first, publicly, because the misread had happened publicly: the comment was mine to fix, I was not blocking anything, and the call was theirs to make. Then I set up a conversation at an hour that was awkward for me and easy for them, which I think mattered more than anything I actually said on it. The durable fix was structural. We agreed that a comment from a module owner has to carry an explicit tag — blocking or opinion — and that a blocking one must name the cost it is protecting. I put both lines into our proposal template. Mine was an opinion, they took a plugin hook instead of a fork, and provisioning stayed on one stack at 318 dollars per environment rather than splitting into two that would have drifted apart.
This one turns on understanding that ownership put weight on the words, repairing in the same public channel where the damage happened, and taking the inconvenient meeting slot. The tag convention turns one repair into a norm. Naming who was right about the fork, instead of the wording, would downlevel it.
Own one message you wrote and the effect it had on one person. Showing that you noticed the silence, asked instead of assuming, and changed how you word review comments is the whole bar here.
Your words now carry weight over a component or a review queue, so show that you understood why the misread was structural, not just unlucky, and that you fixed the wording convention as well as the relationship.
Show awareness that your text is read as direction. Strong answers describe repairing in the same channel where the damage happened and installing a norm — explicit blocking-versus-opinion tags, decisions written down — so the team stops guessing at tone.
Frame it as norm design across distributed groups: what written conventions you put in place so that authority, urgency and dissent are explicit in text, and how you saw the effect beyond the one thread you were in.
saying these in an interview costs you the question
- Defending intent instead of owning how the words landed
- Blaming the reader for being oversensitive or a poor reader of text
- Blaming the medium rather than your own choice of words
- No repair move at all, just an eventual awkward truce
- Repairing privately when the misread happened in a public thread
- No changed habit, so the same message would land the same way again
- How did you realise it had landed badly?Name the actual signal — a thread that went quiet, a formal reply where you expected a casual one, a question routed around you to someone else. Showing that you read those signals is worth more than the repair itself, because it proves you notice in text what most people only notice in a room.
- What would you write differently now?Give a concrete rewrite rule you actually apply, not a sentiment. Numbers before verdicts, a question instead of a conclusion, an explicit label for whether you are blocking. One rule you can state in a sentence beats a general promise to be more careful.
- How is that relationship now?Answer with evidence rather than reassurance: they asked you to review something later, you two wrote a proposal together, they pinged you directly instead of routing around you. Avoid claiming you became close friends; a working relationship that got better is more credible and is what the question is checking.
## Common wordings This prompt shows up in almost every distributed-team loop, in several wordings that all want the same signal: - "tell me about a time you were misunderstood in writing" - "describe a communication breakdown with a remote teammate" - "has a code review comment of yours ever caused friction" A few interviewers invert it — "tell me about a time you misread someone else's message" — and the same story usually works from the other side, but be careful: the inverted version rewards a different beat, namely that you checked your reading before you reacted. ## Why it is asked at all In a **co-located team**, tone repairs itself. You see a face fall, you soften the next sentence, and nothing compounds. In a **distributed team**, a badly worded sentence sits in someone's morning inbox for hours with nobody around to explain it, and the reader fills the gap with the least generous interpretation. Interviewers on distributed teams have watched that pattern turn into a two-week stall between groups, so they are looking for a candidate who treats their own writing as an artifact with consequences rather than as a transcription of what they meant. ## Weak answer, strong answer The weak answer and the strong answer diverge early. - **The weak one** spends its airtime proving the candidate was right on the merits — the change really would have cost more, the code really was wrong — and treats the misread as the other person's processing error. That answer fails even when the technical claim is true, because being right was never the question. - **The strong answer** concedes the effect immediately and without theatre: my words did this, here is what I did about it, here is what I write differently now. Note the distinction worth saying aloud: you apologise for **the framing**, not for **the concern**. Candidates who retract the substance to smooth things over read as conflict-avoidant, which is its own failure mode. ## Evidence that carries weight, roughly in order 1. **First, the signal you noticed** — a silent thread, a suddenly formal reply, a question routed to someone else. Naming the signal proves you read text the way experienced remote engineers do. 2. **Second, the speed and the channel of the repair.** Moving to a call is good; choosing a call slot that is convenient for them and inconvenient for you is better, and saying that out loud costs one sentence. 3. **Third, where you repaired.** A public misread repaired in a private DM leaves the original impression standing for everyone else in the thread; strong candidates fix it in the same place it happened and then take the detail offline. 4. **Fourth, the durable change** — a wording rule, a template line, a convention about labelling whether a comment blocks. ## How the bar shifts - **Early-career**, one message and one relationship is a complete answer, and the interviewer mostly wants to see that you did not go quiet or dig in. - **In the middle**, they expect you to see the structure: your comment carried authority you had not accounted for, or the medium stripped a hedge you assumed was obvious. - **Senior and above**, the answer is expected to end somewhere other than the relationship — a norm, a template, a rule the team now follows — because at that level your text sets tone for people you have never spoken to. ## Two traps specific to this prompt - Do not pick a story where the misread was about a **genuinely hostile message**; a candidate who has to explain away real rudeness spends the whole answer digging. - And do not pick a story with **no consequence at all**, where a slightly blunt message was smoothed over in ten minutes. It has to have cost something — days, a stalled decision, a relationship that needed rebuilding — or there is nothing for the interviewer to score.