The criticism question sounds soft until you watch a hiring panel react to it. The candidate who says “I love feedback, I really thrive on it” loses the room in about four seconds — every interviewer has heard that sentence enough times to tune it out. The candidate who tells a short, specific story about a piece of feedback that stung at first and then changed how they work earns the next ten minutes of the conversation. The question is not asking whether you enjoy being told you’re wrong. It’s asking whether you can hear it, sit with it, and turn it into a change other people can see.

Why interviewers ask this

Hiring managers ask about criticism for three reasons stacked on top of each other: coachability, ego regulation, and growth mindset. Coachability is the cheap one — can you take input from a manager or peer and incorporate it without three rounds of negotiation. Ego regulation is harder to fake — can you hear something uncomfortable about your work without your face changing, without the defensive paragraph, without quietly nursing the wound for a week. Growth mindset is the deepest layer — do you actually believe your skill ceiling is movable, or do you treat each piece of feedback as a verdict on a fixed self.

None of this means interviewers want a masochist. Kim Scott’s Radical Candor framing — care personally, challenge directly — applies in both directions. The interviewer is not testing whether you’ll accept any criticism, no matter how poorly delivered. They’re testing whether, when feedback is real and accurate, you metabolize it instead of metabolizing the person who gave it. Charity Majors writes that most workplace pathology traces back to people being scared to give each other feedback. The candidate who can take it well is rare and disproportionately valuable, which is why this question gets asked so often.

A 2024 Gallup engagement read found that employees who receive meaningful feedback weekly are roughly four times more likely to be engaged than those who don’t — but only when the recipient is actually open to it. The interviewer is screening for the receiving end of that ratio.

The situational-action-result framework

The trap with this question is staying abstract. “I’m open to feedback, I think it’s a gift, I always try to learn” is not an answer — it’s a position statement, and the interviewer will discount it. Use a three-beat structure instead.

• Situational (20-25 seconds). Name the specific piece of feedback you received, who gave it, and what they actually said. The closer you can get to the exact words, the better. “My design lead said the dashboard I shipped was technically correct but unreadable for non-analysts” beats “I once got design feedback.” Specificity is the proof that you remember it, which is the proof that you took it seriously.
• Action (40-60 seconds). What you did with it. Not “I took it on board” — what specifically changed in your behavior, your process, or your output. Did you book a follow-up to understand it better? Did you redo the work? Did you change a checklist, a default, a recurring meeting? This is the load-bearing section of the answer, and it’s the one most candidates rush through.
• Result (20-30 seconds). The measurable change after. Reduced revisions, improved metric, fewer follow-ups from the same critic, a manager comment in the next review cycle. If you can’t quantify, name the qualitative shift in a concrete way — “she stopped flagging it in reviews after that quarter.”

Two minutes total, weighted heavily on the action step. If your answer is half story and half declaration about your values, cut the declaration.

15 sample answers

Software engineer · Code review feedback. “My tech lead told me my PRs were correct but too dense — reviewers were rubber-stamping them because the diffs were unreadable. I’d been treating PR size as a productivity signal. I started capping PRs at 400 lines, writing the description as a reviewer’s reading guide, and splitting refactors into separate commits. Review turnaround on my PRs dropped from about two days to under one, and the same tech lead used my template as the team standard the next quarter.”

Product manager · 360 feedback on listening. “My 360 came back with three engineers saying I ‘decided before the meeting’ — they felt I was running discovery as theater. That stung. I sat with it for a day, then booked 1:1s with each of them and asked for the specific meeting they were remembering. Two named the same one. Since then I open every contentious meeting by writing my current hypothesis on the board and explicitly saying what would change my mind. Engagement in my discovery sessions, measured by how often someone other than me proposes the final direction, went from rare to most weeks.”

Designer · Design critique on accessibility. “A senior designer told me a screen I’d shipped failed contrast in dark mode and I’d never run a contrast checker on the work. I felt defensive — I’d cared about the design — but she was right. I added an accessibility audit step to my personal definition of done, including contrast, focus states, and keyboard navigation. The next quarterly review, the same designer flagged a teammate’s work and used my checklist as the example.”

Data scientist · Stakeholder challenge on a model. “A senior PM pushed back on my churn model in a readout, saying the features I’d chosen were correlated with churn but not causal — predicting it didn’t help him prevent it. I’d been proud of the AUC. He was right that AUC wasn’t his problem. I rebuilt the project around interventions he could actually run and partnered with him on a holdout test for one feature flag. We shipped two retention experiments off that model in the next quarter, where the previous version had shipped zero.”

Marketer · Copy critique from the brand lead. “Our brand lead told me a launch email I’d written sounded like a different company — too aggressive, too feature-listy. I was annoyed because I’d hit the brief. I asked her to mark up the draft in tracked changes, which forced me to see exactly which lines she’d kept versus rewritten. I now do that markup pass on my own first draft before sending it for review, and her edit rate on my copy dropped by about half over the next two quarters.”

