I know this is a very generalized question, as it depends on the company, product, position, etc. But in general, what sets someone apart as ready for a senior position over an intermediate or junior position? Experience I would think would be a big one, but say you have a candidate that shows problem solving abilities to solve code problems, but is newer to the tech field vs someone who’s been in the field x years, does the first guy have a shot without really knowing the ins and outs of working as a software engineer, hoping to pick it up quick?

  • SuperNerd@programming.dev
    link
    fedilink
    arrow-up
    10
    ·
    11 months ago

    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.

    • monobot@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      My company also defines is like ‘being able to define a problem and lead a project’, sadly technical knowledge doesn’t have much to do with ‘seniority’.

    • remotedev@lemmy.caOP
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      I was asking about interviewing as a newcomer to the software dev world. I’ve been going through an online school to learn the fundamentals, and about to start their program that when you finish allowe you to target higher positions when job hunting. I don’t question the skills part of the program, I’ve just been wondering how they would be able to prepare us to go right to more senior positions out of the gate and get other companies to accept us at that level.

      I feel like imposter syndrome is bad enough without feeling like any tiny mistake you’d make would have your whole team thinking you’re in way over your head.

      • MajorHavoc@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        9 months ago

        I feel like imposter syndrome is bad enough without feeling like any tiny mistake you’d make would have your whole team thinking you’re in way over your head.

        Impostor syndrome sucks, but someone who just joined a new organization, is statistically, absolutely in way over their head.

        The hard part to come to grips with is: that doesn’t make them an impostor, it makes them a developer who just joined a new organization.

        Now don’t get me started on teams that make people feel bad for that. They suck and they deserve the revolving door of non-help talent that they end up invariably hiring over and over, because they can’t retain talent.

  • Dr. Wesker@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    11 months ago

    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.

    • SuperNerd@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      Dang, sorry. Maybe your manager sucks and isn’t teeing you up for it or being clear about it? Or heck maybe your org just sucks.

  • hairyballs@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    11 months ago

    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.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 months ago

    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.

  • tinker_james@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    10 months ago

    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.