Why This Competency Matters

When interviewers ask 'tell me about a time you went above and beyond' or 'describe a time you took initiative', they are not testing whether you work hard. They are probing four signals:

[ Agency ]            Did you act on a problem before being asked?
[ Judgement ]         Did you pick something worth the time you spent on it?
[ Execution ]         Did you actually finish, or just propose?
[ Self-awareness ]    Did you know when to stop, or did this become overreach?

This matters at every level but the bar shifts. At L3 and L4, initiative is mostly within your team and your own work. At L5, it crosses team boundaries. At staff and above, it shows up as multi-quarter bets the org would not have made without you. The same story shape (you spotted something, you acted, you owned the outcome) shows up at every band; what changes is the surface area and the stakes.

Candidates underperform on this competency for one of two reasons. The first is they tell stories where they were asked to do something, and frame it as initiative. The second is they have plenty of real initiative stories but undersell them by saying 'it was just my job', which the interviewer reads as a low ownership ceiling. Both fail the same rubric. This lesson fixes both.

What Counts as Real Initiative (vs 'Doing My Job')

The simplest test: was someone going to do this work if you did not?

[ Doing my job ]    Work assigned to you, on your roadmap, with a deadline
[ Initiative ]      Work you spotted, sized, and started without being asked

The boundary is fuzzier than candidates think. Initiative does not require the work to be wholly outside your team's remit; most strong initiative stories are within the candidate's broad area of ownership but specifically were not on anyone's plan for that quarter. The rubric does not require novelty, it requires agency.

A few concrete tests that distinguish real initiative:

• Counterfactual. If you had not raised this, would it have happened anyway in the next two quarters? If yes, soften the framing; if no, this is real initiative.
• Resistance. Did you have to convince anyone to let you do this? Initiative that runs into mild scepticism (and survives it) scores higher than initiative nobody had any reason to oppose.
• Sustained ownership. Did you carry it past the proposal stage? Spotting a problem and pointing at it is not initiative; spotting it and shipping the fix is.

If the answer to any of those three is no, the story might still be a fine 'good worker' answer but it is not the initiative story you want for this prompt.

What Great Looks Like (Rubric)

Strong initiative answers tend to score on five named signals. Hit four out of five and you are clearly above bar.

1. The problem you noticed was non-obvious.

If the problem was visible to everyone, the credit for noticing it is small. Stronger stories explain how the candidate spotted something the rest of the team had missed: a pattern across incidents, a number that did not match the published one, a recurring complaint in customer support tickets, a gap between two team boundaries. The 'how I noticed' beat is often the difference between a strong and a great story.

2. You sized the problem before sizing the solution.

Great initiative starts with quantifying the cost of the status quo. Without that, you cannot defend the time you spent. Strong stories almost always include a beat like 'I pulled three months of incident data and the cost was about $200K in support time'.

3. You scoped the smallest version that would prove the case.

The most common failure mode of initiative is overscoping. A six-month rewrite that nobody asked for is not initiative; it is a personal project. Strong stories show the candidate scoped down to the smallest piece that would prove value, shipped that, and then earned the right to do more.

4. You shipped, not just proposed.

The rubric reads 'I wrote a doc that proposed X' as a half-credit answer. The full-credit answer is 'I wrote the doc, got buy-in, shipped the change, and measured the result'. If you only got as far as the proposal, name that honestly and explain why; do not pretend the proposal was the outcome.

5. You stopped when stopping was the right call.

The sneaky failure mode of initiative is not knowing when to back off. A story that ends with 'and I am still pushing on it two years later despite everyone telling me it is not a priority' reads as poor judgement, not persistence. Strong stories include either a successful end-state or a clean 'I stopped when the cost of continuing exceeded the value' moment.

The Four-Quadrant Taxonomy of Initiative

Most candidates have far more initiative stories than they realise. The reason: they only count the dramatic ones. The taxonomy below is a 2x2 of the surface area where initiative shows up. You should have at least one story per quadrant in your bank.

Within your work          Outside your work
             +------------------------+------------------------+
For your     | A: Improve how you do  | B: Take on adjacent    |
team         |    your own work       |    work nobody owns    |
             |    (process, tooling)  |    (gaps, glue)        |
             +------------------------+------------------------+
For your     | C: Improve the team's  | D: Improve the company |
team's reach |    practices           |    or culture          |
and the org  |    (rituals, standards)|    (cross-team, infra) |
             +------------------------+------------------------+

Quadrant A: 'I noticed our PR review queue was a bottleneck and built a small tool that surfaced stale PRs in the team channel.' Within your work, for your team.

