To answer "tell me about a time you delegated a task," describe a specific piece of work you handed to someone else, explain why you chose that task and that person, and show how you followed up without taking it back or hovering. End with the result for the work and for the person who took it on. Interviewers use this question to see whether you can multiply your impact through other people while still owning the outcome.
This page covers the single delegation question in depth. For a broader bank of manager questions, see our manager interview questions guide, and for the full set of behavioral prompts, our list of "tell me about a time" interview questions.
What is the interviewer really testing with a delegation question?
Many new leads struggle with delegation in one of two ways: they keep everything because it is faster to do it themselves, or they hand work off and disappear. The question checks that you avoid both.
| Signal | A strong answer shows | What weakens it |
|---|---|---|
| Judgment | A clear reason for choosing this task and this person | "I was busy, so I gave it to whoever was free" |
| Clarity | You defined the outcome, the deadline and the decisions they could make alone | Vague instructions, followed by surprise at the result |
| Trust | Agreed check-ins, then you let them work | Daily status pings, or quietly redoing their work |
| Ownership | You stayed accountable for the outcome | Blaming the person if it went wrong |
| Growth | The person built a skill or earned visibility | Delegation used only to offload boring work |
How do you choose what to delegate, and to whom?
A good story makes your reasoning visible. Interviewers want to hear that you matched the task to the person's skill and growth goals, not just to their free time. A simple way to think about it:
| Type of task | Who it suits | How closely to follow up |
|---|---|---|
| Routine work you do well but no longer need to own | Someone who can learn it quickly | Walk through it once, then a light check after the first run |
| A stretch task tied to someone's growth goal | A person who has said they want this experience | A short weekly check-in and an early review of the first draft |
| Work where someone else has more expertise | The specialist | Agree on the outcome and deadline, then step back |
| High-risk or irreversible decisions | Usually stays with you, or is shared with clear sign-off points | Agreed checkpoints before anything irreversible |
When you hand over the task, be explicit about three things: what done looks like, the deadline, and which decisions they can make without you. That last point is what lets you follow up without micromanaging.
A short answer frame
- Situation: the workload or project, and why you could not or should not do this task yourself.
- Task: what you needed to hand off and what success looked like.
- Action: why you chose this person, how you briefed them, the check-ins you agreed and one moment where you resisted stepping in.
- Result: the outcome for the work, what the person gained, and what you were then free to do.
Our STAR method guide explains each step in more detail.
Three example answers we wrote
These are example answers we wrote to illustrate the structure. Names, details and numbers are invented. Use your own story.
Example answer we wrote: a first-time team lead
Situation. I had just become tech lead for a team of four engineers. I was still running every release myself, which took about a day every two weeks and was keeping me out of planning work my manager needed from me.
Task. I needed to hand off release coordination without causing a bad release.
Action. I chose Sam, a mid-level engineer who had told me he wanted more ownership beyond writing code. I wrote down the release checklist I had been keeping in my head, ran the next release with him watching, then had him run the following one while I watched. After that, we agreed he would make the go or no-go call himself and only bring me in if a rollback was needed. On his first solo release, he made a sequencing choice I would not have made. It worked, so I said nothing except "nice job."
Result. Sam ran the next six releases with no rollbacks and improved the checklist, cutting release time from a day to about half a day. I moved that time into quarterly planning, and our roadmap was approved on the first review. My lesson: write the checklist before you hand it over.
Example answer we wrote: a manager delegating a vendor evaluation
Situation. As an operations manager with a team of seven, I was asked to evaluate three scheduling software vendors within six weeks, during our busiest season.
Task. I had to deliver a recommendation to my director, but I did not have the hours to run the evaluation myself.
Action. I delegated it to Nina, a coordinator who used the current scheduling tool more than anyone and had mentioned wanting project experience. I gave her the budget limit, the five requirements the director cared about and the deadline, and told her she could run vendor demos and talk to references without checking with me. We met for 20 minutes every Monday. When one vendor pushed for a decision early, she asked me how to respond, and I helped her draft a reply rather than taking over the conversation.
Result. Nina delivered a recommendation a week early, and she presented it to the director herself. The tool we chose cut scheduling time for the team by about four hours a week. Nina was promoted to team lead the following year, and the director cited the evaluation as an example of her work.
Example answer we wrote: an individual contributor leading a project
Situation. As a senior engineer, I led a project to move twelve internal services off a deprecated logging library. I had no direct reports, but three engineers from two teams were assigned part time.
Task. I needed to split the work so it finished within the quarter, without becoming the bottleneck for every decision.
Action. I migrated the first service myself and wrote a short guide from it. Then I divided the remaining eleven services by team ownership, so each engineer migrated services their own team knew. I set one rule: anything that changed log formats needed my review, and everything else they could merge on their own. We used a shared tracker instead of status meetings, and I only reached out if a service stalled for more than a week.
Result. All twelve services were migrated two weeks before the end of the quarter, with one minor incident that the owning engineer fixed within an hour. Two of the engineers later led similar migrations themselves using the guide.
Weak vs strong answers
| Weak | Strong |
|---|---|
| "I delegate all the time." | One task, one person, a clear reason |
| You gave them the task and checked back at the deadline | Agreed check-ins and decision rights from the start |
| You redid their work at the end | You gave feedback early and let them fix it |
| Only the project result | The project result plus what the person gained |
| Blame if it went wrong | You took responsibility for the outcome |
What follow-up questions should you expect?
- "What would you have done if they'd missed the deadline?" Explain the early warning signs you watched and when you would step in.
- "What do you never delegate?" A fair answer: decisions about people, such as hiring and performance, and anything where you alone hold key context.
- "Tell me about a time delegation went wrong." Prepare a second story where the brief was unclear, and say what you changed.
- "How do you avoid micromanaging?" Point to decision rights and agreed check-ins rather than general trust.
- "How did you pick that person?" Name their skills and their growth goals.
Mistakes to avoid
- Delegating only chores. A story about handing off tasks you dislike suggests you see delegation as offloading.
- Skipping the "why this person" part. It is where most of your judgment shows.
- Taking the task back. If you stepped in, explain why it was necessary and what you did afterward to rebuild their confidence.
- Confusing delegation with mentoring. If your story is mostly about teaching a skill over weeks, tell it as a time you mentored someone.
- No result for the person. Say what they learned, earned or went on to do.
Delegation stories often overlap with leadership. If yours involved setting direction for a whole group, also see the leadership question, and for engineering roles, our engineering manager interview questions.
Practice it
The "why this person" and "how I followed up" parts are where delegation answers usually get vague. Say yours out loud and listen for them. To rehearse it, run a browser-based mock interview with nothing to install, or use the desktop app's Mock Interview, which builds questions from your résumé and the job description and scores each spoken answer out of 10 with what to fix. It is free for 15 minutes a day, with no account. Follow each employer's rules on AI tools, and use AI to prepare beforehand.
Practice your delegation story out loud
Answer manager and leadership questions, get scored feedback on each answer, and repeat until the reasoning is clear.
Try a free AI mock interviewFAQ
What if I have never managed anyone?
Use a project you led, a group assignment or a time you split work with peers. Delegation is about handing off work with clear outcomes, which individual contributors do too.
What is the best kind of task to talk about?
A task that mattered and that helped the other person grow. Routine work is fine if you explain why handing it off freed you for something more important.
How do I show I didn't micromanage?
Describe the decision rights you gave them, the check-in schedule you agreed and a moment where you let their approach stand even though you would have done it differently.
Should I mention a delegation that failed?
Lead with a success, but keep a story where delegation went wrong as a backup in case the interviewer asks. Focus on what you changed afterward.
How long should the answer be?
About two minutes, with most of the time on why you chose the person and how you followed up.