How should a candidate word a question about a team's incident postmortem culture so the answer describes practice, not policy?

### Why the obvious version of this question fails "Do you do blameless postmortems?" is a question about a value, and every team believes it holds the value. The answer is yes almost everywhere, it costs the interviewer nothing to give, and you learn nothing. Worse, on the level axis it reads as a phrase the candidate picked up rather than a practice they have lived inside, because someone who has actually written postmortems asks about the parts that are hard: whether they get written at all when the week is busy, who writes them, and whether anything downstream changes. ### The three levers that make an ask platitude-resistant **Countable.** Give the answer a number to fill in. "Of the last several incidents, how many ended with a written postmortem?" forces a rough count, and a rough count is a fact. An honest answer sounds like "a postmortem for 7 of the last 9 — the two we skipped were single-user glitches", or, just as usefully, "honestly, maybe 2 of the last 8, we've slipped on it". Both are informative; neither is available from the value question. **Recent.** Bound the ask to the recent past — the last handful of incidents, the most recent one. Unbounded questions invite the best case a team can remember. Bounded ones invite what actually happens now. **Artefact-anchored.** Tie the question to an object or a change that either exists or does not: a written document, a change to the release process for the web client, a change to who gets paged, an item that entered the next quarter's plan. "What changed after the most recent one?" is the strongest single sentence in this family, because a culture that reviews incidents and changes nothing is a culture that holds meetings. ### A worked wording for a frontend loop Asked of a behavioral interviewer on a web client team: > "When something breaks for users on the web client — a bad release, a broken flow — what happens afterwards? I'm curious how many of the recent ones ended with something written down, and whether anything actually changed as a result." Note what this does. It is countable and recent without being an interrogation. It names a failure mode the interviewer will recognise. It gives them two exits — the document and the change — so a team strong on one and weak on the other can say so. And it is answerable by someone who does not own the on-call rotation, because it asks what they saw rather than what the policy is. ### Ask the person in front of you what they saw This matters enough to state on its own. A behavioral interviewer may sit outside the incident process entirely. Asking them to describe the policy puts them in the awkward position of reciting something secondhand, and awkwardness is what candidates remember as a signal even when it was their own question's fault. "Were you around for the last one? What did that week look like for the team?" is answerable by anyone who was there, and produces more texture than a correct policy summary would. ### What this ask reveals about you On the list of questions sorted by what asking them reveals, this sits near the ownership end, next to the decision-revisiting probe. The reason is that it presupposes three things the asker has evidently lived through: that incidents happen, that writing them up competes with other work, and that the write-up is worthless unless something downstream changes. Nobody who has only closed tickets arrives at all three. It is also self-limiting, which protects you. You can ask it once, get a specific answer, and reply with a specific of your own — the release you cut that broke a flow for a slice of users, and the one thing your team changed after it. That trade is the actual evidence. ### Two cautions **Do not turn it into a maturity audit.** Following up with a checklist of practices you expect to be in place turns a probe into an inspection and puts the interviewer on the defensive. One question, one follow-up, one contribution of your own. **Have a plan for the team that genuinely has few incidents.** Small or young products sometimes do. Ask about the most recent painful release instead — the shape of the question survives, and no team lacks a painful release. Reading what a hedged or evasive answer tells you about the company is a distinct skill from building the question; the work here ends when the ask is one that only a real memory can answer.