Coachability and Feedback Reception Questions

Assesses a candidate's ability to receive, interpret, and act on constructive feedback from managers, peers, and mentors. Covers proactively seeking feedback, processing initial reactions without defensiveness, implementing suggested changes, tracking measurable improvements, and integrating coaching into onboarding and day to day work. Candidates should provide concrete examples of feedback received, the specific actions taken in response, how they monitored progress, and the outcomes achieved. The topic also evaluates mindset and behaviors such as humility, learning orientation, and sustained behavioral change over time. For junior candidates emphasize openness to learning, following guidance, and rapid skill acquisition; for senior candidates emphasize modeling coachability, mentoring others while remaining open to peer and stakeholder input, and using feedback to improve team processes and performance.

EasyTechnical

27 practiced

How do you proactively seek feedback while working on a feature or a codebase? Describe specific tactics you use (for example: targeted PR descriptions, short check-in meetings, pairing sessions, or feedback surveys), the cadence you prefer, and how you ensure the feedback is actionable.

MediumBehavioral

28 practiced

Describe a time when you disagreed with feedback from your manager about prioritization. Explain how you raised your concerns, what evidence or data you presented, how you balanced respect and persuasion, and what the final outcome was.

MediumTechnical

23 practiced

How would you turn repeated feedback about weak documentation into a sustainable team-level change? Describe both individual-level actions (templates, ownership) and process-level changes (doc reviews, definition of done), and how you would measure adoption over time.

Sample Answer

Situation: My team received repeated feedback that technical docs (APIs, runbooks, design notes) were incomplete or out of date, causing onboarding delays and incidents.

Task: Turn that feedback into a sustainable, measurable team-level change so docs stay useful and findable.

Action — Individual-level:- Introduce lightweight templates for common doc types (API, architecture, runbook) with required sections (purpose, usage, examples, owner, last-updated, testing steps). Host templates in the repo/docs site.- Assign clear ownership: each feature/component has a named doc owner responsible for accuracy; rotate ownership in triage to avoid single points of failure.- Make doc writing part of the developer workflow: include example snippets and small checklist in PRs; require docs for surface-changing PRs.- Provide short brown-bag training and sample good/bad docs.

Action — Process-level:- Add "Documentation" to the Definition of Done: PRs that add/remove behaviour must update docs or justify no-change.- Include doc review in code review checklist and create a lightweight doc-reviewer role per sprint.- Schedule quarterly doc audits tied to sprint planning to refresh critical pages.- Automate freshness checks: CI lints frontmatter (owner, date), flags pages older than X months, and surfaces them in backlog.

Measurement — adoption over time:- Leading indicators: % of PRs with doc updates, number of doc-review comments per PR (should drop as quality improves), auto-lint pass rate.- Lagging indicators: average time-to-onboard (new hires), number of incidents traced to missing docs, search click-through rate on docs site.- Track ownership coverage (percent of components with current owners) and doc staleness (age distribution).- Review metrics monthly; present trends in sprint retro and adjust thresholds (e.g., flag age) after 2 quarters.

Result expectation: Within 2–3 sprints the team normalizes including docs in PRs; within a quarter stale-docs drop, onboarding time and doc-related incident frequency measurably improve. Continuous automation plus clear ownership keeps the change sustainable.

HardTechnical

25 practiced

Propose a rubric to evaluate coachability during interviews for software engineers at multiple levels (junior, mid, senior, staff). Include behavioral indicators, sample interview questions, scoring guidelines, and a calibration process for interviewers to reduce bias.

Sample Answer

Rubric: Coachability for Software Engineers (Junior / Mid / Senior / Staff)

Scoring: 1–5 scale (1 = Resistant, 3 = Accepts feedback, 5 = Proactively seeks & applies feedback). Use behavioral anchors per level; collect evidence (quote/behavior) and a short justification.

Behavioral indicators- Junior (IC1–IC2): Receptive to instruction, asks clarifying questions, applies correction in next task, shows growth mindset.- Mid (IC3): Seeks feedback, experiments with suggested approaches, reflects on trade-offs, documents lessons learned.- Senior (IC4): Solicits feedback from peers, mentors juniors based on learnings, iterates on architecture/design after critique, shows measurable improvement.- Staff (IC5+): Creates feedback loops across teams, institutionalizes lessons (playbooks/standards), influences process change from feedback, models vulnerability and learning.

