Giving and Receiving Feedback Questions

Direct answer

Here is a story I would tell. A stakeholder challenged a forecast I presented. In the moment I stayed curious rather than defensive: I restated the concern, asked for the specifics, and committed to a date to come back with an answer. I followed up with evidence and credited them, and the result was a changed way of working with that group.

Situation and task

(An illustrative story shape.) I was a data scientist presenting a customer-churn forecast (a prediction of how many customers will leave) to finance and sales leaders. A finance director said, "This number looks wrong. It ignores last quarter's pricing change." My task was to keep the room's trust and find out whether she was right.

What I did in the moment

• Did not defend or explain the model at length. I said: "Let me make sure I understand. You expect the pricing change to affect the group of customers I used as the baseline (the past behavior my forecast extends)?"
• Asked two questions: which accounts were affected, and when did the change take effect?
• Admitted what I did not know: "I'm not sure the model captures that. I'll check and send you an answer by end of day tomorrow."
• Wrote down the concern in front of her.

Follow-up

• I re-ran the forecast with a flag (a yes/no column marking which accounts were on the new pricing), so those accounts could get their own churn rate instead of the average. Illustrative numbers: of 800 accounts, 120 were on the new pricing. The original forecast applied 3% churn to everyone: 800 x 3% = 24 accounts. Early data showed the new-price accounts leaving at about 8%, so the revised forecast was 120 x 8% = 9.6 plus 680 x 3% = 20.4, which is 30 accounts, or 3.75%. The projection rose by about a quarter, so her critique was largely right.
• I sent a short note: what I checked, the before and after, what changed in the assumptions, and a thanks that named her contribution.
• I asked her to review the revised assumptions before sharing more widely.

Result

• The updated forecast became the basis for planning, and the finance team trusted the numbers more because the correction was visible and fast. (Illustrative: the story shape matters more than the figures.)
• Process changes: I added an assumptions page at the start of every stakeholder readout, sent a draft to finance a few days ahead, and added a checklist of recent business events (pricing, launches, policy changes) to compare against before presenting. The assumptions page lists, for example: "Churn rate by customer segment: 3% (last four quarters)", "Excludes: accounts that signed up in the last 30 days", "Not modeled: pricing changes after 1 March". The checklist asks: "Any price or packaging change in the last two quarters? Any product launch or retirement? Any policy or contract change?" I would not claim exact accuracy gains from this; the clearest outcome was fewer surprises in meetings.

What I would do differently

Share the draft with finance before the meeting, so the critique arrives in review, not in the room.

Trade-offs and pitfalls

• Agreeing instantly with every criticism can be as unhelpful as defending. If the critique is wrong, say so with evidence, politely and in follow-up.
• Do not promise a date you cannot meet.
• Make the stakeholder visibly part of the fix.

Direct answer

Good review feedback is specific, explains why, signals how important it is, and is about the code, not the author. The pattern I use is observation, issue, suggested fix, validation, with a severity label so the author knows what must change.

