Behavioral loops almost always include some version of “tell me about a time you led a project,” and it is one of the questions where seniority is least correlated with answer quality. Senior managers fumble it by defaulting to org-chart language; ICs duck it because they assume leadership means direct reports. Both miss what the interviewer is scoring. This guide covers how to answer tell me about a time you led a project using STAR, with 15 worked examples across ICs, tech leads, PMs, designers, and marketing leads — plus a short list of moves that will sink the answer at any seniority.
Why interviewers ask this
The fastest mistake is to assume the question only applies if you have managed people. It does not. Hiring panels at every level — IC2, senior IC, staff, manager, director — use it to test the same skill: can you take an outcome that requires more than your own hands, scope it, get other people moving in roughly the same direction, and land it. Wonsulting puts it bluntly: leadership is an action, not a position — wait for the title and you may never get it.
This matters because most jobs above a certain band require some flavor of “leadership without authority” — convincing a partner team to deprioritize, pushing back on a stakeholder who outranks you, rallying peers around a decision you cannot enforce. The interviewer is checking whether you have done that even once, and whether you can narrate it without inflating your role or hiding the messy parts. They score three things: influence (did people follow you, and why), judgment (did you make the right calls when it got ambiguous), and outcome (did the project land, can you prove it). Miss one and the story becomes noise.
The STAR framework
STAR — situation, task, action, result — works here because it forces you to spend airtime on the parts that prove leadership rather than the parts that prove the project existed. Most candidates over-invest in situation (“the company was in a re-org, the team was new, infra was creaky…”) and run out of time before action. The right ratio tilts hard toward action: roughly 15% situation, 10% task, 55% action, 20% result.
Situation (two sentences). Team size, stakes, the constraint. Skip the org chart.
Task (one sentence). What you specifically were on the hook for — not the team. If you cannot say “I owned the outcome of X,” the example is too diffuse and the interviewer will read you as a participant, not a lead.
Action (four to six sentences). This is where project leadership STAR answers either work or do not. You need three beats: a judgment call (what you said yes to, what you said no to, why), at least one moment of influencing someone you did not manage (peer, partner team, skeptical stakeholder), and the operating cadence you ran (kickoff, midpoint check, closeout). Lara Hogan’s Resilient Management frames team leadership around setting clear expectations and iterating on them at predictable checkpoints — even on a four-week IC-led project, naming those checkpoints signals that you ran the work rather than reacted to it.
Result (two sentences). A measurable outcome — shipped on date X, lifted metric Y by Z%, cut cycle time A to B — and one line on what changed in how you work because of it. The metric is the part the panel quotes back to each other in debrief. Without one, the story slides off.
15 sample answers
Each answer below is roughly 70 spoken words — 60–90 seconds out loud. Notice how IC-led examples land just as cleanly as manager-led ones: what carries the story is the judgment call and the metric, not the title.
Backend engineer, IC-led migration. “Our payments service was on a deprecated library and three teams had said no to owning the migration. I wrote a two-page plan, got buy-in from the two senior engineers whose code I was touching, and ran weekly 20-minute syncs to unblock anyone mid-feature. We cut over in seven weeks with zero incidents, and the runbook became the template for the next migration.”
Frontend tech lead, design system rollout. “I was tech lead on a design system rollout across four product teams. The hard part was not the components — it was getting four teams to adopt them on different cadences. I ran a kickoff with each EM, set a 90-day adoption target, and kept a public dashboard. We hit 86% by day 90 and the two laggards had a written exception, not silence.”
PM, cross-team launch. “I led a new pricing page launch that required eng, design, legal, and finance to agree on a single source of truth for plan limits. I ran a one-hour kickoff to align on what we were not changing, a midpoint review at week three, and a closeout retro at week six. We shipped on date and trial-to-paid improved 14%.”
Designer, accessibility initiative. “Nobody owned accessibility, so I wrote a one-pager and got the head of design to sponsor it. I ran an audit, prioritized the top 12 violations, and paired with one engineer per squad to fix them. We went from 41 WCAG AA failures to 6 in a quarter, and the audit template is now part of our design review.”
Data scientist, model rebuild. “Our recommendation model had not been retrained in 18 months and nobody felt safe touching it. I scoped a four-week rebuild, walked the plan past two senior ICs, and shipped behind a flag with a holdout. CTR improved 9% and we now retrain quarterly with a documented runbook.”
Marketing lead, campaign relaunch. “I led the relaunch of our lifecycle email program after open rates dropped two quarters in a row. I rebuilt segmentation, partnered with one writer and one designer on a six-week sprint, and set a kill criterion up front — if opens did not move 15%, we scrap it. They moved 22%.”
Engineering manager, infra project. “I owned a cross-team effort to consolidate three logging pipelines into one. The risk was political, not technical. I spent the first week in 1:1s with each owning EM, wrote the migration plan with their edits visible, and ran biweekly steering syncs. We retired two pipelines in five months and cut logging spend 38%.”
Junior engineer, on-call fix. “I was the most junior on the team, but the on-call rotation was burning people out. I volunteered to lead the fix, audited 90 days of pages, and proposed killing the four loudest alerts — I ran it past the senior engineer who wrote them so it did not feel like a takedown. Pager volume dropped 60% and people stopped trading the rotation away.”
Product designer, research-led redesign. “I led an onboarding redesign that started from research, not from a brief. I scoped six user interviews, brought the PM and lead engineer into two of them so the findings did not read as a designer’s opinion, and shipped an A/B in week eight. Activation went from 31% to 44%.”
QA lead, test pyramid overhaul. “Our integration suite took 47 minutes and people were skipping it. I led a four-week effort to rewrite the bottom of the pyramid, paired with one engineer per service area, and kept the work visible in a shared doc. Suite time dropped to 9 minutes and CI flake fell from 12% to under 2%.”
Career switcher, first project. “I had been at the company six weeks when our quarterly content audit lost its owner. I asked to take it, scoped it to three deliverables instead of the usual seven, and ran a weekly 15-minute check-in with my manager. We shipped on time, two of three recommendations were adopted, and I had a real artifact for my next review.”
Staff engineer, architecture decision. “I led the decision to move our core service from REST to gRPC; two senior peers disagreed. I wrote an RFC, hosted two open review sessions, and folded the strongest objections directly into the doc. The decision shipped, and one of the peers who pushed back hardest later ran the migration for the second service.”
PM, sunsetting a feature. “I led the sunset of a feature 4% of users still loved. The hard part was comms, not code. I scoped a 90-day deprecation, drafted the user email myself, and ran it past CX and legal before sending. We sunset on schedule with under 0.3% support volume bump, and the playbook is now reused.”
Marketing, product launch. “I led GTM for a new tier with three weeks of runway and no dedicated PMM. I scoped the launch to one landing page, one email, and one Product Hunt push instead of the full plan, got founder sign-off on the cut scope, and shipped. We hit 1,400 signups in the first week and the retro became our launch template.”
Engineering manager, team formation. “I was asked to spin up a new platform team from scratch. I spent two weeks writing the charter with input from the three dependent teams, ran a kickoff where every dependent EM read it aloud, and set quarterly OKRs mapped to their roadmaps. Six months in, all three renewed support — the actual test.”
What NOT to say
A handful of moves will sink the answer regardless of how good the underlying work was. If you hear yourself doing any of these, restructure.
- “My manager assigned me to lead it.” Frames you as a passenger. Lead with the judgment call you made inside the project — what you scoped down, who you brought in, what you cut.
- No kickoff, midpoint, or closeout. Without structure beats, the interviewer assumes the project had no structure. Name them: “I ran a one-hour kickoff, a midpoint review at week three, a closeout retro at the end.”
- No metric. “It went well” is not a result. If you cannot quantify the outcome, name a behavior change — a runbook reused, a template adopted, a cadence kept.
- Sole-hero framing. “I did everything because nobody else could” reads as either inflation or a leadership failure — you did not multiply your impact through others.
- Dodging the conflict. Every real project has a moment where someone disagreed. If your story has no friction, the interviewer assumes you are sanitizing it.
- The future tense. “I would have…” or “the plan was to…” — stories that did not actually ship do not count.
Closing move and practice routine
The strongest closer is not the result line — it is the sentence after it, where you say what changed in how you work because of the project. “I now write a one-page charter before I take on anything cross-team.” “I now insist on a kill criterion before campaign launches.” “I do not start a migration without a written runbook.” That sentence does two things: it shows the project was a real learning moment, not a war story, and it gives the panel a vivid line to quote in debrief. Will Larson’s framing in Staff Engineer — that leadership at the senior IC level is “multiplying your impact by influencing decisions” — is the same idea. The artifact, cadence, or template you now reuse is the multiplier.
For practice, pick three projects from the last two years and write each as a 70-word STAR. Read them aloud and time yourself — over 90 seconds is too long, under 45 is missing the action paragraph. Then have a peer ask you cold and listen for three things: did you say “I owned X” in the first 15 seconds, did you name a judgment call, did you land on a metric. If two of three are missing, rewrite. If you want a second pair of eyes on the project bullets these stories map to, drop your resume into the free CV review.