Run a mock round

Show a non-defensive, growth mindset.

Example: "In a 360 review my tech lead said my pull requests were technically strong but hard to review because they were huge and lacked context. My first reaction was frustration, but I asked for specifics. I started splitting work into smaller PRs, writing a short summary of the approach and tests, and adding screenshots for UI changes. Review turnaround dropped from two days to a few hours and reviewers caught fewer issues."

Structure: the feedback, your initial reaction and how you processed it, the concrete change, and the measurable outcome. Mention that you actively seek feedback now.

Use STAR and show respect plus results.

Situation: "A teammate wanted to ship a caching layer right before a major release."
Task: "I was responsible for release stability."
Action: "I asked for a 30 minute design review, laid out the risks with data from our last incident, and proposed a compromise: ship the feature behind a flag and add caching the following sprint. I listened to his points about latency and we agreed on the flag as a middle path."
Result: "We released on time with zero critical incidents, and caching shipped two weeks later with monitoring in place."

Show that you challenge ideas, not people, escalate constructively, and can commit once a decision is made.

Choose a failure that is real but not catastrophic, and focus on learning and corrective action.

Situation: "I estimated a feature at two weeks; it took six."
Task: "I owned the estimate and the delivery."
Action: "I traced the cause: I had underestimated integration work and did not surface the risk. I told stakeholders immediately rather than hiding it, negotiated a reduced first release, and adopted a checkpoint approach with estimates for unknowns."
Result: "We shipped the core in three weeks and the remainder in a follow-up. I now add explicit buffers for unknowns and flag risk in week one."

The interviewer is testing honesty, self-awareness, resilience and whether you improved.

Give a real example and a repeatable method.

Method: "I first clarify the true deadline and what 'done' means, then prioritise ruthlessly using impact versus effort. I cut scope before quality, communicate trade-offs early to stakeholders, and break work into shippable increments so there is always something working."

Example: "We had two weeks to meet a compliance deadline. I mapped the mandatory requirements, deferred nice-to-haves into a documented backlog, set up a checklist with QA, and used a daily async update. We delivered on time with all mandatory controls and no crunch weekends."

Signal calm prioritisation, transparency and that you protect quality where it matters. Avoid glorifying burnout.

Show a learning system, not just a story.

Example: "We inherited a Go service with no tests and I had never written Go. I gave myself three days: I read the standard library style guide, built a small CLI to learn the toolchain, then paired with the original author to map the critical paths. I wrote characterisation tests for the riskiest handlers before refactoring. Within two weeks I was reviewing Go PRs and we had 70% coverage on the service."

Method to mention: define the minimum viable knowledge, learn by building, use primary documentation, ask targeted questions, and validate understanding by teaching or testing.