Behavioral Interviews: Prioritizing Competing Work

“How do you prioritize when everything is urgent?” or “Tell me about a time you had competing priorities” both sound like invitations to describe your productivity system. They aren’t. Interviewers have heard plenty about to-do lists and calendar blocking. What they want to hear is a real choice: two or three things that couldn’t all happen, how you decided, and what you did about the thing that lost.

What the interviewer is checking

Behind the question are four smaller ones. Do you have criteria, or do you work on whatever arrived last? Do you make the trade-off visible, or does someone discover a week later that their request quietly slipped? Do you know which decisions are yours and which belong to your lead or product manager? And can you say “not yet” without damaging the relationship?

An answer that ends “and everything got done” usually fails all four, because it means no trade-off was made.

Criteria that hold up in a real week

You don’t need a formal framework, but you do need reasons. These are the ones that tend to matter most for engineering work:

Impact. How many users, how much money, how much risk?
Cost of delay. What gets worse if this waits a week? A bug that corrupts more data every day is different from a feature that ships seven days later with no other change.
Hard dates. A billing run, a regulatory deadline, or a partner’s launch can’t move. Most internal targets can.
Who’s blocked. Work that unblocks three teammates often beats work that only you depend on.
Effort. A two-hour fix that removes a daily annoyance can jump the queue.

Atlassian’s guide to prioritization frameworks covers named methods like RICE (reach, impact, confidence, effort) and MoSCoW (must, should, could, won’t). Mentioning one is fine, but interviewers care far more about how you applied your reasoning than which acronym you used.

Worked example: an invoice bug against a partner deadline

Here’s an illustrative scenario showing the structure. Build your own from a week when you really had to choose.

You’re halfway through a sprint, building a webhook API that a partner plans to start using next Friday. On Tuesday, support reports that invoices for customers billed in Japanese yen show fractional amounts, because the code rounds every currency to two decimal places and yen has none. The next monthly invoice run is in five days and covers about 300 affected customers. The same day, a teammate asks for a review of a large pull request, and your manager wants a draft estimate for next quarter’s work by Thursday.

A weak answer (illustrative):

I’m very organized. I make a to-do list every morning, put the most important things first, and I’m happy to put in extra hours so that everything gets done on time.

It describes a habit, not a decision, and “extra hours” hides whatever was actually traded away.

Stronger version (illustrative; your criteria and details will differ):

Mid-sprint, I was building a webhook API a partner was due to start using the following Friday. On Tuesday, support found that invoices for yen customers showed fractional amounts, because we rounded every currency to two decimals. The next invoice run was five days away and would affect about 300 customers.

I put the bug first. It had a hard date, it affected customers’ money, and the longer it waited the less time we’d have to test the fix before the run. I estimated a day and a half including tests against every currency we bill in. That put the partner deadline at risk, so I looked at what the partner needed on day one. They needed event delivery; the retry dashboard I’d planned could follow a week later. I told the product manager straight away, and she confirmed with the partner.

For the smaller requests, I asked my teammate whether the review could wait until Thursday or whether someone else could take it; another engineer picked it up. I told my manager the estimate would come Monday instead of Thursday, and he was fine with that. The currency fix went out on Thursday, before the run, and the webhook API shipped on Friday without the dashboard, which followed the next week.

The candidate states the criteria (hard date, customer money, cost of delay), finds a scope change that protects the second deadline, and tells every affected person what moved.

Making the trade-off visible

Every yes to one thing is a no, or a “later,” to something else. The part of prioritization people remember is whether you told them.

A short message does most of the work: “I’m taking the yen invoice bug because the run is on the 1st; that moves the estimate doc to Monday. Let me know if that’s a problem.” It names the choice, gives the reason and gives the other person a chance to object while it’s still easy to change. In an interview, describing that message shows more maturity than any framework.

Deciding which choices are yours

Not every prioritization call belongs to you. If two product managers both want your time for their own projects, choosing between them yourself puts you in the middle of a disagreement that isn’t yours to settle. The better move is to bring the conflict to whoever sets priorities, usually your lead, with a recommendation: “Both of these need about a week. I’d suggest the billing work first because of the invoice date. Can you confirm with both of them?”

Interviewers, especially for senior roles, listen for this distinction. Making every call yourself can look decisive, but it can also mean you’re making decisions other people should own.

Mistakes that weaken the answer

Productivity tips instead of a decision. Lists and time blocks aren’t trade-offs.
Overtime as the resolution. It may be true, but it means nobody chose.
Loudest request wins. Saying you prioritized whatever your most senior stakeholder asked for suggests you didn’t weigh it.
Silent deferral. The deferred person finding out late is often worse than the delay itself.
Choosing the interesting work. Interviewers can tell when the criteria were invented after the fact.

Follow-up questions to expect

“What if your manager had disagreed with your order?” Explain your reasoning once, clearly, and then follow their decision, because they may know about commitments you don’t.

“How do you handle interruptions day to day?” Talk about how you protect focused time and when you allow interruptions, such as for incidents or anything blocking a teammate.

“Tell me about something you decided not to do at all.” A good answer shows you can drop work deliberately and explain why to whoever asked for it.

Interview practice: rank three requests

You have three things on your plate. A flaky test fails about 30% of the time and is blocking teammates’ merges. A feature you own is due in two weeks and is on track. A senior leader has asked for a one-off data export “when you get a chance.” What order do you take them in, and what do you tell each person?

Answer and reasoning

The flaky test goes first, but with a time limit. It blocks several people several times a day, so its cost of delay multiplies across the team. Give it half a day: if the cause isn’t found, mark the test as quarantined, open a ticket with what you learned and tell the team, so merges are unblocked either way.

The feature is next and continues as planned, since it’s on track with a date two weeks out. Mention in your update that you spent half a day on the test, so nobody is surprised if the margin shrinks.

The data export needs one question before it can be ranked: when does the leader actually need it? “When you get a chance” sometimes means Friday’s board meeting. Ask, then schedule it to fit. If it needs to be done this week and it threatens the feature, take that conflict to your lead rather than deciding alone.

A strong answer ranks the items by cost of delay, puts a time box on open-ended work, asks for missing information instead of guessing, and says who hears about each decision.