Giving and Receiving Feedback Questions

Direct answer

In the moment I listen without defending, thank them, and ask for the specific moment that landed badly. Afterwards I change how I deliver (private first, check intent, plainer wording) without dropping the substance of the feedback, and I repair the relationship with a follow-up that acknowledges the impact and asks how they would like to hear it. Intent and impact are different: I can mean well and still have hurt.

In the moment

• Pause and listen. Do not explain your intent first; that sounds like "you are wrong to be hurt".
• Say thanks and name what you heard: "Thank you for telling me. It sounds like it landed as criticism in front of others, and that stung."
• Ask one specific question: "What was the moment, and what did you hear in it?"
• If I feel defensive, say "I want to think about this properly, can we talk tomorrow?" rather than answering badly.

What I change

1. Venue: negative feedback goes private first unless it is about a team-level process.
2. Structure: use SBI (Situation, Behavior, Impact): a concrete moment, an observable behavior, the effect, with no labels like "careless".
3. Ask before I tell: "Would it be useful to hear some feedback on X?" and "How did that land?" afterward.
4. Tone check on written words: read the message as the recipient would, on a bad day.

Repair

• A short follow-up: "I've thought about what you said. The point I raised still matters, but I should have raised it privately and with an example. I'm sorry it landed that way."
• Do not retract the feedback itself if it was valid; apologise for the delivery.
• Ask: "How would you like me to bring things like this up in future?"
• Then do it. The repair is confirmed by the next few interactions (for example the next two or three times I have critical feedback to give), not by the apology. The number is a rule of thumb, not a measured threshold.

Worked example

I told a peer in a design review, "your error handling is sloppy." Later they said it felt like a public shot. I replied, "Thanks for telling me. What part felt worst?" ("Hearing it in front of the team.") The next day I said: "I should have said this privately. The specific issue: the retry in the payment call swallows failures, which would hide outages. Can we look at it together?" We fixed it, and I now send substantive critiques privately first.

Pitfalls

• "I'm sorry you feel that way" is not an apology.
• Over-correcting into never giving candid feedback again makes things worse for both of you.

Direct answer

Private is the default for critical feedback about an individual's behavior or work. Public (in a retro or team meeting) is right for team-level patterns framed as process, for praise, and, rarely, for correcting something happening right now that would hurt others. A rule I use: public about the system, private about the person.

When each applies

• Private: the feedback is about one person's judgment, habits, tone or quality; it might embarrass them; I need to hear their side. (A 1:1 is a regular private meeting between two people, often with a manager.)
• Public: it concerns a shared pattern (review turnaround, flaky tests); the team needs to agree a change; or it is praise that sets a standard.
• Public correction in the moment: only if waiting causes harm (someone about to run a destructive command on production). I correct the action briefly, then follow up privately.

Example 1: private (a recurring behavior)

A teammate repeatedly merges without tests. I use the SBI structure (Situation, Behavior, Impact: name the moment, what the person did, and the effect). In a 1:1 I say: "Last week's pull request for the billing job (Situation) was merged without tests (Behavior). The nightly run failed on Monday because of a case a test would have caught (Impact). Can we talk about what is getting in the way of adding tests?" I ask first, because the cause might be a slow test setup, not carelessness.

Example 2: public (a team pattern, in a retro)

(A retro is a regular team meeting to review how work went.) Instead of "Sam is slow reviewing", I say: "Our pull requests are waiting about two days for the first review (this can be checked from the tracker). That blocks releases. Can we agree on a first-response expectation and a rotation?" This names the pattern and invites a shared fix. The wording is blameless (it describes what happened and the process, not whose fault it was), and nobody is singled out.

Example 3: public correction in the moment

Someone in a team call is about to run a delete command against the production database (the live system customers use). I say, right then and calmly: "Hold on, that command targets production. Can we check the environment first?" I correct the action, not the person, and keep it to one sentence. Afterwards I message them privately: "Thanks for stopping. Here is how I would set up the safeguard so it is harder to hit prod by mistake. Want to pair on it?"

Trade-offs and pitfalls

• Public criticism of a person damages trust and teaches others to hide problems.
• Private-only for team patterns means nothing changes, because each person thinks it is only their issue.
• If something in a retro clearly points at one person, take it offline; do not let the room guess.
• Some people want praise privately; ask.
• Cultural norms differ on how comfortable people are with group feedback, so check preferences rather than assuming.

Direct answer

I make each comment specific (point at the line), explain the reason, offer a way forward, and phrase it about the code, not the person. I include one true, specific piece of praise, mark which items must change, and offer to pair (work through it together, live) on the hard one. The aim is that the new hire knows exactly what to do next and feels the review was about their work getting good, not about them being judged.

Principles

