Tell me about a time your team kept re-arguing the same code-style rule in reviews.
answer
- name the rule and its review cost
- why it kept coming back
- decide it once, with the team
- make the decision automatic or written
- the cost removed, with a number
basics
~20 sTests whether you fix systems or win arguments. Name the debate that kept resurfacing, show you moved it out of code review into a formatter, a lint rule or a written decision, and give the cost that removed.
how to answer
5 beats- the debate that kept coming back, and what it costOpen with the specific rule and the fact that it recurred, not with team background. Keep this and the next beat to roughly a fifth of your airtime, and land one concrete cost early so the interviewer knows why the story matters.
- why it kept resurfacingSay what made it self-renewing: nothing written down, a tool that allowed both forms, or a new joiner arriving with different habits. This is the sentence that turns a style anecdote into a systems observation.
- how you got it decided onceThis is the bulk of the answer, around sixty percent. Describe the evidence you brought, where you took the decision, who was involved, and what you conceded. Name where you took the defaults rather than a position, because that is the cheapest way to end a taste argument.
- how you made the decision stick without youSay what enforces it now: a formatter or lint rule in the pipeline, a short decision record in the repository, a shared configuration. If a human is still the enforcement mechanism, admit it and say why that was the right trade at the time.
- the result and what you would changeGive the after number against the cost you opened with, then spend a sentence on the honest weakness of what you did, such as consultation you skipped or a rule you should not have made. Result and reflection together are about a quarter of the answer.
your answer
5 story prompts- Pick a convention debate that resurfaced in at least three separate reviews, not a one-off disagreement.
- Find one number you removed: review turnaround, mechanical comments per change, or deploys per week.
- Name the mechanism you left behind, whether a formatter, a lint rule, or a written decision.
- Prepare one rule you deliberately decided not to make, and why.
- This can be the same story as your process-improvement answer, re-angled onto the disagreement.
draft and rehearse your own answer in a learn session
go deeper
Convention debates are cheap to have once and ruinous to have forever, so this prompt probes conflict resolution and systems thinking at the same time. The interviewer wants to know whether you end the argument structurally, through automation or a written decision, or whether you win it one review at a time. A strong answer also shows you built consent rather than compliance.
I was on a five-person backend team at a consultancy, building a services layer for a client on a thirteen-week program. By week six we were about nine days behind, and part of the reason was visible in every pull request: four or five comments each about import ordering, brace placement, and whether helper methods belonged above or below their callers. Deploy frequency had fallen from nine a week to three, and median review turnaround was twenty-six hours. I pulled the previous three weeks of review comments into a sheet and counted them. A little over half were mechanical, and not one of them had ever caught a defect. I took that to the Monday sync with a proposal rather than a complaint: adopt the formatter defaults exactly as shipped, wire the formatter and the linter into the pipeline so unformatted code fails before a human reads it, and spend our discussion only on the two rules people genuinely cared about, which were package layout and test naming. Those two we settled in a fifteen-minute vote and wrote into a one-page decision record in the repository, with the reasoning, so nobody would have to re-derive it. I did the tooling that week, including one reformat commit everyone rebased onto. Deploy frequency came back to eleven a week and review turnaround dropped to seven hours. What I would change is that I chose the formatter defaults on my own. Two people quietly disliked them for a month, and ten minutes of asking first would have bought real agreement instead of tolerance.
The signal is in the third and fourth beats: counted evidence instead of an opinion, taste settled by taking defaults, and enforcement moved into the pipeline so it survives the speaker. The closing admission about skipping consultation is what keeps it from sounding unilateral. Dropping the counts, or ending at we agreed, would downlevel it immediately.
A couple of engagements later I was technical lead across three backend teams at the same consultancy, nineteen engineers over two client programs, and each repository had drifted into its own dialect. What surfaced it was a delivery review: our schedule risk was onboarding. A new engineer's first merged change was landing on day nine, and most of that delay was learning unwritten conventions one review comment at a time. I did three things. I moved the shared rules into a configuration package the repositories depend on, so changing a rule is a version bump rather than nineteen separate conversations. I made the standards default-on but deviation legitimate: any team can differ, provided the deviation lives in a short decision record with a reason and a date to revisit it. And I replaced the standing style discussion with a twenty-minute pass each quarter whose only job is retiring rules that stopped earning their keep. We dropped four in the first pass. The uncomfortable part was telling one team lead that the lint set he had hand-rolled was going away. I did that in a one-to-one before it was announced, and he ended up running the migration himself. Over the following quarter, deploys per week across the three repositories rose from twenty-two to forty-one, and a new joiner's first merged change moved to day two. I would sequence it differently: the exception path should have shipped before the configuration package, because for the first fortnight deviating looked like disobeying.
Scope and meta-system separate this from the smaller version: shared configuration, a legitimate deviation route, and a mechanism for deleting rules. The named one-to-one shows the political cost was paid, not narrated around. It would downlevel if the answer stopped at we standardised the tooling, with no exception path and no retirement pass.
Your scope is your own pull requests. It is enough to show you spotted the pattern across several reviews, raised it rather than absorbing it silently, and adopted the tooling or the written rule the moment it was decided.
You are expected to have driven the resolution for the team: run the decision, land the formatter or lint rule in the pipeline, and put the two or three genuinely contested rules in writing. Show consent, not just a merged config file.
Talk about delivery and production scope. Standards should be default-on and enforced before a human reads the diff, onboarding cost should measurably drop, and you should name the exception path you designed for teams that need to deviate.
Work at the level of how rules are made and retired: shared configuration owned somewhere central, a documented route for adding or dropping a convention, and a periodic pass that removes rules that stopped earning their keep. Personal taste should not be enforceable anywhere.
saying these in an interview costs you the question
- Framing the story as winning an argument rather than removing it
- No mechanism at the end, only an agreement to be reasonable
- Imposing a standard without consulting the people who work under it
- Turning every preference into a rule, adding process nobody follows
- Naming no cost: no review turnaround, comment count or delivery number
- Characterising the teammates who held the other preference as difficult
- What did you do about the people who still disagreed after the decision?Show that you distinguished disagreement from obstruction. Say how you made the dissent legitimate and visible before the decision, then how you expected compliance after it, including from yourself. If someone kept relitigating, describe the conversation you had rather than the escalation you threatened. Avoid painting them as unreasonable; if they were right later, say so and say what changed.
- How do you decide which conventions are worth automating and which you let go?Give a filter, not a list. A useful one: automate anything mechanically checkable that has never caught a real defect, write down anything contested that affects more than one team, and let go of anything that is only a taste difference invisible to the reader. Mention the cost of over-ruling too, because a standards document nobody reads is its own failure mode.
- How did that standard hold up once the team changed?Interviewers are probing durability. Talk about what happened when new people joined, whether the rule survived without you enforcing it, and whether anything was later relaxed or deleted. Being willing to say a rule was retired reads as maturity, not failure. If you never checked, say that honestly and say what you would instrument next time.
### What the prompt family looks like Interviewers reach for this scenario in several wordings: tell me about a recurring disagreement on your team; how have you handled arguments about coding standards; tell me about a time you introduced a convention; describe a debate that kept coming back in code review. They are all the same evaluation: given a low-stakes, high-frequency conflict, do you resolve the instance or the class? ### Why it separates candidates so cleanly Style disagreements are the perfect test case because nobody is wrong. Two engineers with defensible preferences can burn an hour a week each, forever, and no amount of being right ends it. A candidate who narrates how they persuaded the other person has answered a different question than the one asked. The signal the interviewer wants is that you recognised a recurring cost, decided the matter once in a way the team consented to, and then made re-litigation unnecessary by moving enforcement into a tool or a document. ### Weak versus strong, in one contrast Weak: we disagreed about formatting, we talked it out, and eventually we agreed on my approach. The story ends with a person changing their mind, which means it will recur with the next joiner. Strong: we were spending a measurable share of review comments on mechanical issues, so I put the numbers in front of the team, we took the tool defaults where taste was involved, wired the check into the pipeline so unformatted code never reaches a reviewer, and wrote down only the handful of rules people genuinely cared about. The story ends with a mechanism, and the mechanism outlives everyone in it. ### The evidence that carries the answer Three kinds land well. First, frequency evidence: how often the debate recurred, ideally counted rather than estimated, such as comments per pull request or the share of review threads that were mechanical. Second, cost evidence: review turnaround, time to first merged change for a new joiner, throughput or deploy cadence. Third, consent evidence: how the decision was made, who was in the room, and what the dissenters were offered. Skipping the third makes an otherwise strong answer sound like a unilateral imposition, which is a real failure mode and interviewers listen for it. ### Two traps The first is over-ruling. Some candidates hear this prompt as an invitation to demonstrate rigour and describe a fifty-page standards document. Say out loud which debates you deliberately let go; restraint is part of the signal. The second is the retirement question. Rules accumulate, and a team with no route to remove one ends up with conventions nobody can justify. Even one sentence about how a rule could be revisited or dropped puts you ahead of most answers. ### How the bar moves with level At the earlier rungs the interviewer is happy with awareness and adoption: you noticed, you raised it, you followed the outcome. Around the middle they want the mechanics, run by you, for a whole team. Higher up they stop caring about the specific rule entirely and listen for the meta-system: where shared configuration lives, how a team deviates legitimately, who owns the standard when the person who wrote it moves on. Answer at your own rung and gesture one rung up; answering two rungs above your experience is transparent and costs more than it gains.