“Describe a situation where you had to juggle multiple projects at once.” “Tell me about a time you had competing priorities.” “What do you do when two people both need something from you by Friday?” “How do you prioritize your work?” Every engineer past their first year has more work than time, so this family comes up in almost every loop, and at every level.
It sounds like a question about being organised. It is really a question about judgement under load: when everything cannot be done at once, how do you decide what comes first, and who do you tell? This post covers what the interviewer is scoring, a real answer from leading the backend of two projects at the same time, and the gap that almost every answer to this question has.
What the interviewer is scoring
Four things, and only one of them is about hard work:
- You have a way of deciding. Not “I work on whatever is most urgent” but a reason one task beats another: the deadline, the business impact, and whether other people are blocked waiting on it.
- You make trade-offs visible. When two things cannot both happen on time, the people who own those priorities hear about it from you, early, with options. Silently choosing for them, or silently letting one slip, is the answer that worries interviewers most.
- You use the team. Delegation by strength and workload, not doing everything yourself, especially if you were leading.
- Quality holds. Hitting both dates by cutting corners on one is not juggling; it is dropping something quietly.
Notice what is missing from that list: working longer hours. Extra effort can be part of a good answer, but an answer whose only tool is “I worked nights” tells the interviewer you have no tool for the next time, when there are not enough nights.
The worked answer
Here is a real answer from my time at Datapraise, where two client projects landed at once:
Situation. At Datapraise, we took on two high-profile client projects at the same time. Both mattered to the company's portfolio, and their timelines overlapped.
Task. I led the backend development for both. That meant hitting every milestone on both projects, coordinating with different teams, and not letting the quality of the work slip on either.
Action. First I went through the requirements and deadlines of both projects so I could prioritize across them: urgent, high-impact work was identified and done first. I blocked out my days by project, with specific time for each, to keep context switching down. I delegated to the team based on each person's expertise and current workload, so the load was spread evenly. And I kept the project managers and both teams in constant contact, with regular check-ins to catch roadblocks early and adjust the plan when something changed.
Result. Both projects were delivered on time. The clients were very happy with the work, which led to positive testimonials and repeat business for the company.
Learning. Running two projects at once is not really about multitasking. It is about planning ahead and keeping everyone informed, so that problems come up while there is still time to move things.
Spoken at a normal pace, that is a little over a minute.
Why it works
The scope is clear. “I led the backend development for both” tells the interviewer exactly what was yours. It is also a leadership answer hiding inside a prioritization answer: delegating and running check-ins across two teams is leading, so this story can do double duty for the leadership questions.
The method covers all four things being scored. A way of deciding (deadline and impact), visibility (constant contact with both project managers), using the team (delegation by expertise and workload), and quality (named as part of the task, not an afterthought).
Time blocks are a real technique. Interviewers who have tried to do deep work across two projects know that context switching is where the time goes. Blocking days by project shows you understood the actual cost, not just the calendar.
The result is the business's, not yours. Testimonials and repeat business are an outcome the company cared about. It is a stronger close than “and I learned to multitask”.
What would make it stronger
Read the action again and count the decisions. There are none, only good habits: prioritizing, communicating, scheduling, delegating, reviewing. That is how almost every answer to this question sounds, which is exactly why it does not stand out. Any candidate can list those five, and interviewers know it. The follow-up that separates candidates is predictable:
“Give me one specific time both projects needed you at the same moment. What did you do?”
The strongest version of this answer replaces some of the list with one collision, told in detail: the week both projects hit a deadline, or an urgent bug in one landed in the middle of a release in the other. What did you weigh, what did you pick, what did you delay, and who did you tell? One real decision like that is worth more than the five habits together, because it shows the habits working instead of naming them.
Three smaller additions would help:
- What the projects were. One line each is enough for the stakes to land: “a payments integration for a retail client and a new mobile API” is far easier to picture than “two high-profile projects”.
- Size. How many people you were delegating to, and how long the overlap lasted.
- What you said no to. If everything got done, something was still pushed later or done in a smaller form. Naming it proves the prioritizing was real.
As always, fill these from what actually happened. If you do not remember the details of the collision, a vaguer true answer beats a vivid invented one.
The follow-ups to prepare
- “What did you deprioritize?” — Have a specific answer. If the honest answer is “nothing”, the next question will be how.
- “What happened when the two project managers disagreed?” — Who decided? A good answer shows you took it to the person who owned the trade-off, with options, rather than choosing between two managers yourself.
- “How did you decide who got which task?” — Expertise and workload, with one example of a hand-off.
- “Did quality suffer anywhere?” — Be honest. A small, known shortcut that was cleaned up afterwards is a better answer than claiming nothing gave.
- “What would you do differently?” — Often: raise the overlap earlier, or ask for help sooner.
When it is asked as “how do you prioritize?”
The same family sometimes arrives as a general question rather than a request for a story. Do not answer it with a framework alone. Give your rule in one sentence — “what blocks other people first, then what has the nearest deadline and the biggest impact, and anything that cannot fit gets raised with whoever owns the priority” — and then prove it with the story: “for example, when I led the backend of two overlapping projects…”. A rule followed by evidence beats either on its own.
A skeleton for your own
THE LOAD what you were juggling, one line each, and for how long
YOUR ROLE what was yours across them
HOW YOU DECIDED deadline, impact, who is blocked waiting on it
THE COLLISION ONE moment both needed you: what you weighed and chose
WHO YOU TOLD the people who owned the priorities, and when
WHAT YOU HANDED delegation: to whom, and why them
WHAT YOU DROPPED what was delayed or cut, on purpose
RESULT both outcomes, with numbers if you have them
LEARNING one sentence you would apply next timeIf you only fill in one line, make it the collision. It turns a list of habits into a story, and it is where the interviewer will take you anyway.
What to take from this
- The question is about judgement under load, not hours worked.
- Show a way of deciding: deadline, impact, and who is blocked.
- Make trade-offs visible to the people who own the priorities, early.
- Use the team; delegating by expertise and workload is part of the answer.
- Replace part of the list of habits with one real collision, told in detail.