skip to content

Collaboration & Conflict

How you work with other people when it gets hard: disagreements, friction, feedback, and persuasion. Interviewers probe this because most engineering failures are coordination failures, and they want evidence you can disagree productively without burning relationships.

on this pageshow

explore

questions

page 1 of 2

How do you word a code review comment when you think the author's approach is wrong?

level: juniorimportance: must knowfreq 54%

answer

  1. label severity: blocking or nit
  2. ask, don't command
  3. cite the standard, not my taste
  4. quote one comment I actually wrote
  5. when I stop typing and talk

basics

~20 s

Probes whether you can be direct without making it personal. Strong answers label severity first, state the objection as a question with the reason attached, cite a shared standard rather than taste, and quote one comment you actually wrote.

how to answer

5 beats
  1. the principle I open with
    One sentence on what your comments are for: routing attention, not scoring points. Keep it to a line — the interviewer is waiting for evidence, not philosophy.
  2. how I label blocking versus nit
    State your actual convention and where it lives, whether that is a prefix, a label, or a sentence at the top of the review. The point is that the author never has to guess which comments they must act on.
  3. the wording move: question plus reason
    Explain how you attach a consequence the author can verify and leave a genuine opening to be wrong. Say why: an objection with evidence is arguable, an objection with authority is only obeyable.
  4. a comment I actually wrote, quoted
    Recite one real comment word for word, ideally one whose first draft you deleted. This is the beat that separates you from every candidate who describes being respectful in the abstract.
  5. when I stop commenting and talk
    Give your trigger for leaving the thread — a round count, a rising temperature, a disagreement about design rather than detail — and what you do in that conversation. Close by saying where the decision got written back down.

your answer

4 story prompts
pick a story
  • Copy two comments you wrote last month, one blocking and one purely optional.
  • Find a comment you nearly sent, then rewrote, and keep both versions.
  • Name one team standard you can cite instead of your own preference.
  • Recall a review where your question turned out to be a misread.

draft and rehearse your own answer in a learn session

go deeper

Code review is where most engineers give hard feedback most often, so this is a cheap read on how you handle disagreement in writing, where tone has no body language to soften it. Interviewers listen for whether you separate severity from preference, whether your objection carries a reason the author can independently check, and whether you can be blunt about risk while leaving the author's ownership intact.

at junior level

I'm the newest person on the test-infrastructure side of a small startup, so I write comments that are easy to disagree with. My rule is that a comment says how much it matters before it says what I think. Last quarter a teammate's change fixed a flaky end-to-end spec by wrapping it in a two-second sleep and a retry. My instinct was that this hid the bug instead of fixing it, but I'd been there seven weeks and could easily have been missing context. So I checked before I typed: I pulled the branch, ran that spec forty times locally, and it still failed four of those runs even with the retry. Then I left one comment. 'Blocking, I think — I ran this locally 40 times and it still failed 4, so the retry may be hiding a race rather than removing it. The fixture load order looks non-deterministic to me. Am I reading that right?' Everything else I had was formatting, and I prefixed those 'nit, take it or leave it' so he knew he could ignore them. He came back agreeing about the fixture order, pushed a real fix, and I approved the same afternoon. What I took from it is that evidence plus a genuine question does the arguing for you. If I'd written 'don't use sleeps', it would have been my opinion against his, and as the junior person in that thread I'd have lost.

why this lands

The signal is in the checking before the commenting, and in the quoted comment: severity first, a number the author can reproduce, and a real question. The formatting notes explicitly marked ignorable is a small move that reads as calibrated. Delivering only the principle, with no comment quoted, would flatten this to advice.

at middle level

At this point I treat comment wording as routing rather than politeness. I review most of what touches the nightly suite at my company, so a badly phrased comment costs me a day of ping-pong I don't have. Two habits. Every comment opens with blocking, question, or nit, and I hold myself to at most two blocking comments in a review — if I have five, the design is the problem and a comment thread is the wrong venue for it. And a blocking comment carries the standard, not me: the rule we agreed on, not the way I'd have done it. The one I remember came after a bad week where our nightly signal had gone dark. Someone put up a change deleting three assertions that had been failing intermittently. My first draft said 'we don't delete assertions.' I didn't send it — that's a rule with a wagging finger and no reason in it. What I sent was: 'Blocking, though I think we want the same outcome here. Deleting these takes them out of the flake count, so the number improves while coverage gets worse. Can we quarantine with an expiry instead? Happy to pair on it after standup.' He took the pairing. The nightly suite's flaky share fell from 14.2% to 6.3% over the following month, once quarantined specs were being tracked instead of quietly removed. The comment I deleted is the reason that conversation stayed technical.

why this lands

The deleted first draft does the work: the candidate shows the bad version and names why it was bad. The two-blocking-comments ceiling is a calibration rule an interviewer can probe. Dropping the standard-versus-preference distinction, or the pairing offer, would leave it sounding like tone advice with a metric attached.

for a junior

Show that you check before you comment: pull the branch, reproduce, read the surrounding code. At your level a question that turns out to be a misread still reads well; a confident wrong command does not.

for a middle

