Q21 of 32 · Behavioural
Tell me about a time you had to convince leadership to adopt a new testing approach.
Short answer
Short answer: Show that you brought a business case, not just a technical preference. Concrete data, an honest framing of cost and risk, a pilot proposal, and a measurable success criterion are the elements that move leadership.
Detail
Convincing leadership is a craft. Pure engineering arguments rarely land; framing in terms of risk, speed, or revenue does.
STAR walkthrough — sample answer:
Situation: A previous company's main API testing was done in Postman collections, run nightly, with manual reporting. Coverage was limited, runs were brittle, and adding cases required GUI work that didn't review well in PRs. I wanted to move us to a code-based approach (Playwright APIRequestContext or similar) integrated into PR CI.
Task: I needed sign-off from the engineering director, who'd previously rejected a similar proposal from another QA engineer 18 months earlier on cost grounds.
Action: I built the case carefully:
Cost of the status quo, in numbers. Pulled a quarter of bug data: 11 production bugs in API logic, of which 7 had escaped because the Postman suite either didn't cover them or had been silently skipped. Estimated incident-response time per bug + customer-impact cost. The number was meaningful.
Cost of the change, honestly. Migration was about 6 weeks of effort, plus ongoing maintenance. I included it in the proposal upfront — leadership respects honesty about cost more than rosy projections.
Pilot rather than big bang. I proposed migrating one API area first (the highest-bug-rate one), measure for 6 weeks, and only proceed with the rest if the pilot delivered specific outcomes: at least 30% reduction in escape rate, no increase in maintenance time per test.
Met the director in their language. Wrote a one-page memo: "Recommended approach to API test debt — risk, cost, pilot proposal, success criteria." No tooling discussion in the body — just enough detail in an appendix for someone to reach the same conclusion.
Anticipated the previous objection. The earlier rejection had been on cost grounds. I cited that explicitly: "the prior proposal was reasonably rejected on cost; this one is structured to validate value before committing the full cost."
The director approved the pilot in a 20-minute conversation.
Result: The pilot delivered: escape rate in that area dropped from 7 to 2 over the 6-week pilot; maintenance time was lower because tests reviewed in PRs. The director approved the full migration without hesitation. We finished it the following quarter and the approach became the team standard.
What I learned: senior IC influence is largely about respecting the decision-maker's job. They have to weigh many trade-offs; making it easy for them to say yes (pilot, measurable bar, honest cost) is half the work.
Why this works: data-driven, business-language framing, pilot reduces commitment, references the previous objection, and the outcome legitimised the decision.
// WHAT INTERVIEWERS LOOK FOR
// COMMON PITFALL
// Related questions
Tell me about a time you advocated for testing investment when leadership wanted to ship faster.
Behavioural
How do you decide what to test when deadlines are tight?
Behavioural
How do you advocate for testing investment with a leadership team focused on shipping fast?
Manual & exploratory
Your team has been using 'commit everything directly to main' for 2 years. How do you lead the transition to a PR-based workflow with branch protection, and what are the biggest risks?
Git