Quadrant B: 'I noticed nobody owned the on-call runbook for the auth service and spent two days writing one.' Outside your assigned work, but still serving your team.

Quadrant C: 'I proposed and ran a weekly design review for our team because we were shipping with too many late-stage rewrites.' Within your work area, but improving how the whole team operates.

Quadrant D: 'I noticed three teams were each building their own metrics dashboards and proposed a shared one, then helped scope the platform team's work to support it.' Cross-team, company-level reach.

Not every interview prompt fits every quadrant, but having stories distributed across the four lets you match the right scale to the question. A junior role tends to draw more from A and C; a senior role tends to draw more from B and D.

The Discovered-Proposed-Shipped Arc

The spine of every strong initiative story has three beats:

1. Discovered. How you noticed the problem. The non-obvious-ness lives here.

2. Proposed. How you got buy-in. Even if it was small, even if it was just your manager.

3. Shipped. What landed and what changed downstream.

A story missing any of those three beats reads as incomplete. 'I noticed a problem and shipped a fix' is missing the proposed step, which makes it sound like you ignored the team. 'I noticed a problem and proposed a fix' is missing the shipped step, which makes it sound like you do not finish things. 'I shipped a fix' alone is missing the discovered step, which means it is not really an initiative story.

When you draft an answer, mark each of the three beats explicitly in your outline. If you cannot point at one of them, the story needs work or it is the wrong story for this prompt.

Common Questions & Model Answers

Prompt 1: 'Tell me about a time you went above and beyond.'

Model answer (strong, Quadrant B example)

'In Q4 2023 I was an L4 engineer at a 200-person startup, on the search team. I had been on-call the previous week and had spent about four hours of one shift trying to debug an incident in the recommendations service, which my team did not own. The runbook for that service was three sentences long and pointed at a Slack channel that mostly redirected to a former engineer who had left. The on-call schedule went all the way around our team in six weeks, so this gap was costing us roughly four hours per rotation in time-to-diagnose.

I owned getting the runbook fixed even though the recommendations service was not on our team's roadmap.

I started by spending two hours with the engineer on the recommendations team who had the most context, mostly listening and writing down what I learned. I then drafted a runbook in our team wiki: the four most common alert sources, the dashboards to check first, the named owners on their team, and the rollback path for the two most likely failure modes. I sent it to their lead with the explicit framing 'this would have saved me four hours last week, can you sanity-check it'. They edited two things and adopted it for their own team's on-call.

Over the next two quarters, average time-to-diagnose for recommendations alerts in our on-call dropped from about an hour to under 15 minutes, based on five incidents tracked in our retro doc. Their team backfilled named ownership the next quarter, partly because the runbook made the gap visible. The thing I would do differently is share the draft with their lead before publishing rather than after; I got lucky that they were receptive, but pushing a runbook on someone else's service without warning could easily have landed badly.'

What lands: a non-obvious problem (most engineers would have just complained on Slack), a small ask not a large one, the other team owning the outcome long-term, real numbers, and a self-aware reflection about the risk of how the candidate operated.

Prompt 2: 'Describe a time you took ownership of something outside your scope.'

Model answer (strong, Quadrant D example)

'In Q2 2024 I was an L5 engineer on the platform team at a 600-person SaaS company. We had three product teams each building their own usage-metrics dashboards, with three different definitions of 'monthly active user'. I noticed this when our PM came back from a customer call where the customer had screenshots from two of our dashboards that disagreed by 30%. Nobody owned aligning the definitions, and it had been quietly bothering people for a year.

I owned getting alignment on a single definition, even though metrics standardisation was not on my team's roadmap and was not in my IC scope.

I started small. I spent a week pulling all three dashboards into one doc, side by side, with the SQL each one used and the divergence cases highlighted. I shared it with the three PMs and the analytics lead, framed as a question rather than a proposal: 'is this the picture as you see it, and should we align'. All four said yes within three days. We held two 30-minute meetings, agreed on a definition, and our team contributed the small amount of platform work to make the unified definition queryable. Total platform-side cost was about three engineering days; the rest of the work stayed with the product teams.

The unified definition shipped in six weeks. In the year after, we eliminated five customer-facing inconsistencies that had been the source of recurring support tickets, and the analytics team was able to stop maintaining three near-duplicate ETL pipelines, which they estimated saved them about a quarter of their maintenance load. I learned that the highest-leverage initiative is often diagnostic, not implementation: writing down what is actually going on, in one place, was 80% of the value here. The remaining 20% was the platform plumbing.'

