How do you keep delivering when priorities shift every few weeks?
answer
- name your default slice size
- one agreed source of current priority
- keep choices cheap to undo
- one short instance, not a philosophy
- the cost you accept, said out loud
basics
~20 sProbes whether churn makes you thrash or adapt. Answer with a working method — small shippable slices, choices that stay cheap to undo, one agreed source of current priority — plus one short instance proving you actually work that way.
how to answer
5 beats- your default working rhythm, in one sentenceOpen with the habit that does the most work — slice size, branch lifetime, demo cadence. One sentence, stated as what you do rather than what you believe, so the rest of the answer has something to hang on.
- how the current priority stays visible and agreedSay where the truth lives and what you do when a request arrives outside it. The signal is that a reorder becomes a visible decision someone else can see, rather than a private adjustment in your head.
- how you keep choices cheap to undoName the mechanics: toggles, thin vertical slices, adapters, deferring the parts that are expensive to reverse. Also name the few things you deliberately fix early, so this does not sound like avoiding every commitment.
- one short instance from your own workThirty to forty seconds, with a number. The instance is what separates you from a candidate reciting a method. Pick a reorder that cost little precisely because of the habits you just described.
- the cost you accept, named honestlyClose by naming what your approach costs — context switching, toggle cleanup, slower first delivery — and how you pay it. Candidates who claim pure upside sound rehearsed; one honest cost makes the rest credible.
your answer
4 story prompts- List your last three priority switches and how much in-flight work each one cost.
- Name the habit that made one of those switches cheap: slice size, toggle, or a handover note.
- Pick one instance from the past year where a reorder cost you almost nothing, and why.
- Write one honest cost of your approach, so the answer is not pure flexibility.
draft and rehearse your own answer in a learn session
go deeper
This probes working style and prioritization judgement rather than a single episode. The interviewer wants to know whether frequent re-planning makes you thrash, hoard half-finished work, or let commitments quietly disappear — and whether you have habits that make a change of direction cheap. A strong answer names concrete practices, gives one instance that proves them, and admits the cost you accept.
At the agency I am at now I am usually split across two client accounts, and the order changes at the Monday triage — a campaign lands, or a bug report jumps ahead of feature work. Three habits stop that becoming thrash. I keep branches short: almost nothing I have open lives past two days, so when something is dropped, at most a day and a half of my work goes with it. I keep one source of order — whatever sits at the top of my column in the tracker is what I am on, and when a request reaches me in chat I move the card before I move any code, so nobody has to guess what I am doing. And when something has to pause, I leave it pickup-ready: branch pushed, plus a couple of lines in the ticket about where it stops and what is untested. The proof is small but real. When a checkout module got deprioritized in the middle of an engagement, handing it back took about an hour, because it was three merged slices rather than one long branch nobody else could read. The cost I have learned to say out loud is that a switch costs me roughly half a day of context, so I ask for it to be a decision rather than a drive-by.
This answers with habits and then proves them with one small, checkable instance instead of a philosophy. Naming the switching cost aloud reads as honest rather than infinitely flexible. Without the concrete instance it would be indistinguishable from a slogan, which is the usual failure on this prompt.
I own the shared component layer that three client sites here build on, so a shift in one client's plan lands on other people's work, not only mine. The rhythm I hold is a thin slice behind a toggle, demoed every Thursday. Nothing sits half-finished on a branch for a month, which means a change of direction costs a slice rather than a sprint. Beyond that, two habits do the real work. I keep a short living document of the choices that are still cheap to reverse and the two that are not — for us the routing model and the token contract are effectively fixed — so when a client asks for a pivot I can come back within the hour with what it costs and what it does not. And I treat a reorder as a conversation with the other two site teams rather than an announcement, because my queue moving silently is exactly how they end up blocked. When one client reordered their roadmap in the fifth week of an eight-week engagement, we dropped two of the seven planned modules with no rework, since none had grown tendrils into the others. Session crash rate across the three sites held at 1.2% through that stretch. The honest cost is that a toggle-heavy codebase rots, so I book half a day each release to delete dead paths, and I say that when I propose the approach.
The middle-level move is scope: reorders here hit other teams, and the answer shows both a way to price a pivot within the hour and the habit of negotiating rather than announcing. Dropping the list of what is still cheap to reverse, or the maintenance cost admitted at the end, would flatten it into generic flexibility.
Talk about your own queue: how you find out what is top of the list today, how small you keep work in progress, and how you leave a paused task in a state someone else could pick up.
Others depend on your output, so show you keep collaborators unblocked when your own order changes, and that you surface the cost of a switch rather than letting a commitment fall off the list unannounced.
You shape the cadence, not just survive it. Show release rhythm, the seams that stop a reorder from rippling, and the churn you declined because it had no owner or no cost attached.
Speak to the mechanism at org scope: how priority gets decided and published so shifts arrive as costed decisions, and what changed in delivery predictability once that mechanism existed.
saying these in an interview costs you the question
- A tidy process with no example that you have ever lived it
- Presenting yourself as endlessly flexible with no cost named
- Complaining that reprioritization is just bad management
- Claiming you absorb the churn by working longer hours
- Long-lived branches defended as thoroughness, making every shift expensive
- Dropping commitments quietly, with nobody told the order changed
- What is the most disruptive priority change you have had to handle?Pick one instance and keep it to sixty seconds — this is a probe, not a second story. Say what was in flight, what it cost to stop, and what you did to make the stop cheap. If it was genuinely expensive, say so; an answer where every switch is free is not believable.
- How do you decide what to drop when something new comes in?Show that dropping is a decision with a named owner, not something that happens by neglect. Describe how you compare the new item against what is in flight, who you take that comparison to, and how the drop gets recorded so nobody discovers it later. Mention what you refuse to trade away, such as a security fix or a committed date.
- When do you push back on a change of priority?Give a threshold rather than an attitude. Reasonable ones: when the switch costs more than it gains and nobody has seen that number, when it arrives from someone without the standing to reorder, or when it would break a commitment already made to another team. Show that pushing back means presenting the cost, not refusing the work.