Own the phrasing. Name your severity convention, then read out one comment you rewrote before sending and say what the first draft would have cost you.

for a senior

Talk about calibration as much as tone: how many blocking comments a single review can carry before the design is the real problem, and how fast you pull a thread onto a call.

for a principal

Speak to review culture rather than your own keyboard: a norm cheap enough that others follow it without you in the thread, and evidence that comment quality changed on reviews you never touched.

saying these in an interview costs you the question

  • Claims you never have to give anyone hard feedback
  • Softens so far the author cannot tell what must change
  • Marks every comment blocking, including pure preferences
  • Presents personal taste as though it were a team standard
  • Sarcasm or public point-scoring inside the comment thread
  • Offers no example of wording you have actually used

  • Show me how you would rewrite a comment that just says 'this is wrong'.
    Rewrite it aloud, don't describe it. Aim for three parts: severity, the consequence you can point at, and a question that leaves room to be wrong. Something like: blocking, because this path retries on a failure we currently count as a pass, so we would lose the signal. Am I reading the failure handling right? Naming the consequence is what stops it being taste.
  • What do you do when the author disagrees with your comment?
    Say that one more written exchange is your limit, and that it has to add information rather than restate the position. After that you move to a call or pull in a third reader. Make clear you distinguish a preference you will drop instantly from a risk you will keep holding, and that you tell the author which one it is.
  • How do you avoid leaving thirty comments on a large change?
    Talk about triage before typing: read the whole diff first, decide the one or two things that actually matter, and let the rest go or batch them as explicit non-blocking notes. Volume reads as distrust even when every comment is correct, and it buries the comment you needed the author to see.

context

open as a page

Tell me about a time you got harsh or blunt feedback on a code review.

level: juniorimportance: must knowfreq 68%

basics

~10 s

Tests whether criticism of your code lands as criticism of you. Answer with one blunt comment, what you did to understand it before replying, the change you made, and the working relationship afterwards.

open as a page

Tell me about a time you had to tell a stakeholder that work was going to be late.

level: juniorimportance: must knowfreq 64%

basics

~20 s

Tests whether bad news travels fast and arrives with a plan. Answer with the moment you knew, how quickly you said it, what you offered alongside the slip, and the revised date you then held.

open as a page

Tell me about a time you had to work with a difficult teammate.

level: juniorimportance: must knowfreq 86%

basics

~10 s

Probes conflict resolution and self-awareness. Describe one person in observable behaviours, the charitable read you tested, the direct conversation you had, what you changed yourself, and a work outcome with the relationship still standing.

open as a page

Tell me about a time you were wrong about a technical decision.

level: juniorimportance: must knowfreq 58%

basics

~10 s

Tests whether you can be wrong without defending it. Name a real call you got wrong, how you found out, what you said and to whom, and the guardrail that came out of it.

open as a page

Tell me about a time you disagreed with your manager.

level: juniorimportance: must knowfreq 72%

basics

~10 s

Tests backbone without ego. Pick one disagreement that genuinely mattered, show you raised it privately with evidence rather than opinion, and land on the decision, the outcome, and a working relationship that survived.

open as a page

Tell me about a time you disagreed with a coworker on a technical decision.

level: juniorimportance: must knowfreq 82%

basics

~20 s

Tests whether you separate the idea from the person. Answer with one concrete disagreement, evidence you went and got instead of opinions you asserted, a decision that actually got made, and a relationship still intact.

open as a page

Tell me about a time you blocked a teammate's pull request in code review.

level: middleimportance: must knowfreq 44%

basics

~20 s

Tests whether you hold a line on risk without making it a contest. Answer with one change you refused to approve, the concrete harm you named, the alternative you offered, and where the code and the relationship both ended up.

open as a page

Tell me about a time you pushed back on a deadline or scope a stakeholder insisted on.

level: middleimportance: must knowfreq 68%

basics

~10 s

Tests whether you can disagree with the business without stonewalling it. Name the commitment, show the evidence it would not hold, and leave the stakeholder choosing between real options rather than facing a wall.

open as a page

Tell me about a time you gave a teammate feedback they did not want to hear.

level: middleimportance: must knowfreq 66%

basics

~20 s

Tests whether you can be direct and kind at once. Answer with one specific behavior and its measurable impact, feedback delivered privately and promptly to the person themselves, and a follow-up that shows the relationship survived.

open as a page

Describe a time you had to work under a team coding convention you disagreed with.

level: juniorimportance: should knowfreq 38%

basics

~20 s

Tests whether you can lose an argument and still implement the decision fully. Name the convention, the case you made once with evidence, and how you complied visibly while leaving a route to revisit it.

open as a page

Tell me about a time something you wrote to a teammate was taken the wrong way.

level: juniorimportance: should knowfreq 38%

basics

~10 s

Tests 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.

open as a page

Tell me about a time a colleague took credit for your work.

level: juniorimportance: should knowfreq 44%

basics

~10 s

Tests whether you can defend your contribution without starting a feud. Answer with one concrete instance, facts checked before motive assumed, a private correction first, and a working relationship that survived it.

open as a page