Severity labels (Google's engineering practices recommend this): Nit: a minor thing that technically should be done but will not change much; Optional or Consider: a suggestion; FYI: information for later. I add Blocking: for must-fix.

Three comments, worded out

1. Style nit

"Nit: d is hard to read here. daysSinceLogin would be clearer. Not worth holding up the change."

2. Design flaw with runtime impact

"Blocking: line 84 loads every order for the account and filters in memory. For accounts with tens of thousands of orders, each request holds all of them and gets slower as the account grows. Could we filter in the query (WHERE status = 'open', which asks the database to return only open orders instead of all of them)? Happy to pair on it (work on it together for a short session). A test with a large fixture (a prepared set of sample data, here an account with many orders) would confirm the fix."

3. Security or privacy concern

"Blocking: line 112 logs the whole request body, including email and shipping address. Logs are readable by more people than the database is. Please log only the order id. Can you also check the other handlers for the same pattern?"

What separates good from poor

A bug-shaped comment with repro steps (repro steps are the exact steps to reproduce the problem):

"Blocking: this returns a negative total for an empty cart. Input: a cart with no items and a $5.00-off coupon. Expected: total 0.00. Actual: total -5.00, because the discount is subtracted from a subtotal of 0 with no floor at zero. Could we clamp the total at 0.00, or reject the coupon when the item subtotal is 0?"

Short checklist before posting: Is it specific? Does it say why? Does it say how serious? Is there a next step? Would I be fine reading it aloud to the author?

Pitfalls: nitpicking dozens of style items buries the one real problem (let a linter, an automated style checker, handle style); asking questions as disguised orders; and reviewing by chat tone without ever saying what would make the change approvable.

Direct answer

I'll tell this as a story (illustrative skeleton). A peer on my team kept merging changes (adding code to the shared codebase so it goes live) late on Friday afternoons without telling the on-call engineer (the person on the rota who responds to alerts outside working hours), so the weekend pager (the automatic alert that wakes that person) took the hit. We were friendly, so raising it risked the relationship. I prepared the facts, asked permission to talk, said specific words, and agreed a small change we could both check.

Situation and stakes

In three of the last five weekends, a page was traced to a Friday-evening change from this peer. Nobody had complained to him. I was the person on call, so I had standing to speak. The risk: he was senior in tenure, proud of his speed, and likely to hear "you are careless."

Preparation (what I did)

• Listed the three incidents (one per affected weekend) with dates and what each page cost (hours of weekend time), separating what happened from my theory of why.
• Checked my own part: did the team have a "no Friday deploys" norm? No, so he had broken no rule. That changed my goal from "stop doing this" to "agree a norm together."
• Chose a private one-to-one meeting on a Tuesday, not a Friday or in a public channel, and sent a neutral invite: "Want to talk about how we handle late changes and on-call?"

What I actually said

"When changes land after 4pm Friday without a heads-up, on-call finds out from the pager. That happened on three of the last five weekends, including the cache change on the 14th. I'm not saying the changes were wrong. I'm saying I can't be ready for something I don't know about. How do you see it?"

He bristled for a minute ("they were small changes"), so I agreed they were small and asked what would make telling on-call easy. He suggested a one-line note in the on-call channel before merging.

Where the relationship stood afterwards

Slightly awkward for about a week, then normal. We wrote the "tell on-call before a late merge" line into the team's runbook (the shared how-to document). Two weeks later I told him the weekend pages from changes had stopped and thanked him. The follow-up check was simple: count pages tied to late changes each month.

What made it work

• It built psychological safety (people feel safe to speak and be corrected without punishment) by keeping it private, specific, and about the effect on on-call.
• I owned my uncertainty and invited his view.

Pitfalls

Do not deliver it by chat while angry, do not use "always," and do not skip the follow-up; feedback without a check is just a one-time complaint.

Direct answer

I write the comment around evidence and a question, in the pull request (PR) so there is a record, not around the person's seniority: describe the specific code path, the scale where it breaks, and ask about their assumptions. I mark it as a real concern, offer a way to test it, and if we still disagree I take it to a design conversation with the right owner. Respect shows in the evidence and the tone, not in staying silent.

How to word it

1. Name the behavior and the scale. "This loop issues one query per order row (the N+1 problem: one query to list N rows, then N more to fetch details). With 2,000 rows that is 2,001 queries per request."
2. Ask about assumptions, don't accuse. "What volume do we expect for this endpoint? If it stays small, this is fine."
3. Offer a test. "I can try it against the staging dataset (a test copy of realistic data) and share numbers." Measured results settle debates better than seniority.
4. Suggest a direction. "A single joined query (one query that combines the orders and customers tables), or batching the lookups (fetching many customers in one request instead of one at a time), would avoid it."
5. Label it, with a reason for the line. "Blocking if volumes are expected above ~100 rows; otherwise Consider." The ~100 is a team judgement, not a law. Illustrative arithmetic: if each query costs about 3 ms of round trip, 101 queries add roughly 0.3 s to a request, while 2,001 queries add roughly 6 s. Pick the line from your own latency budget and measured query time, and say so in the comment.

Follow-up

• If a reply is slow, a quick message: "Happy to pair on this if useful."
• If they disagree with evidence on their side, I update my view and say so.
• If we disagree and cannot resolve it: bring both views to the code owner (the person responsible for that part of the code) or the tech lead as a neutral question ("which risk is acceptable?") and write down the decision. Another compromise: merge behind a feature flag (a switch that turns the new code on or off without a new release) with a latency alert (a metric that warns if requests slow down), plus a follow-up ticket.
• Afterwards, keep the relationship warm: acknowledge when they were right about something else.

Worked example

Comment: "Possible performance issue at scale: get_orders calls fetch_customer inside the loop, so 2,000 rows means 2,001 queries (1 for the list plus 2,000 lookups). Is the expected volume small? If not, could we fetch customers in one query with a join? I can run this on the staging data and post the timing. I would treat it as blocking above roughly 100 rows and as a suggestion below that; the 100 is a team judgement, so tell me if the real volume sits on the other side."

Result: they point out the endpoint is limited to 50 rows by pagination (the API returns results in pages of at most 50). That is below the ~100-row line I set, so it is no longer blocking: 50 rows means 51 queries, not 2,001. I say, "Great, that changes it. Could we add a comment noting the limit?" and approve.

Trade-offs and pitfalls

• Deferring to rank lets known risks ship; ignoring rank creates friction. The evidence-first approach handles both.
• Do not make it public theatre: the PR is visible, so keep the tone neutral.
• Being wrong is possible. Ask first; they may know a constraint.

Direct answer

I would ask a short question that shows I want to get it right, not that I disagree: what outcome the reviewer is after, whether it blocks the merge, and what an acceptable change would look like. If the thread has gone back and forth twice, I would take it to a short call or a desk chat and write the conclusion back in the thread.

Example

Comment on a PR (pull request, a proposed code change awaiting review): "This feels fragile." It sits on a function that parses a date.

Clarifying reply in the thread

Thanks for looking at this. I want to make sure I fix the right thing. Is the concern that the parser breaks on dates in other formats, or something about how the function is structured? Is this blocking the merge, or could it be a follow-up? If you have a rough sketch of what you would prefer, I am happy to start from that.

Why the wording works

• It starts with thanks and states the goal ("fix the right thing"), so it reads as engagement, not defensiveness.
• It offers two concrete guesses, so the reviewer can answer yes or no.
• It asks about blocking status, which is the most useful single fact.
• It asks for an example, since "show me" is quicker than explaining.

Thread or in person

• Thread: when the question is narrow and the answer will help later readers.
• In person or call: when the first reply is still unclear, the reviewer seems frustrated, or the change is large. Afterwards, post a summary: "We agreed to handle the other date formats in this PR and leave the refactor for a ticket."

Avoid

"What do you mean?" with no context, or "This is how the other code does it," which reads as defending. Do not guess silently and push a change, since you may fix the wrong thing and add another review round.