Junior impacts a project. Staff impacts the org. Where does your story land?

The fastest way to know whether a behavioral story is strong enough for the role you want is to ask one question: what was the scope of the impact? There's a clean ladder, and interviewers use it whether they name it or not:

Junior engineers impact a project. Mid-level engineers impact a product. Senior engineers impact the team. Staff engineers impact the org.

A story scores at the level of the impact it demonstrates — not the level of effort, not the difficulty of the code, not your current title. If you're interviewing for a senior role and your best story shows you shipping a hard feature flawlessly, that's a product-level story, and it will read as under-leveled. The interviewer's question isn't “was this hard?” — it's “did this change how the team operates?”

Two things follow. First, target your own level squarely and let small hints of the level above show your growth: a senior candidate is strongest with team-level stories that hint at org-level influence — you're not expected to have all org-level impact. Second — and this is where most engineers leave points on the table — you probably have higher-level impact and aren't counting it. Senior and staff impact is often the low-visibility work that feels like “just doing my job”: you owned a dev process, you researched a library that the team decided not to adopt (saving weeks of misdirected effort), you changed how a meeting ran, you unblocked three other engineers. None of it shipped as a deliverable. All of it is team-level impact.

Before you conclude you don't have a staff-level story, re-read the experiences you already have and look for the impact that doesn't look like a deliverable. It's usually there. You've just been trained not to count it.