Q11 of 32 · Behavioural
Tell me about a time you had conflicting priorities. How did you decide?
Short answer
Short answer: Walk through how you made the trade-off transparent — what the competing demands were, who the stakeholders were, what you used to decide, and how you communicated the choice. Show that you ran the decision *with* people, not silently.
Detail
Conflicting priorities are inevitable; the test is whether you handle them with structure and transparency, or by working frantically to avoid disappointing anyone.
STAR walkthrough — sample answer:
Situation: I was the QA lead on two parallel initiatives at a previous job. One was a major feature release with a fixed launch date driven by a partnership. The other was an audit-driven initiative to harden security testing across the platform — important but date-flexible. Both had landed in the same sprint and both had stakeholders who wanted "the right amount of QA attention."
Task: I had one of me, and roughly a sprint and a half of work between the two if I tried to do both fully. I needed to make a call rather than ride the middle.
Action: Three steps:
- Mapped the trade-off honestly. Wrote a one-pager: "feature release needs ~2 weeks of focused QA; security work needs ~1.5 weeks; I have 2.5 weeks. Here's what gets cut on each side under three options."
- Took the options to the people who owned the priorities — engineering manager, product manager, security lead. Not as a complaint but as "these are the trade-offs; help me pick the one that's least bad for the company." That conversation reframed the choice from "QA failure" to "a real prioritisation call."
- We agreed on a specific scope: fully cover the release, defer the deeper parts of the security work to the next sprint, but not skip security entirely — I did a focused pass on the auth flow as the highest-risk area.
I also followed up with a short note to all three stakeholders confirming the decision in writing, so nothing was ambiguous.
Result: Release shipped clean. Security work completed two sprints later instead of one. The security lead later told me they'd appreciated being part of the conversation rather than being told "we'll get to it." The eng manager started using the same one-pager pattern when their team faced multi-priority sprints.
What I learned: priority conflicts feel like personal stress, but they're usually organisational signals. Making them visible converts your stress into a decision the right people can make.
Why this works: shows a framework (one-pager with options), brings stakeholders in rather than silently absorbing the conflict, written follow-up for accountability, and a downstream impact (the pattern was adopted elsewhere).