Q14 of 32 · Behavioural

Describe a time you had to give a developer difficult feedback.

BehaviouralMidbehaviouralfeedbackcommunicationstarmid

Short answer

Short answer: Pick a real case where the feedback was both honest and constructive. Show you led with the behaviour or pattern (not the person), gave it privately and timely, and offered a path forward — not just criticism.

Detail

The interviewer is checking emotional intelligence and your sense of how feedback actually changes behaviour.

STAR walkthrough — sample answer:

Situation: A senior developer on a previous team had a habit of marking PRs as "ready for QA" before they really were — links to the test plan were vague, the staging deploy hadn't been verified, and three out of five times I'd start testing and find the basics didn't work. It was costing me half-days of context-switching, and the developer was visibly frustrated when I came back with "this doesn't even start up."

Task: I needed to address the pattern, but the developer was senior, well-respected, and not someone I had any line authority over.

Action: I avoided the wrong moves first: I didn't message them publicly in Slack, didn't escalate to their manager without trying directly, and didn't accumulate frustration into a confrontation.

I asked for a 15-minute coffee chat. Framed it as: "Can we talk about how PRs handover from dev to QA on this team? I think there's a small thing we could change that would save us both time." When we sat down, I described the pattern — three of the last five PRs had failed the basics in staging — and what it cost me (lost half-days). I made the impact concrete without making it personal.

I asked for their perspective: turned out they were under pressure to mark things "done" by end-of-day for sprint metrics, and "ready for QA" had drifted to mean "I'm done with the code" rather than "tested in staging." Their frustration was at the metric, not at me.

We agreed on a small change: a four-item self-check before marking ready (deploys clean, basic happy path works, staging URL works, test plan link is real). I drafted it; they reviewed it. We took it to the team retro and made it a team convention.

Result: The pattern stopped within two sprints. The developer thanked me later for not letting the frustration build — they'd sensed it but hadn't known how to ask. Two other devs on the team adopted the same self-check.

What I learned: difficult feedback feels confrontational only when it's been bottled up. Given early, in private, and rooted in shared interest, it's a normal conversation.

Why this works: led with the pattern not the person, did it privately, asked for their perspective (which surfaced a real cause), offered a path forward, and the outcome was a team-wide improvement rather than a punitive call-out.

// WHAT INTERVIEWERS LOOK FOR

Private and timely delivery, focus on behaviour/pattern not personality, asking for the other person's perspective, and a constructive path forward. Bonus signal: the candidate didn't escalate or stew — they raised it directly.

// COMMON PITFALL

Telling the story as 'I told them they were doing it wrong and they fixed it.' That signals one-way feedback. The strongest version shows curiosity (you asked their side) and joint problem-solving.