1

Sharing metrics with context that prove I'm good at execution in interview, resume, etc.

Profile picture
Mid-Level Software Engineer at Taro Community7 months ago

I feel like we are saying in interviews, resume, and performance review the best practice is to include business impact numbers.

However, for lower levels (junior and mid), if impact doesn't matter, and execution is 100% of your value, shouldn't I just be focusing my resume and behavioral interview on how effective of an engineer I am and include metrics to track how good I am?

For example: I have this story that has a lot of great execution wins:

I reduced testing thrash by 90% by creating a data mapping document, scheduling and leading a sync meeting of the data mapping document with my PM, and using it to craft my unit tests.

For context there are 5 message types that can come from at least 6 different places that need to be translated, correlated, and routed properly.

This was measured by the results of the first test in staging that went through for my project.

74
6

Discussion

(6 comments)
  • 1
    Profile picture
    Eng @ Taro
    7 months ago

    For junior and mid, I'd be more interested in the scope of the projects that you've undertaken. I would define scope by complexity of project and collaboration with stakeholders. This gives a good signal about the technical depth and communication of the candidate.

    However, for lower levels (junior and mid), if impact doesn't matter, and execution is 100%

    I would argue that even at junior and mid, demonstrating business impact is still more important because it shows that you understand "why" a project had to done in the first place. Especially at larger companies, this is what you'll be judged on the most.

  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    7 months ago

    Mid-level is where things get interesting as mid-level engineers (generally) want to get to senior, a level at which you are held responsible for impact/direction. This applies to interviews as well where many mid-level engineers would love to get upleveled to senior during the interview process, especially if they have been mid-level for a while.

    Regardless, the nuance around junior and early mid-level engineers not getting rewarded for impact is more around promotion, and it isn't as relevant for a recruiter reading through the resume as there's very little chance they understand this nuance. So big flashy numbers are still good, and you should include them if you have them. It's one of those things where there's no real downside, so might as well.

    Even in promotion packets, I would recommend junior engineers include the overall impact of the project they worked on (e.g. I worked on this thing that added +5% revenue) as it's a small cost to add that number (i.e. a few seconds) and it makes their packet look crispier. They definitely won't get credit for it if the calibration committee know what they're doing, but hey, might as well try.

    In your scenario, I think you should do both. Include the top-line number (i.e. revenue/usage statistics of the overall feature) alongside numbers more related to quality of execution (e.g. I was the only engineer on my team to ship 5+ major features across a year with 0 production outages). I like your test thrash number as well.

  • 1
    Profile picture
    Mid-Level Software Engineer [OP]
    Taro Community
    7 months ago

    Hmm then if impact was get x clients back online due to a legacy bug,

    collaboration was with manager po senior engineer, and a external client

    And the scope was correlate and translate like 6 message types from multiple sources to a single destination with a consistent message format,

    I’m trying to figure out for my situation what’s good complexity.

    The low level details of which field goes where I did without any help or handholding and all. So I’m trying to figure out if this is valid.

    • 0
      Profile picture
      Tech Lead @ Robinhood, Meta, Course Hero
      7 months ago

      At the end of the day, you can't control what you've done in the past. Just pick your best wins and highlight them as well as you can.

      If you aren't sure what your best wins are, you can try different responses to the same question (this is in the context of behavioral interviews) and see how people react.

      For behavioral interviews, I talk about all that in-depth here: [Course] Master The Behavioral Interview As A Software Engineer

    • 1
      Profile picture
      Mid-Level Software Engineer [OP]
      Taro Community
      7 months ago

      I think I’m more focused on step 1 instead of step 2. (I watched your series 👀)

      That flowchart u gave me about u got good opportunity to build cool stuff the answer is clearly yes.

      The other clear thing is in my 1:1 my manager said go start learning how to handle here’s the problem xfn go come out on the other side.

    • 0
      Profile picture
      Mid-Level Software Engineer [OP]
      Taro Community
      7 months ago

      Projects are large enough where im trying to focus on depth of contribution and quality of delivery wherever possible