Engineering manager · Skip-level feedback. “My skip-level told me my team felt I was ‘available but not present’ in 1:1s — that I’d be on Slack during them or end them early when things were calm. I’d thought I was being respectful of their time. I closed Slack for every 1:1 after that, added a ‘what’s on your mind that isn’t on this agenda’ prompt, and stopped ending early unless they asked to. The next pulse survey, my team’s 1:1 quality score moved up two points and one engineer told me unprompted that 1:1s ‘felt different now.’”

Sales · Customer feedback after a lost deal. “A prospect who didn’t buy told me in a closeout call that I’d ‘sold the product instead of solving the problem’ — they’d needed help mapping the buying committee and I’d spent three calls on features. That landed hard. I rebuilt my discovery script to spend the first call entirely on stakeholders and decision criteria, no demo unless asked. My pilot-to-close rate on deals where I ran that revised script was about 12 points higher over the next two quarters.”

UX researcher · Peer challenge on synthesis. “A peer reviewed my readout and told me I’d cherry-picked three quotes that all said the same thing because they were the most articulate, but they weren’t representative. He was right — I’d skipped the tagging pass. I rebuilt the synthesis with a structured codebook, and the recommendations changed materially. I now run any synthesis with at least one peer reviewing the tag distribution before the readout.”

Software engineer · Architecture review. “A staff engineer in design review told me the service I’d proposed was ‘a database with extra steps’ and would create more on-call load than it solved. I’d spent two weeks on the proposal. I asked him to walk me through what he’d build instead, took notes, and came back the next week with a revised proposal that was about 60% smaller. The simpler version shipped, and he sponsored me for promotion the following cycle.”

Product manager · Engineering pushback on scope. “Our tech lead told me my specs were ‘requirement documents pretending to be product specs’ — lots of constraints, no problem framing. I’d thought I was being precise. I rewrote my spec template around ‘problem, evidence, success metric, then constraints,’ in that order, and asked him to review the next one. He pushed back on roughly a third of what I would have built before — which was the point.”

Designer · Customer feedback in usability test. “Three of five users in a moderated test couldn’t find the export button I’d designed as a clean icon-only treatment. I’d been attached to the visual restraint. I shipped a labeled version the next sprint, and export usage went up about 40% in the first two weeks. I now treat ‘icon-only’ as a design choice that needs to clear a usability bar, not a default.”

Engineering manager · Direct report feedback. “An engineer told me in their 1:1 that my code review comments came across as harsher in writing than I meant them — they were starting to dread my reviews. I’d thought I was being efficient. I switched to leaving the ‘why this matters’ alongside the ‘what to change’ on any non-trivial comment, and started using suggested edits for small things instead of prose. Two months later that engineer told me reviews felt collaborative again.”

Marketer · Analytics lead on attribution. “Our analytics lead told me my campaign reports were ‘attribution fiction’ — I’d been claiming last-touch credit for conversions that started long before my touchpoints. I’d known it was loose; I hadn’t known it was misleading the leadership team. I partnered with him on a first-touch / last-touch dual view for every report, and a multi-touch model for the quarterly. The CMO commented on the new clarity the next QBR.”

Software engineer · Pair programming critique. “A senior I paired with told me I jumped to implementation before I’d fully understood the data model and that I was creating bugs that ‘looked like syntax errors but were really shape errors.’ I started doing a 10-minute schema walk on any new system before writing a line, and bugs in my first two weeks on a new codebase dropped noticeably — my onboarding to a different service the next quarter took roughly half the time it had previously.”

Product manager · Designer’s direct challenge. “A designer on my team told me I’d been treating her as ‘pixel implementation’ instead of as a partner on problem framing, and that I’d been writing solutions into my specs. She was right. I switched to writing specs that ended at the problem and the metric, and started running a 30-minute framing session with her before any design sprint. She told me six weeks later it was the best collaboration she’d had with a PM, and the work we shipped from that quarter was the best either of us had done.”

What NOT to say

Closing move + practice routine

The closing move on this answer is short: name what you do now differently because of the feedback, in one sentence. Not “I’m always open to feedback” — a concrete habit. “I now ask for written feedback in every 1:1 because of that 360.” “I now run a contrast check before I ship any screen.” That sentence is what the interviewer will remember three days later when they’re debriefing.

To practice: pick three pieces of real feedback you’ve received in the last two years. For each, write the exact words (as close as you can), the action you took, and the measurable result. Time yourself telling each one out loud — aim for 90 to 120 seconds. If you can’t get a story under two minutes, the action step is probably bloated; cut to the one specific change. If you can’t name a measurable result, the feedback might not have actually changed your behavior yet, which is worth knowing before you sit in the chair.

If one of your three stories is about feedback you initially disagreed with and later came around to, lead with that one. It’s the strongest signal of ego regulation you can offer — and it’s the answer interviewers remember.

Sources:

• Our Approach: Kim Scott’s Feedback Framework — Radical Candor
• Charity Majors on feedback culture
• How Do You Handle Criticism? — The Interview Guys
• Interview Question: “How Do You Handle Criticism?” — Indeed