To answer “tell me about a time you showed initiative,” describe a specific moment when you noticed a problem or opportunity nobody had assigned to you, got the right people aligned, acted on it, and produced a measurable result. Interviewers want proof that you start useful work without being told, and that you do it with judgment rather than going rogue. Keep it to about two minutes in STAR format, and make sure the story shows both the self-start and the check-in with your manager or team.
What is the interviewer really testing when they ask “tell me about a time you showed initiative”?
The question sounds simple, but it checks four things at once. A good story covers all four without you having to point them out.
- Noticing. Do you spot problems and opportunities on your own, or only work from a ticket queue?
- Self-starting. Did you move first, before anyone asked, and did you do real work rather than just raise the issue?
- Judgment and alignment. Did you check that the work was worth doing and that it would not collide with someone else's plans?
- Follow-through. Did the idea become a finished result that someone used, with a number attached?
Some companies name this trait directly. Amazon's published Leadership Principles (as of October 2026) include Ownership, which describes leaders acting on behalf of the whole company and never saying “that's not my job,” and Bias for Action, which values speed and calculated risk-taking because many decisions are reversible. If you interview there, our Amazon Leadership Principles examples show how stories map to each principle. Most other companies look for the same behavior even when they do not label it.
Initiative vs ownership vs leadership: what's the difference?
These three questions overlap, and candidates often answer one with a story built for another. Knowing the difference helps you pick the right example and keeps your story bank from repeating itself.
| Trait | What it means in a story | Typical question | Center of the story |
|---|---|---|---|
| Initiative | You started something nobody asked for | “Tell me about a time you showed initiative” | The moment you decided to act |
| Ownership | You took full responsibility for an outcome, including the unglamorous parts | “Tell me about a time you took ownership of a problem” | Seeing it through to the end, even outside your role |
| Leadership | You guided other people toward a goal | “Tell me about a time you showed leadership” | How you influenced, organized or developed others |
An initiative story can involve leading people, but the first beat must be you choosing to act unprompted. If your best story is mainly about rallying a team, save it for the leadership question and read our guide to answering “tell me about a time you showed leadership”. If it is about going far past what was required on an assigned task, it fits the above-and-beyond question better.
How should you structure an initiative answer?
Use STAR (Situation, Task, Action, Result), with one extra beat that most candidates skip: alignment. Here is a frame you can fill in:
- Situation (2–3 sentences): the context and the gap you noticed. Make clear nobody had assigned it.
- Task (1–2 sentences): what you decided to take on and why it mattered to the team or customer.
- Action (most of the answer): the first small step you took, how you checked with your manager or the owning team, and what you built, wrote or organized.
- Result (2–3 sentences): the measurable outcome, who adopted it, and what you would do the same way again.
The alignment step is what separates initiative from freelancing. A sentence such as “I wrote a one-page proposal and asked my manager whether it was worth two days of my time this sprint” tells the interviewer you can be trusted to act on your own without creating surprises. If the work touched another team's system, say how you brought that team in.
3 example answers we wrote
These are examples we wrote to show the structure, not real candidates' answers. Swap in your own facts and numbers; an invented story falls apart under follow-up questions.
Example answer we wrote: software engineer (onboarding docs)
Situation: On my last team, new engineers took about two weeks to make their first production change. Our setup guide was three years old, and every new hire spent days asking in chat how to run services locally. Nobody owned onboarding; it was just something people complained about.
Task: After helping the third new hire in two months debug the same environment issue, I decided to fix the root cause rather than keep answering the same questions.
Action: I asked my manager whether I could spend about four hours a week on it for a month, after my sprint work. She agreed and suggested I involve the platform team because they owned the build tooling. I collected every onboarding question from our chat history, grouped them into twelve recurring problems, and wrote a script that set up the local environment in one command. The platform team reviewed it and fixed two of the underlying issues on their side. I rewrote the guide around the script and asked the next new hire to follow it while I watched, without helping, so I could find the gaps.
Result: The next three new hires shipped their first change in four to five days instead of about ten. Onboarding questions in our team channel dropped to a handful a month, and the platform team adopted the script for two other teams. I learned to start with data from real complaints before building anything.
Example answer we wrote: operations analyst (missed renewals)
Situation: I was an operations analyst at a software company. While building a routine monthly report, I noticed that about 6% of annual contracts had expired without a renewal conversation, because the renewal date lived only in a spreadsheet that sales reps rarely opened.
Task: Renewals were not my area, but the lost revenue was large enough that I thought someone should look at it, and I had the data in front of me.
Action: I did not want to tell the sales team how to work, so I took the numbers to my manager first, then to the sales operations lead, with a short summary: how many contracts, what they were worth and the likely cause. She asked me to build a fix if I could do it within two weeks. I created an automated alert in our CRM that flagged contracts 90, 60 and 30 days before expiry and assigned a task to the account owner. I tested it on one region for a month and adjusted the timing after reps said 30 days was too late for larger accounts.
Result: In the following two quarters, contracts lapsing without a renewal conversation fell from about 6% to under 1%. Sales operations rolled the alert out to every region and asked me to own the monthly renewal report. What I took from it: bring the data and a small, testable fix, and let the owning team make the call.
Example answer we wrote: product manager (support ticket insight)
Situation: As a product manager on a billing product, I read a sample of support tickets every Friday. Over a month I noticed many tickets about customers being confused by prorated charges after changing plans. It was not on our roadmap, and support treated it as normal.
Task: I wanted to find out whether this was a real pattern and, if so, get a fix prioritized without derailing the quarter's committed work.
Action: I asked a support lead to tag the next two weeks of tickets so I could size the problem, and found that proration questions were one of the largest single ticket categories for billing. I wrote a one-page brief with the ticket data, three screenshots of the confusing invoice and a low-effort fix: a plain-language line on the invoice and a preview before the plan change. I took it to my engineering lead and my director, and we agreed to fit the smallest version into the next sprint as a time-boxed experiment.
Result: After launch, proration tickets fell by about 40% over the next six weeks, and support estimated it saved several hours of agent time each week. The preview pattern was later reused for two other plan changes. The habit I kept is reading support tickets every week, because the best ideas I've had came from there.
Weak vs strong initiative answers
| Element | Weak answer | Strong answer |
|---|---|---|
| Trigger | “My manager asked me to look into it” | “I noticed…” with a concrete, unassigned problem |
| Alignment | Did it in secret, or never mentions anyone else | Checked scope with the manager or owning team early |
| Action | “I raised it in a meeting” | Built, wrote, tested or organized the fix |
| Result | “It went well” | A before/after number and who adopted it |
| Tone | Implies colleagues were lazy | Explains why the gap existed without blame |
Mistakes to avoid
- Choosing a story where you went around your manager. Acting without permission on something risky reads as poor judgment, even if it worked.
- Raising an issue but not acting on it. Pointing out a problem is useful, but the question asks what you did.
- Using an assigned project. If it was your job, it is a delivery story, not an initiative story.
- Making it too small or too big. Fixing a typo is too small. A senior candidate should show initiative at team or cross-team scope.
- Running long. Keep it near two minutes; our guide on how to stop rambling in interviews has a trimming method.
Follow-up questions to expect
A strong first answer invites probing. Prepare one or two sentences for each of these:
- “Why hadn't anyone fixed this before?”
- “How did your manager react when you raised it?”
- “What did you deprioritize to make time?”
- “What would you have done if the owning team had said no?”
- “Is there anything you would do differently?”
- “Tell me about a time your initiative didn't work out.” (Have a second, smaller story ready; the guide to answering “tell me about a time you took a risk” covers how to tell one that did not land.)
Initiative stories often double as process-improvement stories. If yours changed how work gets done, you can reuse the facts for “tell me about a time you improved a process” with a different emphasis. The full list of “tell me about a time” interview questions shows which other prompts the same story can cover, and our STAR method guide explains each part in more depth.
Practice it
An initiative story is easy to write and hard to say well, because the alignment step tends to disappear when you're nervous. Draft it with the free STAR story builder, then rehearse it out loud with a free AI mock interview built from your résumé and the job description. CoPilot Interview's Mock Interview mode reads each question aloud, listens to your spoken answer and scores it out of 10 with what worked, what to fix and a model answer, so you can hear whether the “I noticed” and “I checked with” beats come through. The free plan gives you 15 minutes a day with no account. Follow each employer's rules, and use AI to prepare beforehand; the story and the numbers should always be your own.
Rehearse your initiative story out loud
Get a question built from your résumé and the job description, answer it out loud and see your score out of 10 with what to fix.
Try a free AI mock interviewFAQ
What is a good example of showing initiative at work?
A good example is one where you noticed an unassigned problem, checked with your manager or the owning team, built or organized a fix yourself, and produced a measurable result, such as faster onboarding, fewer support tickets or recovered revenue.
How is initiative different from leadership in an interview answer?
Initiative centers on the moment you chose to act without being asked. Leadership centers on how you guided other people. One story can show both, but for the initiative question, lead with the self-start.
Can I use an example from school or volunteering?
Yes, if you are early in your career or changing fields. The same structure applies: an unassigned gap, a check-in with whoever was responsible, action you took and a measurable result.
What if my initiative was not approved or did not work?
You can use it if you explain what you learned and how you adjusted. Many interviewers value a story where you proposed something, accepted a no gracefully and found a smaller version that worked.
How long should my answer be?
Aim for about two minutes, then let the interviewer ask follow-ups. Spend most of the time on your actions and the result rather than the background.
Should I mention that I asked permission? Does that weaken the story?
Mention it. Checking alignment shows judgment, which is part of what the question tests. The initiative is that you spotted the problem and proposed the fix, not that you acted in secret.