Free lesson · Behavioral Interview
"How Do You Manage Multiple Tasks with Competing Deadlines?"
Why Interviewers Ask This
Every engineer at a FAANG company will face a week - usually many weeks - where three things need to happen and there is only time for two. The interviewer is not testing whether you can work hard enough to finish everything. They are testing whether you can think clearly about what matters most, communicate trade-offs to the people who care, and execute in priority order without drowning.
This question evaluates prioritization judgment and stakeholder communication. The two are inseparable. An engineer who prioritizes well but does not communicate the trade-offs creates surprises. An engineer who communicates well but cannot prioritize creates churn. The interviewer wants both - someone who can look at a full plate, decide what gets eaten first, and tell the chef what is getting cold.
At Amazon, this maps to "Bias for Action" and "Deliver Results." At Google, it is embedded in the performance rubric for every engineer above L4 - the ability to manage ambiguity and competing priorities without waiting for a manager to sort it out. At Meta, "Move Fast" explicitly requires knowing what to move fast on and what to defer. At Microsoft, the growth mindset framework includes the ability to prioritize learning and impact simultaneously. At Apple, shipping excellence requires ruthless prioritization - the company is famous for cutting features to ship on time.
The trap most candidates fall into: they tell a story about working harder. "I stayed late and finished everything." That is not prioritization. That is endurance. The interviewer is looking for evidence that you made deliberate trade-off decisions - that you chose to do one thing and not another, that you communicated that choice, and that the outcome justified the decision. If your story does not include a moment where you said "this will have to wait," you have not demonstrated prioritization.
There is a second, subtler trap: answering with a framework but no story. "I use the Eisenhower matrix to categorize tasks by urgency and importance." That is a textbook answer, not a behavioral answer. The interviewer asked about a time you managed competing deadlines - they want a specific situation, specific decisions, and specific outcomes. The framework is useful as scaffolding for the story, not as a substitute for it.
The Framework for Prioritization Answers
The strongest answers follow a five-part structure that demonstrates both judgment and communication.
Part 1: List the competing demands. Start by establishing the situation clearly. How many things were competing for your time? What were they? Who was asking for each one? What were the deadlines? The interviewer needs to understand the complexity before they can evaluate your response to it. Be specific - "three projects with overlapping deadlines" is better than "I was really busy." Name the projects, name the stakeholders, name the timeline.
Part 2: Assess impact and urgency. This is where you show judgment. How did you decide what mattered most? Impact and urgency are two different axes. A high-impact, low-urgency task might be more important than a low-impact, high-urgency task - but not always. The judgment is in the assessment. Did you consider what would happen if each task was delayed? Did you consider which stakeholders had the most flexibility? Did you consider whether some tasks could be partially completed now and finished later? Walk the interviewer through your thinking.
Part 3: Communicate trade-offs to stakeholders. This is the part most candidates skip, and it is the part that separates competent engineers from excellent ones. When you decide that Task C will be delayed to prioritize Tasks A and B, did you tell the person waiting for Task C? Did you tell them before the deadline, not after? Did you explain why and offer an alternative timeline? Proactive communication about delays is a senior engineering skill. Silent delay followed by a missed deadline is a career-damaging pattern.
Part 4: Execute in priority order. Describe how you actually did the work once the priorities were set. This section should be brief - the story is about the decision, not the execution. But mentioning how you organized your time (time-blocking, heads-down sprints, delegation if applicable) adds credibility.
Part 5: Re-assess as conditions change. Priorities are not static. The best answers include a moment where conditions changed - a new requirement arrived, a dependency shifted, a stakeholder's timeline moved - and you re-evaluated your priority stack. This demonstrates that prioritization is not a one-time act but an ongoing discipline.
Translating EM-Level Prioritization to IC-Level Answers
The principles of prioritization are identical at every level. What changes is the scope.
An engineering manager prioritizes across team members, projects, and organizational goals. They negotiate timelines with directors and product managers. They decide which engineer works on which project.
An individual contributor prioritizes across their own tasks, feature requests, bug fixes, and technical debt. They negotiate timelines with their tech lead or manager. They decide which pull request to review first and which Slack message can wait.
The framework is the same: assess impact, assess urgency, communicate trade-offs, execute, re-assess. The difference is that an IC's stakeholders are typically their manager, their tech lead, and the engineers blocked on their work - while an EM's stakeholders might include directors, product managers, and partner teams.
If you are an IC preparing for this question, do not worry that your scope feels smaller than a manager's. The interviewer is not comparing you to a manager. They are evaluating whether you think about priorities deliberately and communicate about them proactively. Those skills matter at every level.
Swati Models Her Answer
Swati Bajpai, Engineering Manager at Google, Search Infrastructure
I want to share a specific situation from about eight months ago that I think shows how prioritization actually works in practice - because it is messier than any framework makes it sound.
I was managing three concurrent workstreams across my team of fourteen engineers. The first was a latency optimization for the indexing pipeline that our VP had flagged as critical for the quarterly business review - the target was a 15% reduction in P95 latency by end of quarter. The second was an on-call reliability improvement that the SRE team was pushing for - our pages-per-week had been trending up, and they wanted us to invest in reducing alert noise. The third was a new feature integration with a partner team that had a hard launch date tied to a product announcement.
All three had roughly the same deadline window - the last three weeks of the quarter. And I had enough engineering capacity for about two and a half of them.
The first thing I did was not open my calendar or assign tasks. The first thing I did was map each workstream to its actual consequences. Not its stated urgency - its actual consequences if delayed.
The latency optimization: if we missed the QBR target, the VP would be disappointed but the sky would not fall. The optimization could ship the following quarter with minimal business impact. It was high-visibility but low-consequence for a one-quarter delay.
The on-call reliability improvement: if we delayed this, engineers would continue to burn out on noisy alerts. The cumulative cost was real but not tied to a specific deadline. However, one of my senior engineers had explicitly told me she was considering leaving the team because of on-call fatigue. That made this a retention risk, which changed the priority calculus.
The partner team integration: the hard launch date was real. Marketing materials were already in production. Delaying our integration would delay the entire product launch and damage the relationship with a partner team we would need to work with for the next two years.
Based on that assessment, my priority order was: partner integration first (hard deadline, external dependency, relationship consequences), on-call reliability second (retention risk, cumulative team health), latency optimization third (deferrable without significant business impact).
Here is the part I want to emphasize: the next thing I did was not start executing. The next thing I did was communicate.
I scheduled thirty minutes with my VP that afternoon. I walked her through the three competing priorities, my assessment of consequences, and my recommendation to defer the latency optimization to the following quarter. I did not ask for permission - I presented a recommendation with reasoning and gave her the opportunity to override it if she had information I was missing. She did have information I was missing - she told me the QBR latency number was already flagged in a slide deck that had gone to the SVP. Deferring it would require her to update the SVP. She asked if there was any version of the optimization that could ship this quarter, even if it was a smaller improvement.
That conversation changed my plan. Instead of fully deferring the latency work, I scoped it down to a targeted optimization that would deliver about 8% improvement instead of the original 15% target. That smaller scope required two engineers for one week instead of four engineers for three weeks. I reassigned the remaining capacity to the partner integration and on-call reliability workstreams.
I then sent a brief written summary to all three stakeholders - the VP, the SRE lead, and the partner team's engineering manager - with the updated plan, explicit timelines for each workstream, and what each stakeholder should expect from my team. No surprises. No one discovered at the deadline that their project was delayed. Everyone had the information they needed to adjust their own plans.
The outcome: the partner integration shipped on time. The on-call reliability improvements reduced pages-per-week by 30%, and my senior engineer decided to stay on the team. The latency optimization delivered 8% improvement that quarter and the remaining 7% the following quarter. The VP appreciated the transparency and told me she would rather have an honest 8% than a panicked 15% with quality risks.
Why Swati's Answer Works
Swati's answer demonstrates several things the interviewer is evaluating:
She separates stated urgency from actual consequences. All three stakeholders said their project was urgent. Her job was to assess the real consequences of delay for each one, which required judgment that went beyond the urgency labels.
She communicates proactively and upward. Going to the VP with a recommendation and reasoning - before the deadline, not after - is exactly the stakeholder communication skill this question evaluates. The VP had information that changed the plan, which is exactly why proactive communication matters.
She adjusts the plan based on new information. The conversation with the VP produced a new constraint (the SVP slide deck), and Swati adapted by scoping down rather than abandoning. This shows flexibility within a structured approach.
She quantifies the outcome. 8% latency improvement, 30% reduction in pages-per-week, retention of a senior engineer. These are not vague "it went well" statements - they are measurable results.
She does not mention working extra hours. At no point does Swati say "I stayed late to finish everything." The story is about making trade-offs, not avoiding them. That is the signal.
How to Adapt This for IC-Level Answers
Swati's story works because her role involves managing competing priorities across a team. If you are an IC, your version might look like this:
"I had three tasks with overlapping deadlines: a feature for the next sprint, a P1 bug that the support team escalated, and a design document my tech lead needed for an architecture review. I assessed each one: the P1 bug was affecting customers in production, so that was highest priority. The design document had a flexible deadline - I messaged my tech lead and asked if Thursday instead of Tuesday would work, and she said yes. The feature could start later in the sprint as long as it shipped by the end. I fixed the bug first, delivered the design doc by Thursday, and started the feature with enough runway to finish on time."
The structure is identical. The scope is different. The principles - assess consequences, communicate trade-offs, execute in priority order - are the same.
The Common Mistakes
Mistake 1: "I worked extra hours and finished everything." This is the single most common answer to this question, and it is the weakest. The interviewer did not ask whether you could work 70-hour weeks. They asked how you manage competing priorities. If your answer is "I never have to choose because I just work more," you have not demonstrated prioritization. You have demonstrated unsustainable habits that will eventually fail.
Mistake 2: Letting the manager decide. "I brought the conflicting deadlines to my manager and she told me what to prioritize." This is fine if you are a junior engineer in your first year. It is not fine if you are applying for a mid-level or senior role. The interviewer wants to see your judgment, not your manager's. Even if your manager was involved in the decision, your answer should focus on your assessment and recommendation, not on delegation of the decision upward.
Mistake 3: Framework without story. "I use the Eisenhower matrix. Urgent and important tasks get done first. Important but not urgent get scheduled. Urgent but not important get delegated. Neither urgent nor important get dropped." That is a Wikipedia answer. The interviewer has heard it before. They want a specific situation where you applied prioritization judgment, not a description of a generic framework. Use the framework as scaffolding for a real story, not as the answer itself.
Mistake 4: No stakeholder communication. "I prioritized Task A over Task B and finished Task A first." What happened to the person waiting for Task B? Did you tell them? Did you tell them before the deadline? If your story does not include a moment where you communicated a trade-off to a stakeholder, you have missed the most important part of the answer. Prioritization without communication creates surprises. Surprises erode trust.
Mistake 5: Treating every priority as equal. "I divided my time equally across all three projects." That is not prioritization - that is time-sharing, and it usually means everything gets done slowly and nothing gets done well. The whole point of prioritization is that some things come first. If your story does not include a moment where you chose to delay or descope something, you have not prioritized.
Mistake 6: No re-assessment. Real prioritization is not a one-time decision. It is an ongoing discipline. If your story describes setting priorities on Monday and never revisiting them, the interviewer may wonder what happens when conditions change. The strongest stories include a moment where new information arrived and you adjusted your approach.
Now Practice This
Prioritization questions are among the most common behavioral questions at FAANG companies because they directly predict on-the-job performance. Every engineer will face competing priorities. The question is whether you handle them with deliberate judgment or with brute-force effort.
Step 1: Identify a real prioritization scenario from your experience. Look for a time when you had at least two competing demands with overlapping timelines. The more specific the scenario - with named projects, named stakeholders, and real deadlines - the stronger your answer will be.
Step 2: Map your story to the five-part framework. What were the competing demands? How did you assess impact and urgency? How did you communicate the trade-offs? How did you execute? Did you re-assess when conditions changed? If any part is missing, either fill it in from memory or pick a different story.
Step 3: Make sure your story includes a trade-off. If your story ends with "I finished everything on time," push harder. What did you choose not to do? What did you delay or descope? Where did you say no? The trade-off is the evidence of prioritization. Without it, you are telling a story about hard work, not judgment.
Step 4: Make sure your story includes proactive communication. Did you tell stakeholders what would be delayed before the deadline passed? If not, that is a gap in your story. The strongest answers include a specific conversation where you communicated a trade-off to someone who cared about the outcome.
Step 5: Run it through AlgoInsight's AI Behavioral Interview portal. The evaluator is specifically calibrated to detect the "I worked extra hours" non-answer. It checks for trade-off decisions, stakeholder communication, and re-assessment. If your answer scores well on the portal, it will score well in the interview.
Interview: The Framework at a Glance:
- List the competing demands - specific projects, stakeholders, and deadlines
- Assess impact and urgency - consequences of delay, not just stated urgency
- Communicate trade-offs - tell stakeholders what will be delayed and why, before the deadline
- Execute in priority order - brief on the how, focus on the decisions
- Re-assess when conditions change - priorities are not static
The key signal: The interviewer wants to see you making trade-offs, not avoiding them. "I finished everything" is not a prioritization story.
Tip: Separate stated urgency from actual consequences. Every stakeholder will tell you their project is the most urgent. Your job is to assess the real consequences of delay for each one - business impact, customer impact, team impact, relationship impact. The assessment is the judgment. The stakeholder communication is the maturity. Together, they are what the interviewer is evaluating.
Warning: "I worked extra hours and finished everything" is the most common weak answer to this question. It tells the interviewer you avoid trade-offs by burning yourself out. That is not a strategy - it is a pattern that breaks under sustained load. The interviewer has seen engineers who "just work harder" until they cannot anymore. Show them you can make deliberate choices about where to invest your time instead.