Sample interview questions (pick 2–3 per interview)- Tell me about a time you received critical feedback on your code/architecture. What did you do? (All levels)- Describe a change you made after a code review that improved the system. Why did you choose that change? (Mid+)- How do you onboard feedback from non-engineering stakeholders? Give an example. (Senior+)- Describe when you taught a team process improvement that came from a failed project. How did you get buy-in? (Staff)- Role-play: I disagree with your approach — how do you respond? (Behavioral + live interaction)

Scoring guidelines (anchors)- 1 — Defensive: Blames others, repeats same behavior.- 2 — Reluctant: Accepts feedback but minimal follow-through.- 3 — Competent: Accepts, applies, shows one concrete improvement.- 4 — Strong: Proactively asks, iterates, mentors others using insight.- 5 — Exceptional: Systematically converts feedback into team-level change; measurable impact.

Calibration & bias mitigation1. Training: 1-hour calibration session with definitions, example answers mapped to scores.2. Anchors: Provide two written anchor responses per score per level (good/poor examples).3. Blind notes: Interviewers take structured notes (behavior, quote, impact) without noise like education or demographics.4. Group calibration: Weekly 30–45min panel to review borderline hires; discuss evidence, not gut feelings.5. Rubric enforcement: Require at least one concrete example in notes to justify >3 score.6. Metrics & audits: Track inter-rater agreement, appeals, and post-hire performance vs. coachability scores every 3–6 months.7. Continuous improvement: Feed outcome data back to update anchors and interviewer training.

Use this rubric as a guide—requireers should adapt language to job level and include at least one behavioral and one scenario question per interview.

MediumBehavioral

27 practiced

Imagine you receive feedback that your PR comments come across as terse and demotivating. How would you change your review style to be more constructive? Provide concrete wording patterns, techniques to empathize, and how you would measure whether your tone changed in reviewers' perception.

Sample Answer

Situation: A teammate told me my PR comments felt terse and demotivating after a sprint—they were less likely to ask for reviews and became defensive in threads.

Task: I needed to change my review style so feedback stayed honest and actionable but became constructive and motivating, restoring collaboration.

Action:- I adopted the STAR/FEEDBACK approach for reviews: start with a specific Strength, then a Target (what to change), then clear Actionable steps.- Concrete wording patterns I used: - Praise + reason: "Nice: the component has clear prop validation — that reduces runtime errors." - Request, not demand: "Could we consider extracting X into a helper? It would make testing simpler; what do you think?" - Explain impact: "This loop could be O(n^2) for large inputs — if we switch to a map, it avoids potential perf regressions." - Offer help: "If you'd like, I can pair on the refactor for the mapping logic." - Softening buffers for hard asks: "I suggest..." / "Would you be open to...?" / "One possible improvement is..."- Empathy techniques: - Read the code/PR twice to understand intent before commenting. - Ask clarifying questions before assumptions: "Can you explain the reason for X? I want to avoid breaking an intended edge case." - Use "I" statements to own perspective: "I'm concerned that..." instead of "You did..." - Time feedback: prioritize critical issues, defer style nitpicks to linter or a separate pass.- Process changes: - Added a short PR checklist and a "what I want reviewers to focus on" section so comments are targeted. - Set a personal rule: every PR must include at least one positive note.- Measurement of change: - Short-term: asked the original teammate for follow-up feedback after two weeks and used a 3-question anonymous pulse (tone, clarity, helpfulness) — aim: improve average score by 1 point on a 5-point scale. - Behavioral metrics: increased number of review requests to me, fewer defensive replies, shorter comment threads, fewer reverts due to misunderstandings. - Qualitative: solicit recurring feedback in retrospective and check whether teammates volunteer for pairing after my reviews.

Result: Within a month teammates reported reviews felt more collaborative. My pulse survey moved from 3.1 to 4.2/5 on tone, and PR threads became briefer and more solution-focused.

This taught me that clear, empathetic phrasing plus process changes (checklists, focused asks) create better outcomes without sacrificing technical rigor.

Unlock Full Question Bank

Get access to hundreds of Coachability and Feedback Reception interview questions and detailed answers.

Join thousands of developers preparing for their dream job.