The competing priorities interview question is usually decided by one follow-up. The interviewer asks what you dropped. A strong answer names four things. Say which item lost and what it cost someone. Say how you ranked the items, by what happens if each one slips. Say who made the final call and what you brought them. Then say what you did to soften the cost. Answers that fail this follow-up sound alike. Some say everything got done because you worked late. Others describe a ranking method, like an urgent and important grid, with no example of it in use. Neither shows a trade-off. If nothing lost, the interviewer hasn’t seen you choose. The rest of this post follows one Android engineer through a real kind of collision. A Google Play target API deadline landed on a sprint already full of feature work.
The competing priorities interview question turns on the item that lost
Most versions of this question sound like a test of organization. “Tell me about a time you had competing priorities.” “How do you handle two deadlines at once?” The follow-ups usually settle the score. “What did you deprioritize?” “Who disagreed?” “What did that cost?”
Amazon’s leadership principles show why. The page carries no date. Deliver Results says leaders “focus on the key inputs for their business.” Focusing on some inputs means not focusing on others. An interviewer scoring that principle needs to hear what you set aside.
So “I stayed late and shipped both” is a weak answer. It shows effort. Because no choice was made, it gives the interviewer no judgment to score. It can also raise a worry the interviewer won’t say out loud. Will this person overload themselves on my team without telling anyone?
A real trade-off costs someone something
The dropped item has to matter. If you deprioritized a cleanup task nobody was waiting for, the story has no tension. The interviewer can’t tell whether you’d make a hard call.
Pick a story where the losing item had an owner. A product manager wanted it. A teammate was blocked on it. A date had been promised. Then the cost is concrete. Someone had to change a plan because of your ranking.
The cost also tells the interviewer how big the story is. Moving a code review by a day is a small trade. Moving a launch date is a larger one. Pick the size that fits the level you’re interviewing for. If the slip turned into a missed date, that’s a different question. Our post on answering the missed deadline question covers it.
An Android 16 deadline landed on a full sprint
Here is the story used for the rest of this post. You’re a mid-level Android engineer on a grocery delivery app. It’s July 2026. Your sprint holds two big items.
The first is raising the app’s target API level. Google Play’s target API level requirements set a date. From August 31, 2026, new apps and app updates must target Android 16 (API level 36). Otherwise Play won’t accept them. Developers can request an extension to November 1, 2026. You estimated three days.
The second is saved carts that sync across a user’s devices. Your product manager promised it for a marketing push on September 10.
The target bump turned out bigger than three days. Android’s Android 16 behavior changes page explains why. On Android 16 devices, apps targeting API level 36 can no longer opt out of edge-to-edge display. Nine of your screens had relied on that opt-out. On those screens, content slid under the system bars. Predictive back animations also turn on by default for those apps on those devices. Then onBackPressed is no longer called. Two checkout screens used it to confirm before leaving. The real estimate was about two weeks. Both items no longer fit before the end of August.
Rank by what happens if each item slips
The ranking is the part of the answer the interviewer can check. “I prioritized by impact” can’t be checked. A sentence about consequences can.
Ask the same question of each item. What happens if it slips by two weeks? For the target bump, the answer was severe. After August 31, the team couldn’t ship any update without the extension. That included crash fixes. For the sync feature, the cost was real but smaller. The September campaign would lose one selling point. The app would still work.
The extension only moved the date. The two weeks of work stayed the same size. They would have landed in October, inside the team’s holiday code freeze.
Say the ranking in that form in the interview. One item blocks every release. The other weakens one campaign. An interviewer can follow that in one hearing.
Say who made the call, because it may not have been you
Many engineers tell this story as if they ranked the work alone. Often they didn’t. The interviewer knows that. GitLab’s handbook page on directly responsible individuals gives a typical split. For a new feature, the product manager owns prioritization. The engineering manager owns delivery.
Claiming the whole decision can backfire. A follow-up like “how did your PM feel about that?” exposes it quickly. The stronger version is honest about roles. You found the collision. You measured both costs. You brought options to the person who owned the ranking. Then you carried out what they chose.
Bring at least two options. In the story there were three. The team could request the extension and build the feature first. It could finish the target bump and slip the whole feature. Or it could ship a smaller feature on time. With only one option, the owner can just approve or refuse it.
In the story, the product manager picked the third option. Saved carts shipped on September 10, stored on one device only. Cross-device sync followed two weeks later. Sync was the item you dropped from the September 10 release. Marketing paid for it by removing the “on any device” line from the campaign. If the owner had overruled your ranking, the story changes shape. The influence without authority post covers that turn.
A sample answer built from that sprint
In July, our sprint had two big items. One was raising our target API level to 36. Google Play requires that for app updates from August 31. The other was saved carts that sync across devices. Our PM had promised it for a September 10 campaign.
I estimated the target bump at three days. Once I made the change, nine screens broke. Android 16 removes the edge-to-edge opt-out for apps at that level. Two checkout screens also relied on
onBackPressed. That stops being called. The real estimate was two weeks. Both items couldn’t fit.I compared what a two-week slip would do to each. If the target bump slipped, we couldn’t ship any update after August 31, not even a crash fix. An extension would only push the same work into our October freeze. If sync slipped, the campaign lost one feature.
The ranking was my PM’s call, so I took them three options the same day. Ask for the extension, slip the whole feature, or ship saved carts on one device first. They chose the third. I finished the target bump by August 22. Saved carts went out on September 10. Sync followed two weeks later.
That had a cost. Marketing rewrote the campaign to drop the “any device” claim. I helped by writing the release note that explained when sync would arrive. I also now test the next target level in the spring, before any estimate goes into a sprint.
The engineer, the app and the sprint in this answer are invented for this post. The Play deadline and the Android 16 changes are real. Build yours from a collision you lived through, with true details.
The answer’s last sentence shows the estimate miss changed how you plan. Testing the next target level in spring makes the same collision less likely next year.
When they ask why you didn’t just take the extension
A sharp interviewer will press on the easy exit. Google offered more time, so why make anyone lose anything? Have a short answer ready. “The extension would only have moved the deadline. The same two weeks of screen fixes would have hit our holiday freeze. We’d have had less time to test them.”
Then add the condition where your answer would change. Suppose the team had no freeze and nothing else planned for October. Then requesting the extension and shipping the full feature first could have been the better call. Saying that shows you ranked the items on facts from that quarter. If the interviewer then asks what you’d do with no freeze, give that order plainly. Request the extension and ship the full feature on September 10. Then do the screen fixes in early October with a full test pass.