• Comment on the code, never the developer (Google's code-review guidance): "this function" instead of "you wrote".
• Explain why: the reader learns a rule for next time, not only this fix.
• Prefer a question or a suggestion with a reason over a command.
• Label severity (Blocking, Consider, Nit) so they can plan.
• Limit the volume. Pick the three most important problems first; the rest can follow in a later round.

Key comments, worded

• Weak: "This is wrong, you forgot null handling (a null is a missing value)."
  Better: "Blocking: if email is null here, line 42 will throw and the request fails. Could we check for null first, or return a clear error? Example: if email is None: return error(...)."
• Weak: "Why did you copy this?"
  Better: "Consider reusing parse_date from utils. It already handles the time zone case, so we avoid two copies to keep in sync."
• Praise that is real: "The tests for the happy path (the normal case where everything works) are clear, thank you for adding them."

ML-model review example

Terms first: a scaler rescales numbers using the data's average and spread. Fitting it means calculating that average and spread. A train and test split holds some data back so the model can be scored on rows it never saw. Data leakage is when information from the held-back rows sneaks into training, like seeing the exam answers before the exam. Tiny example: training values 10, 20, 30 have average 20; if a held-back value of 100 is included in the calculation, the average becomes 40. The test set has quietly shaped the training.

Blocking: "The scaler is fitted on the whole dataset before the train and test split. That lets test data influence the training statistics (data leakage), so the reported accuracy can look better than production. Could we fit it on the training split only and apply it to the test split? It's an easy mistake, and I can show you the pattern." This balances correctness (it is blocking) with encouragement (the mistake is named as common, with help offered).

Unclear commit messages (short role-play)

Reviewer: "Thanks for fixing the blocking items. Can we talk about the commit message?"
New hire: "Is it too long?"
Reviewer: "It's long, but the main point is hidden. A reader skimming history needs the 'what' in the first line."
Before (for the null-email fix above): "fixed stuff and changed the config so the thing works now, also tried some other approach"
After: "Fix null email crash in signup handler" plus a one-line body: "Check email before normalizing; add test for empty email." The config change and the other approach, if they belong in the PR at all, get their own commits with their own first lines.

Trade-offs and pitfalls

• Praise that is generic ("nice job!") reads as a cushion; specific praise teaches.
• Fixing everything for them in the review stops the learning. Offer to pair on one hard point and let them write the rest.
• Do not water down a real bug: if it is a blocker, say so plainly and kindly.

Direct answer

I'll tell this as an illustrative story skeleton. A senior engineer on my project proposed that three new services (separate programs, each owned by a different team) share one database table (one shared set of rows and columns that all of them read and write). I was convinced it would cause cross-team breakages, and he outranked me. I prepared evidence, asked permission to give feedback, framed it as impact and questions, and offered an alternative to try, so the power gap shaped how I spoke without silencing the message.

Situation

He was respected and had designed much of the system. Several teammates had doubts but kept quiet. I was mid-level, and the design review (a meeting where the team examines a proposed design before building it) was in two days.

Managing the power gap

• Be sure I was right to speak: I had seen two schema changes (edits to a table's structure, such as renaming or removing a column) in the previous quarter break other teams' downstream jobs (scheduled programs that read that table and fail when a column they expect disappears). Picture one team renaming a column on Monday and another team's nightly report failing on Tuesday. That was observable, not opinion.
• Prepare and structure: I wrote a half-page: the two incidents, the risk if three services shared one table, and one alternative (each service owns its table and exposes data through an interface, a defined set of calls, instead of direct reads).
• Private first, with permission: "Could I give you a concern about the shared-table design before the review? I'd rather bring it to you than surprise you."
• Questions, not verdicts: "What happens to the other services when the orders table changes? I saw two cases last quarter where that broke downstream jobs."
• Own my uncertainty: "I may be missing a constraint."
• Offer a small test: "Could we try the owned-table approach for the first service and compare?"

What happened

He was quiet, then said I was right about the incidents but that separate tables would cost extra migration work (the effort of moving existing data and code onto the new layout). We agreed to a compromise: shared table only for read-only data (data services look at but never change), with owned tables for anything written. He credited the concern in the review. The relationship stayed good, and he later asked for my review earlier.

Do differently: I'd have raised it a week sooner, not two days before the review.

Pitfalls

Going over his head first, raising it for the first time in a public meeting, or arguing about whose opinion should count for more instead of pointing at observable impact. If the person is your manager, the same method applies, but state the impact on shared goals and what you need.

Direct answer

I would first make sure I understand their objection by restating it and checking the facts, then reply with evidence, not opinion. I concede if their point stands up, hold if I have evidence and the risk is real, and escalate only after a direct conversation has not resolved it, while not letting the PR (pull request, a proposed code change awaiting review) sit.

Step by step

The example used below: the PR makes a payment call that retries on failure. The reviewer worries a retry could charge a customer twice and suggests an idempotency key (a unique token sent with each request so the server recognises a repeat and processes it only once). I think a simpler database rule already prevents it.

1. Pause and restate. "My understanding is that you are worried the retry loop (the code that repeats a failed call) can send duplicate charges. Is that right?" A hard comment is often a real worry stated badly.

2. Separate fact from preference. Is it a claim I can test (a bug, a measurable slowdown) or a style or design preference? Google's published code-review guidance says technical facts and data overrule opinions and personal preferences, and the style guide is the authority on style.

3. Check whether I am wrong. Reproduce their concern with a test. If it fails, concede and thank them.

4. Reply with evidence and the trade-off. "I tried the idempotency-key approach you suggested. It adds a table and a migration (a script that changes the database structure and must be rolled out carefully). My approach avoids that: the payments table already has a unique constraint (a database rule that rejects a second row with the same order id), and here is a test showing a retried call cannot create a second charge. Does that address it?"

   Check the claim against the failure that matters before sending it. A unique constraint only stops a second row in our own table. If the first call timed out after the payment provider had already charged the card, a retry would call the provider again, and no local constraint can stop that. In that case the reviewer is right and the idempotency key (sent to the provider, which many payment providers support) is the correct fix, so I would concede in step 3. My test must therefore simulate a timeout after the provider has processed the charge, not only a repeated local write. My position holds only if the charge record is created first, the provider call carries that record's id, and the provider deduplicates on it.

5. Offer a call if the second reply does not settle it. Text can read harsher than intended.

6. Escalate if still stuck. Google's guidance lists a broader team discussion, a tech lead, a maintainer of the code, or an engineering manager, and says not to leave the change waiting.

Decision table

Close the loop

After a decision, I thank the reviewer, and if I held my position I make sure the decision is recorded in the PR, so the next reader sees why.

What would change my call

A reproducible failing test, a production incident, or a teammate who owns the affected module disagreeing would move me toward conceding.