Is this for interviewing or promotion?

At my org the formal definition is "[demonstrated] ability to lead projects at x scope." This is how people leaders frame it.

But to individual contributors (engineering track) folks, I think we are looking for:

• Thinks. Applies themselves to the hard work of figuring things out. Reads documentation for libraries and languages to get how to use them. Doesn't vomit up random groupthink (from the wider org or web) without understanding it.
• Curious: doesn't take "this is how we've always done it" as a thought stopper -- wonders if there's a better way. Flexible, open to learning.
• Teamwork skills: communicates own level of certainty, listens to others and tries to understand -- not stubborn: honestly tries to figure out the best solution rather than trying to look smart in front of others. Has a feel for how to help everyone be heard and add their thoughts to the group decision.
• Communicates clearly-- excellent written documentation for spikes/designs/decisions is a clear stand out here. (easy win with high visibility)
• Can start to participate in meta/scope and product type conversations around "hey this is stupidly hard why don't we just do this slightly different thing that's way easier" (extra credit at this level)

How to show this when interviewing vs getting promoted is different.

My experience is that every company makes it up as they go, and every year or two they "reorg" and redefine their annoyingly abstract role definitions. Not the answer you're asking for I'm sure, but clearly I'm just speaking from frustration.

For an IC, I think it's mainly about autonomy. The management don't want to be behind you. You get assigned a task, you ought to know how to handle it (including asking to the right persons) and to deliver it on time.

At my workplace, we separate Developer from Lead Developer role, and "experience level" into Junior, Professional, and Senior.

A Professional can work without much guidance (and knows when to ask and seek collaboration). A Senior can instruct and support the team beyond that.

If you're talking a straight up senior individual contributor without mentorship, leadership or ownership responsibilities attached, then I agree with what others have said about autonomy. A senior is given a problem or task and comes back some time later with the completed solution. If there is feedback, a senior will get clarification, go away again, and come back with an updated solution.

In my experience, this has required:

• Technical competence and confidence (research, coding skills, digging into source code if documentation is sparse, having a good understanding of the big picture as well as the implementation details)
• And equally as important (in bigger orgs), being able to seek out help/answers for org specific things that aren't googleable without hand holding. (example: getting a name of a potential subject matter expert from a tech lead and take it from there -- initiate the conversation, vet out the content, get a solid understanding -- without hand holding from the tech lead)

To more directly answer your question: Time isn't necessarily a factor. Demonstrating that the way you approach problems/tasks and the actual results you produce can be trusted and relied on firmly plants you senior territory imo.