66

What can I do to quickly build my reputation as a junior engineer?

Profile picture
Entry-Level Software Engineer at Series B Startup2 years ago

What can I do to get on the radar of senior engineers within the company and build respect for me overall? My company is also relatively small, so I'm fairly close with the CTO as well.

5.9K
4

Discussion

(4 comments)
  • 60
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    2 years ago
    • The best thing to do as a junior engineer to earn respect is to write extremely high quality code. There is so much more depth to coding than just being able to get things functional relatively quickly, which a lot of earlier-in-career engineers don't realize.
    • Make every one of your pull requests at least as high-quality as the one I linked below. This is something I did as I grew as a software engineer and taught repeatedly to every mentee I've ever had to great success.
    • Think about how you can write 0-bug code. This can involve thinking about overall approach more deliberately, thinking through edge cases proactively, and pairing your code with automated test coverage.
    • It can be easy to get distracted by non-coding things, especially more "senior" level behaviors like leading/managing projects. You can do these if you have the time; just make sure not to do them at the expense of your coding foundation. You should be feeling your code getting better and better and your ability to write truly clean code getting faster. And hopefully, this should be mirrored in feedback as well.

    Here's an example of an excellent pull request from when Taro was open-source.

    I also highly recommend this Q&A on how to write great code faster.

  • 47
    Profile picture
    Staff Software Engineer @ DoorDash, ex-FB, ex-Klaviyo
    2 years ago

    Alex already made some great suggestions especially regarding code quality. I would add a few more

    • document your findings and any learnings. Share them with your team. This is a very good way to build a reputation for yourself. Most importantly, a vital way to promote a collaborative culture on your team.
    • For any complicated design decision you are making, write your though process down in a doc. Take a step back to think deeply about the problem first before you start writing code. This is a very important mindset change from junior to senior. You also can use this doc in two ways
      • present this doc as a RFC if you want more opinions.
      • point to this doc when asked about why you made this design decision.
    • leave anything you touch better. This could be
      • something in code.
      • a wiki doc you read.
      • a onboarding process that you find annoying
    • we are all humans. spend some time getting to know other people (not just senior SWEs) on your team. Like you said, it's a small team, it's very important to know them in the context out of work. Build a deeper connection and it will make work more fun and efficient. Some of my closed friends right now are the ones I made during I worked at Klaviyo (my first startup).
  • 27
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    2 years ago

    Yes! Really going deep on code quality is a very transferrable skill, and a lot of the code review "dressing" in particular (thinking through trade-offs, testing) is already done naturally during the coding process: You just need to "capture" this activity and embed it in your pull requests.

    At all 3 of my previous companies (Course Hero, Meta, Robinhood), my extreme coding depth here was always met with very high praise. When I joined Course Hero, it was roughly the equivalent of a Series B startup, and this behavior of mine was very appreciated.

    A lot of ambitious engineers will also eventually go to Big Tech, and this kind of behavior is extremely important there since it's so important to keep their massive systems clean and working.

  • 14
    Profile picture
    Entry-Level Engineer [OP]
    Series B Startup
    2 years ago

    Given we're a startup, other engineers on my team don't spend that much diligence on their code and code reviews. However, my CTO does really appreciate good code quality. All that being said, is this still the write thing to invest time in?