How do you work with someone whose working style clashes with yours?

level: juniorimportance: should knowfreq 46%

basics

~20 s

Probes adaptability rather than conflict. Name a concrete style difference in behaviour terms, say what you adapted, what you asked for in return, and give one piece of evidence that the working rhythm actually improved.

open as a page

Tell me about a time you approved a pull request you had reservations about.

level: middleimportance: should knowfreq 37%

basics

~20 s

Probes judgment about when not to block. Answer with the reservation you put in writing, why the risk was acceptable that day, what made the change reversible, and how you made sure the follow-up actually happened.

open as a page

Tell me about a time you disagreed with a reviewer's comment and pushed back.

level: middleimportance: should knowfreq 54%

basics

~20 s

Probes whether you can hold a technical position without making it a contest. Answer with one comment you genuinely disagreed with, the reviewer's concern stated fairly, the evidence you brought, and the decision that landed.

open as a page

Tell me about a change of yours that got stuck in review going back and forth.

level: middleimportance: should knowfreq 41%

basics

~20 s

Tests whether you can end an unproductive review loop instead of waiting it out. Answer with how long it stalled, how you separated real disagreements from preferences, the move that broke the loop, and what the delay cost.

open as a page

Tell me about a time your team kept re-arguing the same code-style rule in reviews.

level: middleimportance: should knowfreq 38%

basics

~20 s

Tests 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.

open as a page

Tell me about a time your work was blocked by a dependency another team owned.

level: middleimportance: should knowfreq 55%

basics

~20 s

Tests whether you move a dependency instead of waiting on it. Answer with the deliverable that was blocked, what you learned about their priorities, the trade or patch that got it moving, and a shipped result.

open as a page

Tell me about a time you unblocked yourself by writing code in a repo your team didn't own.

level: middleimportance: should knowfreq 38%

basics

~20 s

Tests whether you can clear a blocker by doing the work yourself without trampling another team's ownership. Answer with the ask you made before writing anything, the patch built to their standards, and who maintains it now.

open as a page

Tell me about a time a handoff across time zones cost your team real time.

level: middleimportance: should knowfreq 33%

basics

~10 s

Probes whether you design around a time-zone gap instead of complaining about it. Answer with one concrete round-trip that cost days, the written handoff or decision rule you introduced, and what it saved.

open as a page

How do you make sure your work stays visible when your team is fully remote?

level: middleimportance: should knowfreq 41%

basics

~10 s

Checks whether you have deliberate written habits or just hope your work speaks for itself. Answer with two or three specific practices, one moment they paid off, and how you avoid performative noise.

open as a page

Tell me about a time you were blamed for a failure that was not yours.

level: middleimportance: should knowfreq 37%

basics

~20 s

Tests composure and ownership when the account of events is wrong about you. Own your genuine share first, correct the timeline with evidence rather than counter-accusation, and finish on the fix that removed the ambiguity.

open as a page

Tell me about a time you escalated a problem with a coworker to your manager.

level: middleimportance: should knowfreq 40%

basics

~20 s

Probes judgement about when direct handling stops working. Show the attempts you made first, the threshold that made escalation necessary, that you told the person before your manager, and what the escalation actually bought the work.

open as a page

Tell me about a time you scrapped work you had already sunk weeks into.

level: middleimportance: should knowfreq 41%

basics

~10 s

Probes sunk-cost resistance and whether your ego is attached to your own code. Name the work, the signal that killed it, the cost you stated out loud, and what shipped in its place.

open as a page

Tell me about a time a teammate convinced you your technical position was wrong.

level: middleimportance: should knowfreq 37%

basics

~10 s

Tests persuadability: whether evidence moves you rather than seniority or volume, and whether you concede where the original argument happened. Show the challenge, what specifically changed your mind, and the credit you gave.

open as a page

Tell me about a time a stalled debate was decided against you and you had to deliver it.

level: middleimportance: should knowfreq 44%

basics

~20 s

Tests whether you can commit to a decision you argued against without sulking or sandbagging. Answer with your position stated once, the moment you got behind the call publicly, and evidence you delivered it well.

open as a page

Tell me about a time a technical debate on your team stalled and you escalated it.

level: middleimportance: should knowfreq 52%

basics

~10 s

Probes judgment about decision velocity: whether you can tell consensus-seeking from stalling. Answer with a debate you timeboxed, escalated to a named decision owner with the options costed, then executed without sulking.

open as a page

Tell me about a time your manager overruled you and you had to carry out the decision anyway.

level: middleimportance: should knowfreq 44%

basics

~20 s

Tests disagree-and-commit. Show that you argued once, substantively, and then executed wholeheartedly — visible commitment to your team, no quiet slow-walking, and a data trigger rather than resentment as the way back to the question.

open as a page

Tell me about a disagreement with a coworker where you were the one who changed their mind.

level: middleimportance: should knowfreq 47%

basics

~20 s

Tests whether you can win a disagreement without damaging the person. Answer with their position stated fairly, the interest underneath it that you actually found, the evidence that spoke in their terms, and a relationship that got easier afterwards.

open as a page

showing 1–30 of 33