Ask Experienced Devs

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.

The ability to jump into a task with minimal instruction is the key differentiator of a senior engineer. You have a ticket with some requirements. You have the code base. You should know where to go from there.

Now to be clear, I'm not saying I expect a senor dev to do it by themselves. Quite the opposite. You're going to have questions, and you're going to need clarification. But in situations where a junior dev would just say "help I'm stuck", a senior dev knows how to figure out what questions to ask, and asks them.

Not just technical questions, but also questions about the business. Product managers are going to assume you can read their mind. It's up to you to work with them and figure out what they actually want.