What lands: the spotting moment is non-obvious (a 30% discrepancy that nobody had quantified), the candidate scoped small (one doc, two meetings, three engineering days), the credit goes to the right places (analytics team, product teams), and the lesson is generalisable.

Prompt 3: 'Walk me through something you initiated that was not asked of you.'

Model answer (strong, Quadrant A example, discovered-proposed-shipped arc)

'In Q3 2022 I was a mid-level engineer at a B2B startup and I noticed that our PR review turnaround for our team had crept from a median of about 4 hours to about 26 hours over the previous quarter. We were a team of nine and the slowdown was not on anyone's radar; the symptom was that PRs were sitting open for a day or more and people were just routing around it by self-merging small changes.

I owned diagnosing it and proposing a fix even though my manager had not flagged it.

Discovered: I pulled three months of PR data from the GitHub API. Two patterns. First, 60% of stale PRs were touching one specific code area where only two people on the team had context, and both of them were on a launch. Second, our team channel had no surface for stale PRs, so a PR sitting open simply disappeared from anyone's mental queue.

Proposed: I wrote a one-page note with two suggestions. One, rotate one of the two specialists onto general review duty during launch quarters. Two, add a daily Slack summary of PRs older than 24 hours. I sent it to my manager with a small ask: try option two for two weeks as an experiment. They said yes the same day.

Shipped: I built the Slack summary in a weekend, about 60 lines of Python plus a Slack webhook. We ran it for two weeks. PR median dropped from 26 hours back to 6, even before we made any reviewer-rotation change. We adopted it as our team practice and three other teams in the org asked for the script over the next quarter.

What I take away is that a tiny tool with the right surface area can outscore a much bigger process change. I now default to 'what is the smallest thing I can ship in a weekend that would make this visible' before I think about heavier interventions.'

What lands: explicit Discovered-Proposed-Shipped beats, a small experimental ask, a quick weekend execution, real numbers, and a generalised principle the candidate now uses.

Prompt 4: 'Tell me about a time you noticed a problem before others did.'

Model answer (strong, Quadrant D example)

'In Q1 2024 I was a senior engineer reviewing our customer support tickets for the prior quarter as part of an on-call rotation handoff. I noticed that 18 of the 47 tickets we had handled mentioned the same workflow: customers trying to integrate our webhook system and getting confused by signature verification. The tickets had not been tagged in any way that would have surfaced this to the product or docs team. Each individual ticket had been resolved in under an hour, but the cumulative cost was substantial.

I owned surfacing this even though it was not part of my role to do trend analysis on support tickets.

I built a one-page summary: the 18 tickets, the average time-to-resolution per ticket (about 35 minutes), the total support cost (about $7K in support engineer time), and three concrete fixes I thought were available (a clearer error message in our SDK, a small docs update, and one library change). I sent it to our docs team and the engineer who owned the SDK. The docs update shipped in a week. The SDK change shipped in three weeks. The library change took longer because it required a minor breaking change, but it landed in the next release cycle.

In the quarter after, webhook-signature tickets dropped from 18 to 3, and the support team reused the format I had built for trend analysis on two other recurring patterns. The thing I would do differently is set up the trend report as a recurring artefact rather than a one-time thing; I built it once, helped, and then nobody ran it again until I left and someone else picked it up.'

What lands: the non-obvious noticing (a pattern across 18 tickets nobody had aggregated), real cost numbers, three specific proposals not just one, the credit going to the docs and SDK teams, and a reflection that names a missed opportunity for durability.

Prompt 5: 'Describe a time your initiative did not pay off.'

Model answer (strong, honest failure)

'In Q3 2022 I spent about three weeks of my own time prototyping a refactor of our event-processing service. The service had been written by a former engineer and had what I considered to be three architectural smells: implicit coupling between two queues, a single global lock around a hot path, and no clear test boundary for the consumer side. I had not been asked to look at it, but I had on-call experience with two of the three issues.

I owned the prototype and the proposal, and the proposal did not get adopted.

What went wrong, in retrospect, three things. First, I started with the technical artefact (the prototype) before the business case. When I went to my manager with a working refactor, the question I got was 'how much did this cost us last quarter and how much will the refactor cost'. I did not have those numbers. Second, I had not talked to the team that owned the service before I started. They had different priorities and a different read on which of the three smells actually mattered. Third, the prototype was at the wrong scope: too big to ship as an experiment, too small to fully justify the rewrite.

The work was not entirely wasted. About a third of the prototype's ideas were absorbed into the service over the next year, mostly the test-boundary work, which I shared with the owning team after the fact. But the bigger refactor never happened, and arguably should not have.

