Top 17 Prioritisation Interview Questions
Browse 17 real-world technical and behavioral interview questions about Prioritisation. Review scenarios, edge cases, and architectural best practices.
Your largest customer, worth 15% of revenue, wants a feature nobody else has asked for, and renewal is in eight weeks. How do you decide whether to build it?
Separate the leverage from the merit: the renewal makes the request urgent, it does not make it valuable. Work out the real problem underneath the requested solution, test whether it generalises to other accounts, and price the full cost including permanent maintenance rather than the build estimate. Then choose deliberately between roadmap, configuration, services and no.
Your Product Backlog has grown past four hundred items and refinement takes two hours a week without anything getting clearer. What would you change?
Treat the backlog as inventory with a carrying cost, delete rather than archive the items nobody will ever order, and derive how deep to refine from the team's measured throughput instead of refining everything. Refinement that clarifies nothing is usually missing a decision, not a better format.
Tell me about a time you had to deliver with unclear requirements or a deadline you did not believe in.
Show that you made the ambiguity smaller before you started coding, that you wrote down the assumptions you were proceeding on, and - for the deadline half - that you renegotiated scope early with evidence rather than absorbing the pressure silently and missing the date.
Tell me about a time you fixed something nobody had asked you to fix.
Pick unasked work that solved a problem other people were feeling, show that you sized it before starting and told someone you were doing it, and be able to say what you chose not to fix — unsanctioned effort only reads as initiative when it was also disciplined. Use this ownership answer to show the decision, trade-off, and evidence rather than a memorised definition.
Your advocacy team can either build things - an SDK, sample apps, better reference docs - or publish things: posts, talks, videos. Both compete with the product roadmap for the same engineering time. How do you decide the split?
Decide by where developers are dropping out. Build when the blocker is inside the integration and repeats for every developer; publish when the blocker is awareness or a mental model. Then price the build option honestly, because an SDK is a permanent maintenance commitment, not a project.
Every stakeholder says their item is urgent. How do you decide what goes into next quarter?
A framework's job is to make the trade-off legible, not to produce a verdict: ring-fence hard-dated and reliability work first, score the discretionary remainder on one agreed model, and communicate each no as what it displaces plus the condition that would reverse it.
Tell me about a time you had far more work than you could deliver. How did you handle it?
Name the competing demands, say what you dropped or deferred and who agreed to it, and describe how you told the people whose work was affected. Interviewers listen for a decision made in the open, not for evidence that you absorbed the overload quietly.
The bid is due in five days, three technical sections are unanswered and the clarification window has closed. How do you run the last five days?
Triage against the published scoring weights rather than by discomfort, freeze the solution and the price on day one, spend the remaining capacity on unanswered high-weight requirements and the compliance matrix, and reserve a full day for a red-team read and submission mechanics.
You are prioritising the backlog for a product that has no users yet, so there is no reach or impact data. How do you rank it?
Stop ranking by value, which you cannot know, and rank by uncertainty instead: sequence the work that would most cheaply tell you the whole idea is wrong. Scoring frameworks fed with invented numbers launder a guess into a decision, and their real cost is that nobody revisits the guess.
How do you force product leadership to prioritize paying down toxic technical debt in a hyper-growth scale-up that only cares about shipping features?
A cynical engineering leader's framework for categorizing technical debt, quantifying business risk, and negotiating with product managers. Use this engineering leadership answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects tech debt to the point an interviewer is testing.
Your Product Owner says everything in the sprint is top priority and refuses to rank the backlog. How do you handle it?
Do not argue about priority in the abstract; make the cost of not choosing visible by showing capacity against the ask, then force a decision through a mechanism that requires ordering rather than asking for agreement.
The platform migration has no user-visible benefit. How do you rank it against features customers are asking for?
Convert the migration into the units the roadmap already uses by pricing its carrying cost and the cost of delaying it, then rank it on the same scale as features rather than arguing for it as a special category that deserves exemption. Use this prioritisation answer to show the decision, trade-off, and evidence rather than a memorised definition.
A stakeholder says the new request is not a change, it is just a clarification. How do you handle that?
Stop arguing about the label and test the request against the accepted criteria: if the behaviour or the effort changes, it is a change whatever it is called. Hand the product owner a delta and options rather than a refusal, and keep a log so a fortnight of small clarifications stays visible.
Feature delivery and paying down architectural debt are competing for the same engineers. How do you decide the split and defend it?
Stop treating debt as a backlog of tasks and express it as a rate — the interest you are paying in change lead time, incident load and onboarding cost — then fund only the remediation that measurably moves one of those numbers. A fixed percentage tax is easy to agree and the first thing cut under pressure.
Your team wants to rewrite a service that works. How do you decide, and how do you say no if that is the answer?
Make the team convert the ask into a measured cost the current service imposes and a payback period, then test whether an incremental route reaches the same place. Say no on the arithmetic rather than on authority, and if you say yes, agree in advance what would make you stop.
You committed to three things this quarter and it is now clear only two will land. How do you decide which one goes, and who do you tell?
Work out the shortfall in engineer-weeks so the gap is arguable, then rank the three on value at risk and on what other people committed on the strength of your date, take the trade-off to whoever owns it rather than deciding quietly, and stop the dropped item cleanly.
Two engineering teams in your program each insist their work has to come first, and both leads have dug in. You have no authority over either. How do you get to a decision?
Convert a priority argument into a sequencing question with a stated cost, because two teams can both be right about importance while only one ordering is cheaper. Find the shared constraint, price each ordering against it, then take the residual disagreement to the one person who owns both.