What I changed in how I work: I now do the cost-of-inaction analysis before the prototype, not after, and I always have a 30-minute conversation with the owning team before writing more than half a day of code. I have shipped four cross-team initiatives since with this approach, and the failure rate has dropped sharply.'

What lands: a real failure, three specific mistakes named honestly, a partial silver lining without overclaiming it, a behavioural change, and evidence the change has worked since.

Prompt 6: 'Tell me about a time you saw work nobody owned and took it on.'

Model answer (strong, Quadrant B example)

'In Q2 2023 I was an L4 engineer on the billing team. We had a small library, used by four other teams, that had no clear maintainer. The original author had moved teams a year earlier and the library had silently accumulated 14 open issues. Two of those issues were actively breaking integrations for one of the four downstream teams.

I owned getting maintainership formalised, which was not on my roadmap.

I had the easier first step: I fixed the two integration-breaking issues over a week, mostly because they were directly relevant to my own team's work. That gave me credibility to make a proposal. I then wrote a one-page note: the library has no owner, here is the issue backlog, here is who depends on it, and I propose either a) my team takes formal ownership and we dedicate a 10% allocation to maintenance, or b) we deprecate it and migrate the four downstream teams to the in-house alternative. I sent it to my manager and the four downstream team leads. We landed on option a, my team took ownership, and we set a quarterly maintenance budget.

In the year after, the open issue count went from 14 to 3, the integration-breaking pattern stopped, and the deprecation question got a clear answer (we kept it). I learned that the cheapest way to earn the right to make an ownership proposal is to fix two of the visible bugs first; the proposal lands much better when it comes from someone who has already done some of the work.'

What lands: the candidate did some of the work before proposing, gave the team a clean either-or, the option that won was the one with explicit cost (10% allocation), the metric is a real backlog reduction, and the lesson is a tactic the candidate now reuses.

Pitfalls Specific to This Competency

Four traps that show up most often in initiative stories:

1. Sounding self-aggrandising. 'I single-handedly saved the team from disaster' reads as embellishment, even when it is true. Strong stories let the work speak: name the action plainly, credit the people who helped, let the metrics carry the weight. The interviewer is reading for evidence, not heroism.

2. Confusing busy-work for initiative. 'I worked late to get the project done' is not initiative; it is hours. Real initiative is about agency and judgement, not effort. If the only signal in your story is that you put in extra time, replace it with a story where you also chose what to spend that time on.

3. Not finishing. 'I proposed a fix' without 'I shipped the fix' reads as a half-credit answer. If you only got as far as the proposal, name that explicitly and explain why; do not let the listener assume implementation when there was none.

4. Initiative as overreach. Stories where the candidate kept pushing on a dead idea for years, or rebuilt something the team had explicitly decided not to rebuild, score against the candidate. Self-awareness about when to stop is part of the rubric for senior levels.

Practice Prompts & Exercises

For each prompt below, draft a 200 to 300 word STAR answer using a real story from your career. Then mark which of the four quadrants the story falls into and which of the five rubric signals it hits.

1. Tell me about a time you went above and beyond your job description.
2. Describe a problem you noticed and fixed without being asked.
3. Walk me through something you initiated that was outside your scope.
4. Tell me about a time you owned a piece of work nobody else wanted.
5. Describe a time your initiative did not work out and what you learned.
6. Tell me about something you built or proposed that the team adopted.
7. Describe a time you spotted a problem in someone else's area and how you handled it.

For every story, fill in the Discovered-Proposed-Shipped beats explicitly. If you cannot point at one of the three, either fix the gap or pick a different story.

Bridge / Cross-References

This lesson sits next to the previous one in the same category, and they overlap by design. Many initiative stories also involve influence, and many influence stories also involve initiative. The difference at the rubric level: initiative is graded on agency (did you act?), influence is graded on the mechanism (how did you move the group?). When you bank a story, label it with both competencies if it serves both, and prepare two slightly different framings.

Supporting Foundations lessons:

• star-method and story-banking give you the structure and the inventory of stories you draw from.
• crafting-compelling-stories shapes the discovered-proposed-shipped arc into a hook-conflict-resolution narrative.
• quantifying-impact is the lesson that backs up the cost-of-inaction beat in every model answer above.

The next lesson, Making Hard Decisions Under Uncertainty, picks up where this one leaves off. Where this lesson is about acting on problems nobody handed you, that one is about acting when the right answer is not obvious. The two competencies often appear in the same story, but the rubric signals are different.